Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработки. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.
Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!
Начало
Выделю общие темы статьи:
Многовато выходит? Отнюдь. Например, в роадмапе тимлида пунктов раз в десять больше. Это только базовый пул и краткая выжимка. И вы неслучайно не видите здесь проектирование систем. Зачастую плохое архитектурное решение — это производная от неверной оценки ситуации лидом: некорректно были оценены риски решения, срок работ указан слишком амбициозно, плохо выстроена коммуникация и т. д. Например, ваша система постоянно теряет важные сообщения не потому, что вы не знали, что есть способы надежнее гарантировать их доставку, а потому, что неверно оценили важность конкретных сообщений для компании.
И если вы дочитали до этого момента, пришло время погрузиться в каждую из тем.
Управление ожиданиями
Вариаций проблем в команде разработки может быть много, но очень часто в основе лежит несоответствие ожиданий действительности.
Работа лида — это постоянное общение с людьми:
с руководителем(ями);
с соседними командами;
с заказчиками фич;
со своими сотрудниками;
с кандидатами в команду.
Эти группы иногда пересекаются, но в каждой из них важно управлять ожиданиями и выстраивать прозрачную, понятную коммуникацию.
Предлагаю рассмотреть ситуацию, в которую попал один из начинающих тимлидов нашего отдела. Представим, что этим тимлидом являетесь вы. Есть большая фича, которая должна быть готова к концу месяца. Её ждут решительно все, особенно целевой заказчик.
В середине месяца вы понимаете, что команда не успевает, потому что появился «подводный камень» в мониторинге работы фичи на проде. Вариант «Что-то по-быстрому придумать и уложиться в срок» не сработал — как быть?
Не норм
Вы всё-таки как-то пытаетесь уложиться в срок, надеетесь на лучшее. Не успеваете. В начале следующего месяца приходит заказчик и интересуется статусом своей фичи — начинаются попытки оправдаться. В авральном режиме доделываете фичу к следующей неделе. Катите недостестированный битый релиз. Ломаете прод. Огорчаете руководителя. Демотивируете команду. Наносите финансовые потери компании и множеству людей, которые от неё зависят.
Норм
В первую минуту предупредить заказчика о форс-мажоре, объяснить ситуацию, извиниться, опционально сделать грустный взгляд (если вы оба работаете в офисе, это особенно важно) и в будущем делать всё возможное, чтобы ситуация не повторилась.
Во вторую минуту предупредить всех остальных интересантов (на них можно грустными глазами не смотреть), также объяснив им ситуацию. В объяснение лучше включить факт изменения процессов в вашей команде, чтобы системно искоренить возникшую проблему со срывом сроков по этой причине в будущем.
Превентивная коммуникация даёт понять интересантам, что проблема действительно значимая, — и вы либо убедитесь в этом и всех поставите в известность, либо вам скажут, что это не такая уж и проблема и можно запускаться в существующем виде.
Пример может быть не связан со сроками. Вместо них могут быть следующие ситуации:
сомнительное качество результатов;
заказчик просил одно, а получает другое;
релиз ломает что-то уже давно работающее в системе.
Управление ожиданиями стоит на трёх слонах: честность, прозрачность и планирование. Находите в себе силы объективно оценить ситуацию, не пытайтесь понравиться кому-то путём искажения реальности. Прозрачно ведите коммуникацию со всеми интересантами, вовремя предупреждайте о проблемах, не имеющих быстрого решения. Перед началом работ декомпозируйте процесс и планируйте каждый кусочек отдельно.
Отстаивание интересов компании
Звучит как задача для топ-менеджмента, однако это один из важных пойнтов в работе тимлида. Интересы любой компании — это эффективная утилизация ресурсов, соблюдение заявленных сроков, отсутствие инцидентов из-за новых релизов, небольшая текучка кадров и т. д. Они могут меняться по разным причинам. Этот список можно продолжать, но, если попытаться формализовать — нужно делать то, что решает задачи компании.
Важный момент заключается в том, что интересы вашей команды и интересы компании должны быть сонаправлены. Ни в коем случае их нельзя противопоставлять.
В одной из компаний, где я работал, однажды схантили целиком готовую команду: наняли лида вместе с его сотрудниками. План заключался в найме притёртой опытной команды во главе с руководителем, которая должна была дать серьёзный буст системе. В итоге новые сотрудники слились в едином порыве отстаивания исключительно своих интересов:
«Задачу не берём, пока она до мелочей не проработана кем угодно, кроме нас»;
«Сроков не называем, поскольку мы так не работаем, ждите очередную итерацию на ближайшем демо»;
«Нам нужны огромные долгие встречи всем составом, чтобы принять любое архитектурное решение».
Инвестировать в такую команду дальше, конечно, никто не собирался.
Компании заинтересованы в экспертных мотивированных командах, нацеленных на результат. Равно как и команды заинтересованы в стабильных сильных компаниях. Чем сильнее компания, тем амбициознее задачи и стремительнее рост. Ниже — не исчерпывающий список, а лишь часть примеров.
Когда интересы компании НЕ отстаиваются?
вводится 100 статусов для задач, что оттягивает сам запуск;
на тайм-менеджмент тратится больше времени, чем на решение задач;
команда системно демотивируется, в ней большая текучка;
незамедлительно внедряется любая новая технология, потому что это модно / интересно попробовать / «на конфе доклад о ней видел»;
задачи решаются очень быстро, но необдуманно;
задачи решаются слишком долго, хоть и качественно;
пишутся свои «велосипеды», потому что это интересно.
Когда интересы компании отстаиваются?
проектное управление используется как инструмент достижения целей;
используется минимум инструментов для получения максимального результата;
команду слышат, есть системные встречи 1:1 и ретро, а проблемы реально решаются;
задача решается оптимальным образом в контексте соотношения затраченных ресурсов и результата;
используются наработки и решения других команд.
Переговоры
Основная цель переговоров лида с любыми сторонами — достижение соблюдения интересов компании. Это может быть не всегда очевидно. Например, вы договорились определённым образом ревьювить код — и участникам ревью стало сильно комфортнее. На первый взгляд, это не про пользу компании. Однако на самом деле в долгосрочной перспективе она получит более лояльных и сплочённых разработчиков в этом конкретном юните.
Даже когда участников переговоров всего два — вы и ваш сотрудник на регулярной встрече 1:1 — принятые решения должны служить улучшению результатов компании. То же самое касается и встреч большим составом — и не только внутри вашей команды.
Есть две крайности:
стараться переспорить других и ценить только своё мнение;
делать всё так, как говорят другие, чтобы лишний раз ни с кем не дискутировать.
Обе крайности зачастую ведут к провалам и внедрению плохих решений. Выслушивайте аргументы всех интересантов, взвешивайте свою позицию, калибруйте мнения друг с другом — и встаньте максимально непредвзято на сторону лучшего решения.
Разберём пример: вы решили, что написать продакшен-код и всю бизнес-логику на любой опенсорс-кодогенерилке — это отличная идея. Вы полны решимости внедрять, но вдруг сталкиваетесь с сильным хейтом со стороны своей команды и владельцев сервисов-клиентов, которым вы анонсировали скорое внедрение.
Не норм
Вы проводите переговоры и отстаиваете свою позицию, отметая вполне логичные (если в них вдуматься) аргументы коллег. Итог: через очень короткий промежуток времени ваш сервис разрастётся, будет постоянно ломаться, а любые проблемы в сгенерированном коде будут решаться крайне долго и сложно.
Норм
Провести переговоры, пытаясь понять, чем вызвано такое отношение к вашему решению. Задать уточняющие вопросы и понять, что генерация бизнес-логики обойдётся очень дорого в долгосрочной перспективе. В итоге принять взвешенное решение отказаться от этой бесперспективной идеи.
И ещё один пример: в вашем продукте появилась функциональность, до ужаса похожая на функциональность продукта соседней команды. Лид соседней команды организует встречу, чтобы обсудить, кто всё-таки будет её реализовывать, чтобы избежать дублирования логики.
Не норм
Срочно всё похожее передать соседней команде, поставить свои релизы в жёсткую зависимость от её приоритетов, далее при появлении каждой новой задачи приходить к руководителю и говорить: «Мы-то всё сделали, но вот они там ещё долго будут, поэтому результата нет».
Норм
Обсудить плюсы и минусы унифицированного решения. Насколько оно будет гибким? Ускорит ли деливери обеих команд? Как легко масштабируется? И, ответив на эти и другие вопросы, вместе решить, как поступить (чтобы было и дёшево, и надёжно).
Переговоры — это поиск баланса интересов и компромиссов, направленный на достижение осязаемого результата. Старайтесь как можно быстрее гибко находить выходы из любой ситуации, вместо того чтобы создавать новые тупики. Фиксируйте плюсы и минусы всех позиций. Прогнозируйте влияние решения на развитие проекта в долгосрочной перспективе. Пытайтесь понять, что и при каких обстоятельствах может пойти не так.
Несправедливость — это норма
Реальность полна сюрпризов, мир не чёрно-белый — он всегда многогранен и переливается разными оттенками. Надеяться, что все процессы будут всегда максимально рациональными и справедливыми — это точно не путь самурая лида.
В моей практике был случай на эту тему — поиск справедливости в оценке результата. Тимлиду соседней команды ставят KPI. Он всеми силами пытается его достичь, не обращая внимания ни на что больше. И на первый взгляд всё выглядит логично: есть KPI — значит, команда должна его выполнить на 150%. Противоречий тут как будто нет, однако упущен фундаментальный момент — что, помимо этого KPI, есть, к примеру:
стабильность системы,
доступность сервисов,
скорость ответа основных методов API,
текучка кадров,
наём
и т. д.
Все метрики, кроме KPI, при таком подходе сильно проседают. Результаты такой команды, конечно, никто хорошо оценивать не собирался. В итоге тимлиду кажется, что его результат оценён несправедливо, ведь KPI-то достигли, а всё остальное имело для него более низкий приоритет. Причём это произошло с учётом еженедельной обратной связи от его руководителя.
Несправедливо? С точки зрения тимлида — возможно. Но попытки искать справедливость, как правило, обречены на провал. Необходимо и улучшать систему новыми запусками, и поддерживать то, что есть, в хорошем состоянии.
Это лишь один из примеров. Полезно запомнить, что справедливости не существует, и учиться работать в таких условиях.
Тимлид с первого дня работы сталкивается с разными ситуациями:
разработчик очень старается и много работает, но не делает того, что требует задача, при этом просит повышения за свои старания;
бюджет юнита закончился — и нужно решить, кого из команды ротировать, при условии, что этого никто не хочет и вроде бы все молодцы;
клиенты сервиса приходят с идеями, как правильно поступить, решая свои задачи без понимания нюансов продукта;
KPI поставили на полгода, но на пятый месяц ситуация резко изменилась и нужно срочно делать совсем другое;
разные интересанты хотят диаметрально разных фич, реализации которых конфликтуют между собой.
И это всё — только первые несколько часов вашего рабочего дня. Именно поэтому не работает подход «Наберём много разработчиков — они сами как-нибудь справятся». И именно поэтому нужен руководитель, который будет на острие работы с несправедливостью и будет наводить порядок в хаосе. И делать это проще, если вы адекватно оцениваете ситуацию.
Как же оценивать её адекватно?
по возможности больше присутствовать на встречах с руководителями;
следить за вектором развития компании в целом;
стараться видеть дальше своей команды;
узнавать, как что работает у других;
вникать в желания и боли стейкхолдеров.
Чем лучше вы упорядочите окружающую реальность, тем лучше будет чувствовать себя ваша команда и ваша компания.
Расхождение плана и факта
Если ваши цели достигаются на 100%, то они недостаточно амбициозны. Если на 20% — слишком нереалистичны. То же самое можно сказать и про планы. Искусство в том, чтобы научиться сводить план с фактом с минимальным люфтом.
Разберём на примере планирования спринта:
запланировали спринт — и к середине уже всё сделали? Что-то идёт не так;
запланировали спринт — и треть его запланированных работ переехала в другой? Что-то идёт не так;
всё выполнили в срок, обеспечив съезд только одной не очень-то и важной задачи, но команда сбежала от вас через неделю? Всё ещё что-то идёт не так;
всё выполнили в срок, но катили все задачи в последний час спринта? Уже лучше;
всё выполнили в срок и катили задачи равномерно в течение спринта? Вообще хорошо;
всё выполнили в срок, катили задачи равномерно в течение спринта и успели ещё и составить план запусков следующего? Вы супер.
Чтобы добиться результата в планировании, нужно тщательно взвешивать все возможности и риски (о них — далее). В итоге обязательно нужно проводить постанализ фактического результата, сверяя его с планом, и честно стараться найти и решить проблемы. В большинстве случаев они будут не в безделии ваших сотрудников.
Работа с рисками
Дисклеймер: мы не рассматриваем ситуацию с точки зрения кризис-менеджмента. Цель риск-менеджмента — либо минимизировать проблемы, либо вообще не доводить до возникновения по-настоящему кризисной ситуации.
«Уважаемый товарищ тимлид, я срочно поехал к зубному», «Кошке стало плохо — и нужно срочно отвезти её к ветеринару» — риски, которые сложно спрогнозировать. Однако можно и нужно исходить из предположения, что на дистанции форс-мажоры будут в команде происходить.
Сервис N, который давно надо было отрефакторить, внезапно отказал полностью; случился релиз с генерацией новых данных в базе, и они за первый час съели всё место — рутинные технические риски, которые нужно прогнозировать
Периодически выписывайте и структурируйте технические риски вашей системы, планируйте, как и когда их исключать. У вас должны быть список рисков и конкретные задачи по работе с ними со сроками и хотя бы коротким обоснованием того, почему ту или иную проблему не надо решать прямо сейчас.
Когда что-то произошло и команда героически в кратчайшие сроки всё исправила — это круто, но высший пилотаж — не допускать таких ситуаций, а без оценки рисков это крайне сложно.
В крупных компаниях есть много подразделений — и может показаться, что коллеги, отвечающие за информационную безопасность, без вас отработают связанные с ней риски, сетевики — риски чрезмерной нагрузки на сеть, архитекторы скажут, как лучше построить систему, системные аналитики проработают риски непонятных описаний задач и т. д. Но это огромное заблуждение, которое приводит к печальным последствиям.
Любое профильное подразделение смотрит на деятельность компании в целом и улучшает процессы, которые оказывают на неё большое влияние. Однако только вы знаете нюансы работы именно ваших сервисов, и только вы можете ещё в зачатке обработать связанные с ними риски, чтобы они не разрослись до чувствительных проблем для всех.
Обратная связь
Про обратную связь написано множество статьей (например, эта). Но, на мой взгляд, важно помнить одно: её нужно давать системно — и корректирующую, и поддерживающую.
«Ты молодец, отлично сделал задачу N, особенно понравилось, что ты в ней предусмотрел K и при релизе не случилось M».
Приятно ли слышать такие слова? Безусловно. Если подобное реально случилось, на встрече 1:1 обязательно нужно сказать их вашему сотруднику. Такая обратная связь покажет ему, что он всё делал правильно, — и в следующий раз при работе с такой задачей он с большей вероятностью поступит так же. При этом важно не обесценивать похвалу: отмечайте сильные стороны только тогда, когда они действительно есть.
«Мы вчера зарелизили задачу N на две недели позже заявленного срока. При первом релизе произошло K, а в кодовой базе я нашёл подход M, противоречащий нашей конвенции».
Приятно ли такое? Нет. Ни вам, ни вашему сотруднику. Однако это важно сказать и обсудить — умалчивание будет порождать уверенность сотрудника в том, что всё было хорошо и правильно. И в следующий раз это может обернуться куда более серьёзными последствиями для пользователей вашей системы.
Завершая разговор об обратной связи, приведу популярную цитату: «Хвалите публично, ругайте лично» — это правда работает.
Заключение
Тимлид — это человек, который решает проблемы, а не создаёт их. Каждый из упомянутых пойнтов в действительности гораздо шире. Написанное — это только основы для тимлида. В моей практике даже в них случались проблемы. Решения звучат как «Нормально делай — нормально будет», несмотря на это они работают на практике, и я предлагаю внедрять их с самых первых дней работы тимлида. Усвоив эти основы, решать по-настоящему нетривиальные проблемы будет в разы проще.
Запомните их — и добро пожаловать в многогранный мир управления командой разработки! Всё получится — особенно с опытом и набитыми шишками. Но это уже совсем другая история…
