Есть огромное количество рекомендаций, что делать и чего не делать при организации IT‑команды. Про Scrum и Agile best practices знают практически все, кто имеет хоть какое‑то отношение к IT. Проблема в том, что большинство советчиков — это Scrum‑мастера, которые никогда не руководили командами и поэтому слабо представляют, как соотносятся их рекомендации с реальной жизнью.
Мой совокупный опыт как технического менеджера‑руководителя — больше 6 лет. На текущей позиции я собрал с нуля и организовал две команды. Ранее в компании «Юзтех» я был замом технического директора с сотнями людей в подчинении, а в «Сбербанке» как глава департамента управлял 7 большими группами на 150 человек. Я отшлифовал популярные идеи о создании IT‑команд на реальных проектах и теперь рад поделиться своим опытом.
Типовые ошибки в организации работы IT-команды
Каждый раз на мой вопрос о том, кто, что и в какое время должен делать, IT‑менеджеры отвечают что‑то невразумительное. Даже прославленные Scrum‑мастера не имеют полных инструкций с описанием этапов работы в команде, распределением обязанностей и сроками их выполнения. А это напрямую влияет на результат разработки.
Без заранее выстроенного плана команды вынужденно самоорганизуются в попытке запустить хоть какие‑то процессы. В большинстве случаев это приводит к тому, что стадия высокой производительности даже в маленьких командах наступает в лучшем случае через 4–6 месяцев после старта работы, а это большие финансовые потери для компании.
Рисунок 1. Стадии организации команды
![](https://habrastorage.org/getpro/habr/upload_files/062/254/b80/062254b807ae2d543285c1705054c364.png)
На рисунке видно, что около полугода уходит на этап формирования команды (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-а из идеи продукта.
![](https://habrastorage.org/getpro/habr/upload_files/ce0/fcd/f41/ce0fcdf4182cd9a247b4bb2e33bb387e.png)
Роли участников команды
Для слаженной работы всей команды важно четко определить зоны ответственности каждого участника.
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. Процесс формирования краткосрочного плана спринта
![](https://habrastorage.org/getpro/habr/upload_files/044/984/15e/04498415e8b601e1cac4997ed4ddfb7e.png)
Ежедневные созвоны – лишняя трата времени или необходимость?
На Stand Up встречах каждый проговаривает выполненные задачи за прошлый день, озвучивает планы на сегодняшний день и рассказывает про текущие проблемы, чтобы получить помощь от коллег.
Я неоднократно наблюдал концепцию отказа от Stand Up в пользу отправки в чат ежедневных отчетов каждого члена команды. Зачастую это приводило к довольно серьезным рассинхронизациям внутри команды. Если членам команды некомфортно встречаться каждый день, что крайне желательно, то я бы рекомендовал все равно запланировать хотя бы 2 Stand Up в неделю.
Не затягивайте эти встречи больше чем на 15–20 минут, чтобы они были не обременительны для сотрудников. Stand Up важны не только для синхронизации, но и для чувства дружеского плеча, где каждый член команды может рассчитывать на взаимную поддержку и помощь. Это слаживает команду и дает здоровый рабочий настрой. Сам факт укрепления команды во время Stand Up, на мой взгляд, является очень важным. Без доверия и поддержки на стадию Performing выходят не все.
Итак, что нужно для запуска разработки:
Выработать User Scenario.
Cделать дизайн‑скетчи экрана.
Прописать и передать в разработку User Stories.
Ежедневно проводить Stand Up встречи и 2–3 раза в неделю Grooming сессии.
Понравилась статья? Поделитесь ей с теми, кто управляет работой IT‑команды или хочет этому научиться.
Комментарии (2)
quaer
13.07.2023 08:58Вроде и хорошо написано, но не очень понятно, если не глубоко в теме :(
Обычно Project Manager (PM) или Product Analyst (PA), реже сам PO,
погружается в конкретный User Scenario и нарезает его на множество User
Stories.Какие понятия вы вкладываете в эти сочетания букв? Даже при использовании общеизвестных слов приходится уточнять их смысл в контексте, а тут сразу иероглифы.
Не может быть так, что если разговаривать на более понятном языке, то процесс создания команды ускорится, а работа улучшится?
ermadmi78
Очень хорошая и нужная статья. Спасибо. Рассказываете вы, по сути, азбучные истины управления разработкой, но именно понимания азбучных истин современному менеджменту катастрофически не хватает.
Я, в последнее время, чаще встречаюсь с тем, что команды ломаются даже не доходя до этапа storming. Просто потому, что менеджмент не в состоянии ответить на вопрос "что делать?". Про User Stories я вообще молчу - увидеть вменяемый роадмап и беклог - это из разряда фантастики :)
Еще рекомендовал бы формализовать процесс декомпозиции бизнес задач из беклога User Stories в технические задачи. Связь между ними далеко не такая очевидная, как кажется на первый взгляд. Одна "бизнес задача" может распадаться на несколько технических, и одна техническая задача может требоваться для закрытия нескольких бизнес задач. В сложных проектах имеет смысл вести 2 беклога - бизнес задачи и технические задачи.
Дополнительно очень рекомендую вести беклог "Технический долг". Любой проект на этапе создания MVP для ускорения "берет в долг" у мироздания. Где то срезали угол, где то сделали неоптимально, где то пожертвовали нефункциональными требованиями (отказоустойчивость, масштабируемость), где то не заложили фундамент под планируемое развитие проекта и т.д. и т.п. Технический долг - это нормально. Без него практически нереально запустить разработку. Но очень важно уметь управлять техническим долгом. Первый шаг в управлении - это формализация долга. На каждом этапе развития проекта вы должны очень четко понимать, что вы должны мирозданию. Второй шаг - это составить план погашения долгов. Роадмап выплат по долгу так сказать. Когда и на каких этапах мы будем возвращать долги мирозданию? Ну и третий шаг - проявить силу воли и возвращать долги в соответствии с планом, даже если этого очень сильно не хочется делать. Если вы не управляете техническим долгом, то рано или поздно технический долг начнет управлять вами.