Есть огромное количество рекомендаций, что делать и чего не делать при организации IT‑команды. Про Scrum и Agile best practices знают практически все, кто имеет хоть какое‑то отношение к IT. Проблема в том, что большинство советчиков — это Scrum‑мастера, которые никогда не руководили командами и поэтому слабо представляют, как соотносятся их рекомендации с реальной жизнью.

Мой совокупный опыт как технического менеджера‑руководителя — больше 6 лет. На текущей позиции я собрал с нуля и организовал две команды. Ранее в компании «Юзтех» я был замом технического директора с сотнями людей в подчинении, а в «Сбербанке» как глава департамента управлял 7 большими группами на 150 человек. Я отшлифовал популярные идеи о создании IT‑команд на реальных проектах и теперь рад поделиться своим опытом.

Типовые ошибки в организации работы IT-команды

Каждый раз на мой вопрос о том, кто, что и в какое время должен делать, IT‑менеджеры отвечают что‑то невразумительное. Даже прославленные Scrum‑мастера не имеют полных инструкций с описанием этапов работы в команде, распределением обязанностей и сроками их выполнения. А это напрямую влияет на результат разработки.

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

Рисунок 1. Стадии организации команды

На рисунке видно, что около полугода уходит на этап формирования команды (forming). Потом команда снова застревает на этапе storming. Люди чувствуют проблему и не знают, как ее решить, обвиняя друг друга в недоработках. Это приводит к скорому развалу команды и необходимости заново собеседовать и набирать людей.

В среднем процесс найма сильной и компетентной команды из 5 человек занимает полгода. Еще полгода уходит на forming и storming. Чаще всего неорганизованная команда разваливается после года совместной работы, и тогда приходится возвращаться на этапа найма.

Планирование разработки

Менеджмент любой IT‑команды делится на формирование долгосрочного видения и создание краткосрочных процессов разработки внутри команды.

Долгосрочной стратегией обычно занимаются Product Owner (PO) и UI/UX Designer (Designer). PO определяет, что и в какие сроки нужно сделать, а Designer помогает сформировать базовое видение интерфейса и выделить основные User Scenarios — сценарии взаимодействия пользователя с продуктом.

На их основе создаются базовые скетчи будущего дизайна. А на основе User Scenarios и дизайна формируются User Stories — маленькие нарезки функционала, необходимые для воплощения конкретного User Scenario.

Обычно Project Manager (PM) или Product Analyst (PA), реже сам PO, погружается в конкретный User Scenario и нарезает его на множество User Stories. Затем User Stories выстраиваются в цепочку задач в зависимости от их приоритетности. Совокупность User Stories в приоритезированном виде и называется Backlog. Это список функционала, который предстоит сделать.

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

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

Рис 2. Процесс формирования Backlog-а из идеи продукта.

Роли участников команды

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

PO отвечает за конечный успех продукта, формирует Product Vision и участвует в разработке User Scenarios. При этом он не обязан быть основным действующим лицом, формирующим пользовательские сценарии.

PA формирует User Scenarios и User Stories. Если для этой роли нет отдельного человека, это делает PM. Если и для роли PM нет человека, то PO.

PM формирует Milestones, лавируя между возможностями команды и интересами бизнеса. Milestones — это план реализации продукта, за который наш PM отвечает перед PO.

Как организовать работу команды

Краткосрочное планирование и начало разработки становится возможным, когда сформирован Backlog как минимум на 1–2 спринта вперед. Обычно на один спринт отводится 2 недели. Если уменьшить срок, то периодические активности спринта отнимают до 50% времени разработчиков, что чрезвычайно много. Если делать длину спринта больше 2-х недель, то начинается рассинхрон между членами команды, и производительность разработчиков падает. Чем длиннее спринт, тем ниже производительность.

Так как же выглядят периодические активности команды в рамках каждого спринта? Каждый спринт начинается с Planning‑а всей командой. Это нужно, чтобы каждый знал, кто и что будет делать.

Идеальный Planning должен занимать не более 1–1.5 часов. Это возможно, только когда команда:

• знает свою производительность;

• подробно проанализировала каждую задачу;

• понимает, как все они должны быть реализованы.

На Planning нужно приходить с понятными всем задачами. Тогда на встрече останется только раздать их каждому члену команды, в зависимости от его зоны ответственности. Чаще всего обсуждение деталей происходит на Grooming сессиях в рамках периодических активностей предыдущего спринта. Рекомендуется делать 2–3 Grooming сессии по 1–1.5 часа на протяжении каждого спринта.

Самая частая ошибка в Planning технических менеджеров — включение всех сессий Grooming‑а, растягивающее одну встречу на 4–6 часов. От длительных групповых совещаний люди утомляются, и уже после 2-х часов эффективность коммуникации значительно снижается. Встреча длиной более 4-х часов не имеет смысла.

На Grooming встречах должны присутствовать все члены команды, чтобы у всех было общее понимание будущих технических решений и причин их принятия. В противном случае могут возникать споры между членами команды. На этих встречах рассматривается как реализация задачи во время спринта, так и сам процесс формирования технических задач на основе User Stories. В эссе Б. Франка «Путь к богатству» есть всем известная фраза: «Time is money». В нашем случае это значит, что время каждого сотрудника стоит денег, поэтому руководители стремятся уменьшить количество Grooming встреч.

Самый эффективный способ уменьшить затраты команды на Grooming сессии — это проводить раз в спринт встречу PM‑а и Team Lead‑а (TL), чтобы синхронизировать долгосрочные планы на команду, оценить риски невыполнения этих задач в срок и уравнять все технические риски. В этом случае на Grooming сессии TL будет приходить с уже частично проработанным видением технических задач. Это сэкономит время команды на Grooming сессиях.

Во многих западных источниках пишут, что Grooming и Backlog Refinement (встречи с участием PO и TL) — это одно и то же, но с моей субъективной точки зрения это не так.

Grooming сессии нужны для детальной проработки User Stories и технических задач, в том числе задач технического долга.

Backlog Refinement помогает выявить риски реализации долгосрочных планов и найти решения, чтобы сгладить их в рамках спринтов. В том числе это про отказ от правильных технических решений в пользу быстрых «костыльных» решений. Backlog Refinement напрямую влияет на то, какие задачи будут рассматриваться на Grooming сессиях.

Рис 3. Процесс формирования краткосрочного плана спринта

Ежедневные созвоны – лишняя трата времени или необходимость?

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

Я неоднократно наблюдал концепцию отказа от Stand Up в пользу отправки в чат ежедневных отчетов каждого члена команды. Зачастую это приводило к довольно серьезным рассинхронизациям внутри команды. Если членам команды некомфортно встречаться каждый день, что крайне желательно, то я бы рекомендовал все равно запланировать хотя бы 2 Stand Up в неделю.

Не затягивайте эти встречи больше чем на 15–20 минут, чтобы они были не обременительны для сотрудников. Stand Up важны не только для синхронизации, но и для чувства дружеского плеча, где каждый член команды может рассчитывать на взаимную поддержку и помощь. Это слаживает команду и дает здоровый рабочий настрой. Сам факт укрепления команды во время Stand Up, на мой взгляд, является очень важным. Без доверия и поддержки на стадию Performing выходят не все.

Итак, что нужно для запуска разработки:

1. Выработать User Scenario.

2. Cделать дизайн‑скетчи экрана.

3. Прописать и передать в разработку User Stories.

4. Ежедневно проводить Stand Up встречи и 2–3 раза в неделю Grooming сессии.

Понравилась статья? Поделитесь ей с теми, кто управляет работой IT‑команды или хочет этому научиться.