Многие руководители думают, что для управления командой разработки обязательно нужно разбираться в программировании. Хотя важнее понимать, как технические решения влияют на бизнес-метрики, и уметь выстраивать процессы так, чтобы команда работала быстро и эффективно.
В этой статье разберемся, как устроено управление командой разработки изнутри — от ролей и процессов до метрик и инженерных практик. Покажем конкретные инструменты и подходы, которые помогут приблизить компанию к достижению бизнес целей.
Как на команду разработки влияет тимлид и руководитель
Внутри команды разработки обычно есть несколько ключевых ролей: тимлид, проектный менеджер или руководитель команды. Все они управляют процессом разработки, но делают это по‑разному.
Тимлид — человек, который внутри команды отвечает за техническое качество, процессы и работу с людьми. Он следит, чтобы разработчики писали работающий код, на релизе все запускалось без багов и команда всегда действовала слаженно. Часто именно тимлид проводит код‑ревью, помогает новичкам и подсказывает, как лучше реализовать фичу. Он не ставит задачи, а помогает их реализовать.
Менеджер проекта или руководитель группы разработки работает шире. Он управляет сроками, согласовывает цели с бизнесом и связывается с другими отделами. Менеджер проекта отвечает за то, чтобы команда двигалась в нужном направлении и укладывалась в сроки. А если возникают риски или сложности, помогает их решить.
Как устроен полный цикл управления разработкой
Даже если вы не пишете код и не участвуете в разработке напрямую, понимание структуры работы ИТ-команды помогает лучше управлять процессами. Выстраивать реалистичные ожидания, лучше понимать риски и разговаривать с командой на одном языке.
Обычно любой цифровой продукт проходит через пять этапов: Discovery, MVP, Scaling, Support и Sunset.
Discovery. Цель этого этапа — понять, какую проблему решает команда и кому нужен продукт. Здесь собирается исходная информация: потребности пользователей, цели бизнеса, технические ограничения и конкуренты. Команда проводит интервью, рыночные исследования, анализирует поведение пользователей. Выдвигает первые гипотезы и создает концепцию продукта.
Если пропустить этот этап или провести формально, можно создать ненужный продукт. Например, можно вложить ресурсы в сложную CRM-систему, которая в итоге окажется неудобной для отдела продаж и разработку придется свернуть.
MVP. Здесь начинается разработка первой версии продукта. Цель — как можно быстрее запустить работающий продукт, который проверит ключевую гипотезу. Это может быть один основной сценарий: оформить заказ, забронировать встречу или загрузить фото.
Scaling. Если MVP оказался успешным, продукт нужно масштабировать. Добавлять новые функции, обрабатывать больше пользователей и усложнять инфраструктуру. На этом этапе меняются приоритеты. Если на этапе MVP многое можно было делать вручную, то теперь нужны четкие процессы: автоматическое тестирование, мониторинг, логирование, контроль версий и создание документации.
Support. На этом этапе продукт уже работает, но требует постоянной поддержки. Нужно чинить баги, адаптироваться под новые условия, отвечать на запросы пользователей и выкатывать улучшения.
Sunset. Любой продукт когда-нибудь устаревает и его заменяют другим. Бизнес-модель может измениться, а технология — потерять актуальность. Sunset — это заранее спланированный процесс завершения жизни продукта. Сюда входит: сообщение пользователям, когда и как продукт перестанет работать, сохранение или безопасное удаление данных, отключение сервисов и обновление внутренней документации.
Как цикл разработки связан с ролями и управлением
На каждом этапе разработки участвует команда, состав и фокус которой постепенно меняется.
В начале больше работают продакт, аналитик и дизайнер — они исследуют проблему, формулируют гипотезу и придумывают, как это может выглядеть. На этапе MVP в работу включаются разработчики и тестировщики — им важно как можно быстрее собрать первую версию и убедиться, что она вообще работает.
Дальше команда растет и сталкивается с новыми задачами: поддержка, масштабирование, автоматизация, инфраструктура. А на этапе Sunset в работу включаются юристы, службы поддержки и другие специалисты, которых раньше могло не быть вовсе.
При этом на всех этапах с командами работают одни и те же ключевые сотрудники: продакт, тимлид, проджект-менеджер и аналитик.
Продакт определяет, зачем мы делаем продукт, какие задачи и каких пользователей он решает. Это человек, который постоянно держит в голове и рынок, и цели компании, и потребности команды.
Тимлид отвечает за техническую реализацию: помогает разработчикам, принимает архитектурные решения и следит, чтобы команда работала стабильно.
Проджект-менеджер следит за сроками, процессами и коммуникациями. Он фасилитирует встречи, решает организационные проблемы и помогает команде быть синхронизированной.
Аналитик выясняет, как люди пользуются продуктом, помогает расставить приоритеты и оценить, сработала ли гипотеза.
И чтобы все эти люди работали слаженно, нужна продуманная структура рабочих инструментов команды. Это, например:
- бэклог — список задач, идей и фичей, которые еще не сделаны;
- роадмап — общий план на несколько месяцев вперед: что, когда и зачем мы будем делать;
- спринты — короткие отрезки времени (обычно 1–2 недели), в которые команда берет конкретный объем работы;
- метрики и отчеты — чтобы команда и руководители видели и прогресс и проблемные места.
Бэклог продукта в таск-трекере Kaiten
Понимание цикла разработки и умение работать с инструментами распределения задач помогает лучше распределять роли, не мешать команде, и в нужный момент подключаться там, где от менеджера действительно есть польза.
Как ставить цели команде разработки, чтобы они приносили результат
В ИТ-разработке часто бывает так: команда вроде бы работает, задачи есть, процессы идут, а результата нет. Точнее — он вроде есть, но не тот, на который рассчитывал бизнес. Причина в том, что команда не ориентирована на бизнес-цели. Она делает что умеет, а не то, что действительно важно для компании.
Команда может тратить спринты на красивую анимацию или рефакторинг, который никто не просил. А в это время реальная проблема бизнеса, например, отток пользователей, будет оставаться без внимания.
Чтобы этого не происходило, нужно связать три уровня:
- стратегию компании;
- цели продукта;
- работу команды разработки.
Начинается все со стратегии. Например, у бизнеса может быть цель «увеличить выручку на 30% за полгода». Из нее вытекает следующая цель: «увеличить количество повторных покупок». А уже на уровне продукта это может выражаться в конкретной задаче: «реализовать рекомендательную систему, которая показывает клиенту сопутствующие товары». Только после этого задача попадает в спринт: «добавить блок “Вам может понравиться” на карточку товара».
Так одна небольшая задача на фронтенде начинает цепочку, которая ведет к росту выручки.
Чтобы подобная связка работала, нужны понятные и рабочие инструменты. Вот три самых подходящих из них:
OKR (Objectives and Key Results) — методика, которая помогает команде ставить цели. В ней есть цель — качественное описание того, к чему стремится компания, и ключевые результаты — как команда поймет, что приближается к этой цели.
Читайте также: «Что такое OKR? Определение и примеры»
Impact Map — инструмент, который помогает визуально связать действия команды с целями бизнеса. В центре карты — цель. Дальше — кто может повлиять на эту цель (например, клиенты, менеджеры, партнеры), их поведение, и только потом — фичи, которые могут изменить это поведение.
К примеру, у компании есть цель «сократить стоимость поддержки на 20%». На достижение цели влияют пользователи, которые часто пишут в саппорт. Задача — изменить их поведение. То есть сделать так, чтобы они реже приходили с вопросами. Добиться этого можно через внедрение базы знаний, улучшение FAQ и добавление подсказок на сайте.
Product Tree — способ посмотреть на продукт в целом и понять, куда он развивается. Суть способа простая: нужно представить, что продукт — это дерево. Ствол — его основа, то, ради чего пользователи вообще пришли. Ветви — текущие функции, листья — то, что можно улучшить, доработать или создать. Это помогает увидеть, в какую сторону развивается продукт: где все уже продумано хорошо, а где, наоборот, функций или возможностей недостаточно.
Если команда не видит связи между задачами и целями, это может только навредить бизнесу.
К примеру, в интернет-магазине сделали редизайн главной страницы. Добавили новую анимацию, переработали каталог и осовременили сам сайт. В результате время на странице выросло и это вроде бы хорошо. Но через два месяца продажи упали.
Оказалось, что путь до кнопки «Купить» стал менее очевидным, а сама кнопка — менее заметной. Из-за этого заказать товары стало сложнее и большинство покупателей отваливалось на этапе оплаты. А все потому, что команда не проверила, как изменения повлияют на конверсии и не задалась простым вопросом: «А как это поможет нам продавать больше?»
Как настроить рабочие процессы внутри команды разработки
В ИТ-командах чаще всего встречаются три варианта: Scrum, Kanban и гибридные модели. Каждый из них подходит под свою ситуацию.
Scrum — это метод, в котором работа разбивается на фиксированные короткие отрезки — спринты. Обычно они длятся 1–2 недели. В начале каждого спринта команда планирует задачи, которые точно готова сделать за это время. Эти задачи не меняются до конца спринта — даже если в середине недели бизнес попросил срочно переделать что-то еще.
Какие метрики помогают оценить эффективность команды разработки
Одна из задач руководителя — понимать, как работает команда, и видеть точки роста. Для этого стоит использовать метрики. Их условно делят на две группы: leading и lagging. Leading-метрики — опережающие. Они показывают, как команда работает сейчас, и позволяют прогнозировать результат. Lagging — запаздывающие. Они фиксируют уже случившееся.
Например, количество реализованных фич за квартал — это lagging-метрика, на нее уже нельзя повлиять. А вот cycle time или количество открытых багов — это leading-метрики. Их можно наблюдать в процессе и корректировать по ходу.
Есть еще 2 популярные метрики — velocity (скорость выполнения задач) и cycle time (время выполнения задачи/проекта).
Проблема velocity в том, что она показывает, сколько задач команда закрыла за спринт. Но не говорит, насколько эти задачи были сложными или полезными. Можно делать много мелких задач ради красивой цифры и при этом не двигаться по-настоящему важным направлениям.
Поэтому гораздо больше информации дает cycle time — время от момента, когда задача попала в работу, до момента готовности. Эту метрику можно отслеживать по каждой задаче. Если cycle time начинает расти, значит где-то в процессе есть узкое место. Например, задачи висят на ревью, тестировании, или долго ждут выкладки в прод.
Читайте также: «Ключевые показатели Scrum: 7 метрик, которые помогают оценить эффективность в Agile»
Кроме метрик стоит оценивать качество кода и релизов. Это можно отслеживать через:
- количество багов, найденных на проде;
- количество откатов релизов;
- количество инцидентов после обновлений;
- соотношение между баг-фиксом и новой функциональностью в спринте.
Главное — не просто отслеживать метрики, а использовать их для улучшения процессов в компании. Команда должна регулярно находить слабые места, обсуждать проблемы, вносить небольшие изменения и проверять результат. Например, если вырос cycle time, вводить WIP-лимиты или ускорять ревью, а потом отслеживает изменения.
Инженерные IT-практики для неинженеров
Чтобы выстроить нормальную работу с технической командой, не нужно учиться писать код. Но важно хотя бы в общих чертах понимать, как живет задача внутри команды: с чего все начинается, какие шаги проходит, что может ее задержать и где можно повлиять на процесс.
Обычно все начинается с Git — системы, где разработчики хранят и редактируют код. Она позволяет им работать параллельно: одному делать форму входа, другому — форму регистрации. Работа ведется в отдельных ветках, а потом промежуточные результаты объединяются в один общий. Если в одном и том же месте разработчики поменяли одно и то же — Git покажет конфликт и попросит вручную выбрать правильную версию.
Перед слиянием изменений в основную версию проходит code review — проверка кода другим разработчиком. Это защищает от ошибок, помогает поддерживать единый стиль кода в команде и развивать навыки программистов. Разработчик, который читает чужой код, лучше понимает устройство проекта и все взаимосвязи. А команда в целом работает увереннее.
Менеджеру знание принципов Git и code review помогает понимать, на каком этапе сейчас задача и почему она может задерживаться. Например, задача может зависнуть из-за нерешенного конфликта в коде или потому что она долго ждет проверки от коллег.
Дальше вступает в работу автоматизация — CI и CD. CI иначе можно назвать «автоматической проверкой». Как только разработчик отправляет свои изменения, система запускает цепочку тестов. Она проверяет, что ничего не сломалось: все страницы загружаются, кнопки работают, а данные сохраняются как надо. Параллельно система может собирать продукт — например, делать из набора файлов уже готовое веб-приложение или мобильную версию.
Если все прошло успешно, запускается CD — автоматическая доставка изменений. Код загружается либо в специальное тестовое пространство (где можно все проверить на живом примере), либо сразу в рабочую версию — ту, с которой взаимодействуют реальные пользователи.
Зачем все это знать управленцу
Если вы руководите проектом или продуктом, вам не обязательно знать Git наизусть. Но понимать, как работает этот цикл, важно. Это помогает точнее планировать сроки, вовремя замечать узкие места и заранее понимать, где может застревать задача. А если вы, например, знаете, как устроена доставка изменений (CD), вам будет проще обсуждать с командой релизы и понимать, насколько стабильно выкатываются фичи.
Эти знания — только верхушка айсберга. В реальной работе инженерных практик намного больше, и каждая из них может серьезно повлиять на скорость и качество разработки.
Например, как объяснить бизнесу, почему команде нужно время на рефакторинг, и перевести это на язык денег. Либо, что делать, если у разработчиков много технического долга и вы не понимаете, сколько это стоит и насколько критично.
Чтобы уверенно управлять техническими командами и говорить с разработчиками на одном языке нужно системное понимание того, как устроена современная разработка изнутри.
Для этого мы создали тренинг «Инженерные IT-практики для неинженеров». За 8 модулей вы получите практические навыки работы с Git, настроите собственный CI/CD пайплайн и научитесь оценивать качество технических процессов в команде. Вас ждет много теории и практики.
После тренинга вы сможете:
самостоятельно оценивать техническую готовность кандидатов на собеседованиях;
понимать, почему релиз задерживается, и находить реальные узкие места;
говорить с командой на одном языке и завоевать доверие разработчиков;
принимать взвешенные решения об инвестициях в качество и скорость разработки.
Узнать подробности и записаться на тренинг
Следующий поток стартует уже 12 августа. Места ограничены — в группе не более 12 человек, чтобы каждый получил персональную обратную связь от тренеров-практиков.
