Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработки. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.

Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.

Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!

Начало

Выделю общие темы статьи: 

1. Управление ожиданиями.

2. Отстаивание интересов компании.

3. Переговоры.

4. Несправедливость — это норма.

5. Расхождение плана и факта.

6. Работа с рисками.

7. Обратная связь.

Многовато выходит? Отнюдь. Например, в роадмапе тимлида пунктов раз в десять больше. Это только базовый пул и краткая выжимка. И вы неслучайно не видите здесь проектирование систем. Зачастую плохое архитектурное решение — это производная от неверной оценки ситуации лидом: некорректно были оценены риски решения, срок работ указан слишком амбициозно, плохо выстроена коммуникация и т. д. Например, ваша система постоянно теряет важные сообщения не потому, что вы не знали, что есть способы надежнее гарантировать их доставку, а потому, что неверно оценили важность конкретных сообщений для компании. 

И если вы дочитали до этого момента, пришло время погрузиться в каждую из тем.

Управление ожиданиями

Вариаций проблем в команде разработки может быть много, но очень часто в основе лежит несоответствие ожиданий действительности. 

Работа лида — это постоянное общение с людьми:

• с руководителем(ями); 

• с соседними командами; 

• с заказчиками фич; 

• со своими сотрудниками;

• с кандидатами в команду.

Эти группы иногда пересекаются, но в каждой из них важно управлять ожиданиями и выстраивать прозрачную, понятную коммуникацию. 

Предлагаю рассмотреть ситуацию, в которую попал один из начинающих тимлидов нашего отдела. Представим, что этим тимлидом являетесь вы. Есть большая фича, которая должна быть готова к концу месяца. Её ждут решительно все, особенно целевой заказчик.
В середине месяца вы понимаете, что команда не успевает, потому что появился «подводный камень» в мониторинге работы фичи на проде. Вариант «Что-то по-быстрому придумать и уложиться в срок» не сработал — как быть?

Не норм

Вы всё-таки как-то пытаетесь уложиться в срок, надеетесь на лучшее. Не успеваете. В начале следующего месяца приходит заказчик и интересуется статусом своей фичи — начинаются попытки оправдаться. В авральном режиме доделываете фичу к следующей неделе. Катите недостестированный битый релиз. Ломаете прод. Огорчаете руководителя. Демотивируете команду. Наносите финансовые потери компании и множеству людей, которые от неё зависят.

Норм

В первую минуту предупредить заказчика о форс-мажоре, объяснить ситуацию, извиниться, опционально сделать грустный взгляд (если вы оба работаете в офисе, это особенно важно) и в будущем делать всё возможное, чтобы ситуация не повторилась.
Во вторую минуту предупредить всех остальных интересантов (на них можно грустными глазами не смотреть), также объяснив им ситуацию. В объяснение лучше включить факт изменения процессов в вашей команде, чтобы системно искоренить возникшую проблему со срывом сроков по этой причине в будущем. 

Превентивная коммуникация даёт понять интересантам, что проблема действительно значимая, — и вы либо убедитесь в этом и всех поставите в известность, либо вам скажут, что это не такая уж и проблема и можно запускаться в существующем виде. 

Пример может быть не связан со сроками. Вместо них могут быть следующие ситуации:

• сомнительное качество результатов;

• заказчик просил одно, а получает другое;

• релиз ломает что-то уже давно работающее в системе.

Управление ожиданиями стоит на трёх слонах: честность, прозрачность и планирование. Находите в себе силы объективно оценить ситуацию, не пытайтесь понравиться кому-то путём искажения реальности. Прозрачно ведите коммуникацию со всеми интересантами, вовремя предупреждайте о проблемах, не имеющих быстрого решения. Перед началом работ декомпозируйте процесс и планируйте каждый кусочек отдельно.

Отстаивание интересов компании 

Звучит как задача для топ-менеджмента, однако это один из важных пойнтов в работе тимлида. Интересы любой компании — это эффективная утилизация ресурсов, соблюдение заявленных сроков, отсутствие инцидентов из-за новых релизов, небольшая текучка кадров и т. д. Они могут меняться по разным причинам. Этот список можно продолжать, но, если попытаться формализовать — нужно делать то, что решает задачи компании. 

Важный момент заключается в том, что интересы вашей команды и интересы компании должны быть сонаправлены. Ни в коем случае их нельзя противопоставлять. 

В одной из компаний, где я работал, однажды схантили целиком готовую команду: наняли лида вместе с его сотрудниками. План заключался в найме притёртой опытной команды во главе с руководителем, которая должна была дать серьёзный буст системе. В итоге новые сотрудники слились в едином порыве отстаивания исключительно своих интересов: 

• «Задачу не берём, пока она до мелочей не проработана кем угодно, кроме нас»;

• «Сроков не называем, поскольку мы так не работаем, ждите очередную итерацию на ближайшем демо»;

• «Нам нужны огромные долгие встречи всем составом, чтобы принять любое архитектурное решение». 

Инвестировать в такую команду дальше, конечно, никто не собирался.

Компании заинтересованы в экспертных мотивированных командах, нацеленных на результат. Равно как и команды заинтересованы в стабильных сильных компаниях. Чем сильнее компания, тем амбициознее задачи и стремительнее рост. Ниже — не исчерпывающий список, а лишь часть примеров.

Когда интересы компании НЕ отстаиваются? 

• вводится 100 статусов для задач, что оттягивает сам запуск;

• на тайм-менеджмент тратится больше времени, чем на решение задач; 

• команда системно демотивируется, в ней большая текучка; 

• незамедлительно внедряется любая новая технология, потому что это модно / интересно попробовать / «на конфе доклад о ней видел»; 

• задачи решаются очень быстро, но необдуманно;

• задачи решаются слишком долго, хоть и качественно; 

• пишутся свои «велосипеды», потому что это интересно. 

Когда интересы компании отстаиваются?

• проектное управление используется как инструмент достижения целей; 

• используется минимум инструментов для получения максимального результата; 

• команду слышат, есть системные встречи 1:1 и ретро, а проблемы реально решаются;

• задача решается оптимальным образом в контексте соотношения затраченных ресурсов и результата;

• используются наработки и решения других команд. 

Переговоры 

Основная цель переговоров лида с любыми сторонами — достижение соблюдения интересов компании. Это может быть не всегда очевидно. Например, вы договорились определённым образом ревьювить код — и участникам ревью стало сильно комфортнее. На первый взгляд, это не про пользу компании. Однако на самом деле в долгосрочной перспективе она получит более лояльных и сплочённых разработчиков в этом конкретном юните.

Даже когда участников переговоров всего два — вы и ваш сотрудник на регулярной встрече 1:1 — принятые решения должны служить улучшению результатов компании. То же самое касается и встреч большим составом — и не только внутри вашей команды.

Есть две крайности: 

• стараться переспорить других и ценить только своё мнение;

• делать всё так, как говорят другие, чтобы лишний раз ни с кем не дискутировать.

Обе крайности зачастую ведут к провалам и внедрению плохих решений. Выслушивайте аргументы всех интересантов, взвешивайте свою позицию, калибруйте мнения друг с другом — и встаньте максимально непредвзято на сторону лучшего решения.

Разберём пример: вы решили, что написать продакшен-код и всю бизнес-логику на любой опенсорс-кодогенерилке — это отличная идея. Вы полны решимости внедрять, но вдруг сталкиваетесь с сильным хейтом со стороны своей команды и владельцев сервисов-клиентов, которым вы анонсировали скорое внедрение.

Не норм

Вы проводите переговоры и отстаиваете свою позицию, отметая вполне логичные (если в них вдуматься) аргументы коллег. Итог: через очень короткий промежуток времени ваш сервис разрастётся, будет постоянно ломаться, а любые проблемы в сгенерированном коде будут решаться крайне долго и сложно.

Норм

Провести переговоры, пытаясь понять, чем вызвано такое отношение к вашему решению. Задать уточняющие вопросы и понять, что генерация бизнес-логики обойдётся очень дорого в долгосрочной перспективе. В итоге принять взвешенное решение отказаться от этой бесперспективной идеи.

И ещё один пример: в вашем продукте появилась функциональность, до ужаса похожая на функциональность продукта соседней команды. Лид соседней команды организует встречу, чтобы обсудить, кто всё-таки будет её реализовывать, чтобы избежать дублирования логики. 

Не норм

Срочно всё похожее передать соседней команде, поставить свои релизы в жёсткую зависимость от её приоритетов, далее при появлении каждой новой задачи приходить к руководителю и говорить: «Мы-то всё сделали, но вот они там ещё долго будут, поэтому результата нет».

Норм

Обсудить плюсы и минусы унифицированного решения. Насколько оно будет гибким? Ускорит ли деливери обеих команд? Как легко масштабируется? И, ответив на эти и другие вопросы, вместе решить, как поступить (чтобы было и дёшево, и надёжно).
 

Переговоры — это поиск баланса интересов и компромиссов, направленный на достижение осязаемого результата. Старайтесь как можно быстрее гибко находить выходы из любой ситуации, вместо того чтобы создавать новые тупики. Фиксируйте плюсы и минусы всех позиций. Прогнозируйте влияние решения на развитие проекта в долгосрочной перспективе. Пытайтесь понять, что и при каких обстоятельствах может пойти не так. 

Несправедливость — это норма

Реальность полна сюрпризов, мир не чёрно-белый — он всегда многогранен и переливается разными оттенками. Надеяться, что все процессы будут всегда максимально рациональными и справедливыми — это точно не путь самурая лида. 

В моей практике был случай на эту тему — поиск справедливости в оценке результата. Тимлиду соседней команды ставят KPI. Он всеми силами пытается его достичь, не обращая внимания ни на что больше. И на первый взгляд всё выглядит логично: есть KPI — значит, команда должна его выполнить на 150%. Противоречий тут как будто нет, однако упущен фундаментальный момент — что, помимо этого KPI, есть, к примеру:

• стабильность системы,

• доступность сервисов,

• скорость ответа основных методов API,

• текучка кадров,

• наём

• и т. д.

Все метрики, кроме KPI, при таком подходе сильно проседают. Результаты такой команды, конечно, никто хорошо оценивать не собирался. В итоге тимлиду кажется, что его результат оценён несправедливо, ведь KPI-то достигли, а всё остальное имело для него более низкий приоритет. Причём это произошло с учётом еженедельной обратной связи от его руководителя.

Несправедливо? С точки зрения тимлида — возможно. Но попытки искать справедливость, как правило, обречены на провал. Необходимо и улучшать систему новыми запусками, и поддерживать то, что есть, в хорошем состоянии.

Это лишь один из примеров. Полезно запомнить, что справедливости не существует, и учиться работать в таких условиях. 

Тимлид с первого дня работы сталкивается с разными ситуациями:

• разработчик очень старается и много работает, но не делает того, что требует задача, при этом просит повышения за свои старания; 

• бюджет юнита закончился — и нужно решить, кого из команды ротировать, при условии, что этого никто не хочет и вроде бы все молодцы;

• клиенты сервиса приходят с идеями, как правильно поступить, решая свои задачи без понимания нюансов продукта; 

• KPI поставили на полгода, но на пятый месяц ситуация резко изменилась и нужно срочно делать совсем другое; 

• разные интересанты хотят диаметрально разных фич, реализации которых конфликтуют между собой. 

И это всё — только первые несколько часов вашего рабочего дня. Именно поэтому не работает подход «Наберём много разработчиков — они сами как-нибудь справятся». И именно поэтому нужен руководитель, который будет на острие работы с несправедливостью и будет наводить порядок в хаосе. И делать это проще, если вы адекватно оцениваете ситуацию. 

Как же оценивать её адекватно?

• по возможности больше присутствовать на встречах с руководителями;

• следить за вектором развития компании в целом;

• стараться видеть дальше своей команды;

• узнавать, как что работает у других;

• вникать в желания и боли стейкхолдеров. 

Чем лучше вы упорядочите окружающую реальность, тем лучше будет чувствовать себя ваша команда и ваша компания.

Расхождение плана и факта 

Если ваши цели достигаются на 100%, то они недостаточно амбициозны. Если на 20% — слишком нереалистичны. То же самое можно сказать и про планы. Искусство в том, чтобы научиться сводить план с фактом с минимальным люфтом.

Разберём на примере планирования спринта: 

• запланировали спринт — и к середине уже всё сделали? Что-то идёт не так;

• запланировали спринт — и треть его запланированных работ переехала в другой? Что-то идёт не так; 

• всё выполнили в срок, обеспечив съезд только одной не очень-то и важной задачи, но команда сбежала от вас через неделю? Всё ещё что-то идёт не так;

• всё выполнили в срок, но катили все задачи в последний час спринта? Уже лучше;

• всё выполнили в срок и катили задачи равномерно в течение спринта? Вообще хорошо;

• всё выполнили в срок, катили задачи равномерно в течение спринта и успели ещё и составить план запусков следующего? Вы супер. 

Чтобы добиться результата в планировании, нужно тщательно взвешивать все возможности и риски (о них — далее). В итоге обязательно нужно проводить постанализ фактического результата, сверяя его с планом, и честно стараться найти и решить проблемы. В большинстве случаев они будут не в безделии ваших сотрудников.

Работа с рисками 

Дисклеймер: мы не рассматриваем ситуацию с точки зрения кризис-менеджмента. Цель риск-менеджмента — либо минимизировать проблемы, либо вообще не доводить до возникновения по-настоящему кризисной ситуации.

«Уважаемый товарищ тимлид, я срочно поехал к зубному», «Кошке стало плохо — и нужно срочно отвезти её к ветеринару» — риски, которые сложно спрогнозировать. Однако можно и нужно исходить из предположения, что на дистанции форс-мажоры будут в команде происходить. 

Сервис N, который давно надо было отрефакторить, внезапно отказал полностью; случился релиз с генерацией новых данных в базе, и они за первый час съели всё место — рутинные технические риски, которые нужно прогнозировать

Периодически выписывайте и структурируйте технические риски вашей системы, планируйте, как и когда их исключать. У вас должны быть список рисков и конкретные задачи по работе с ними со сроками и хотя бы коротким обоснованием того, почему ту или иную проблему не надо решать прямо сейчас.

Когда что-то произошло и команда героически в кратчайшие сроки всё исправила — это круто, но высший пилотаж — не допускать таких ситуаций, а без оценки рисков это крайне сложно. 

В крупных компаниях есть много подразделений — и может показаться, что коллеги, отвечающие за информационную безопасность, без вас отработают связанные с ней риски, сетевики — риски чрезмерной нагрузки на сеть, архитекторы скажут, как лучше построить систему, системные аналитики проработают риски непонятных описаний задач и т. д. Но это огромное заблуждение, которое приводит к печальным последствиям.

Любое профильное подразделение смотрит на деятельность компании в целом и улучшает процессы, которые оказывают на неё большое влияние. Однако только вы знаете нюансы работы именно ваших сервисов, и только вы можете ещё в зачатке обработать связанные с ними риски, чтобы они не разрослись до чувствительных проблем для всех.

Обратная связь 

Про обратную связь написано множество статьей (например, эта). Но, на мой взгляд, важно помнить одно: её нужно давать системно — и корректирующую, и поддерживающую.

«Ты молодец, отлично сделал задачу N, особенно понравилось, что ты в ней предусмотрел K и при релизе не случилось M».

Приятно ли слышать такие слова? Безусловно. Если подобное реально случилось, на встрече 1:1 обязательно нужно сказать их вашему сотруднику. Такая обратная связь покажет ему, что он всё делал правильно, — и в следующий раз при работе с такой задачей он с большей вероятностью поступит так же. При этом важно не обесценивать похвалу: отмечайте сильные стороны только тогда, когда они действительно есть.

«Мы вчера зарелизили задачу N на две недели позже заявленного срока. При первом релизе произошло K, а в кодовой базе я нашёл подход M, противоречащий нашей конвенции».

Приятно ли такое? Нет. Ни вам, ни вашему сотруднику. Однако это важно сказать и обсудить — умалчивание будет порождать уверенность сотрудника в том, что всё было хорошо и правильно. И в следующий раз это может обернуться куда более серьёзными последствиями для пользователей вашей системы.

Завершая разговор об обратной связи, приведу популярную цитату: «Хвалите публично, ругайте лично» — это правда работает.

Заключение 

Тимлид — это человек, который решает проблемы, а не создаёт их. Каждый из упомянутых пойнтов в действительности гораздо шире. Написанное — это только основы для тимлида. В моей практике даже в них случались проблемы. Решения звучат как «Нормально делай — нормально будет», несмотря на это они работают на практике, и я предлагаю внедрять их с самых первых дней работы тимлида. Усвоив эти основы, решать по-настоящему нетривиальные проблемы будет в разы проще.

Запомните их — и добро пожаловать в многогранный мир управления командой разработки! Всё получится — особенно с опытом и набитыми шишками. Но это уже совсем другая история…