«Нужно больше минералов людей!» — частая реакция на отставание проекта от дедлайнов. Но что делать, когда увеличение команды не только не решает проблему, но и усугубляет ее?
В конце 2022 года наша команда столкнулась с задачей — разработать новый личный кабинет заемщика для ипотечных клиентов банка. Масштаб изменений требовал серьезных ресурсов, мы пошли по классическому пути — собрали большую команду из 20 с лишним человек, но вместо ожидаемого ускорения получили обратный эффект.
Эта история о том, как мы обнаружили, что «больше» не всегда значит «лучше», и как простое решение по реорганизации команды помогло нам не только уложиться в сроки, но и повысить качество работы.
Меня зовут Игорь Котов, я СТО стрима Ипотека, и в этой статье я поделюсь историей о том, как забуксовала большая команда, как мы диагностировали проблему и какие решения нам помогли все решить. Наш опыт может быть полезен тем из вас, перед кем стоит похожий вопрос — как ускорить разработку, не увеличивая команду?
Как все начиналось
От современного банка клиенты ждут современных сервисов. А как вы уже поняли из вступления, наш процесс подачи заявки на ипотеку был немного устаревшим. Поэтому в прошлом году было решено сделать удобный и современный личный кабинет заемщика. Вот что в нем должно было быть:
- заполнение заявки в онлайн-формате с возможностью сохранить черновик и вернуться к его заполнению в удобное время;
- прозрачное отслеживание статуса рассмотрения заявки;
- возможность добавление созаемщиков;
- загрузка и обновление документов;
- доступ к кабинету с любого устройства через авторизацию по номеру телефона.
План был логичен и прост: собрать команду опытных специалистов, выстроить поэтапный подход к разработке, к осени 2023-го — MVP, затем последовательное добавление фич и релиз полного решения в конце года.
Стартовый состав и организация
К маю была окончательно собрана команда, в которую вошло больше 20 человек. Ядро команды составили опытные инженеры, хорошо знакомые с продуктом и спецификой, к ним присоединились новые специалисты, недавно пришедшие в банк. Команду усилили аналитиками, тестировщиками и сотрудниками с другими необходимыми ролями.
Работу организовали по классическим agile-принципам: двухнедельные спринты с дейли для синхронизации. В конце каждой итерации демо и ретро. Декомпозиция на отдельные фичи и user stories, чтобы сделать разработку более управляемой.
На бумаге все выглядело правильно: большая команда, четкий процесс разработки, понятные цели. Но несколько спринтов спустя стало понятно, что что-то идет не так. Оценки по срокам постоянно не совпадали с реальностью, задачи переносились из спринта в спринт…
К сентябрю, когда мы выпустили-таки MVP, стали ясны две вещи:
а) команда почти выгорела,
б) при текущем подходе зарелизить кабинет в срок не удастся.
Когда размер имеет значение: подводные камни большой команды
Мы стали разбираться, что пошло не так. Одной из проблем, на которую вышли почти сразу, оказались непомерно разросшиеся командные ритуалы. Дейли превратились в пытку: они занимали более 40 минут, при этом каждый участник говорил всего 1–2 минуты.
Получалось, что большую часть времени люди просто ждали своей очереди, а потом слушали обновления, которые часто их напрямую не касались. В команде из 20+ человек такие потери времени существенны — суммарно все тратили больше 13 часов в неделю только на дейли-митинги.
Вторая проблема оказалась менее очевидной, но более серьезной — низкая вовлеченность части команды. В большом коллективе, где были как опытные разработчики, так и новички, возникла возможность «отсидеться за спинами» более активных коллег. Одни перестали предлагать свои идеи, полагая, что «Вася — эксперт, а эксперты лучше знают». Другие не спешили глубоко погружаться в продукт, ведь есть условный Вася, который в случае чего подскажет решение.
Третья проблема — отсутствие фокуса. При таком размере команды оказалось практически невозможно сконцентрироваться на одной конкретной цели спринта. Мы пытались параллельно двигать несколько крупных фич, что приводило к распылению внимания и ресурсов. В результате задачи регулярно «переезжали» из спринта в спринт, подрывая веру в возможность достижения конечной цели в срок.
От монолита к микросервисам
В процессе поиска выхода из ситуации мы перебрали несколько гипотез. Причем идею с наймом новых сотрудников отмели практически сразу — чтобы погрузить нового человека в проект, нужно 3–4 месяца, которых у нас нет. Плюс придется на ходу решать проблемы с коммуникацией и координацией, которые неизбежно возникнут при расширении команды.
Поэтому мы решили попробовать разобраться с проблемой по-другому. Вместо набора новых специалистов разделили большую команду на три миникоманды. Каждая получила свою четкую зону ответственности: одна занялась разработкой функций по работе с созаемщиками, вторая — модулем загрузки и обработки документов, а третья — полной версией анкеты заемщика.
Каждая команда получила полный набор компетенций для автономной работы над своей частью продукта, были четко определены точки интеграции. Составы команд мы перемешали, в каждую вошли как старожилы, так и новички.
Несмотря на разделение, мы сохранили механизмы для координации работы. В конце каждого спринта проводили общее демо, где команды делились результатами и обсуждали вопросы интеграции. Это помогало поддерживать единое видение продукта и обеспечивало согласованность решений.
Так как каждая миникоманда получила четкую цель, это кардинально изменило подход к планированию спринтов: теперь вместо множества параллельных задач команда могла сосредоточиться на чем-то конкретном.
Мы понимали, что меняем устоявшиеся процессы и выводим людей из зоны комфорта. Но уже первые два спринта после разделения показали, что решение было верным.
Результаты
Компактный размер команд радикально повысил эффективность коммуникации: дейли стали занимать не больше 15 минут, на планирование спринта хватало часа, а ретро стали более откровенными и конструктивными: отсидеться больше не получалось — каждый чувствовал личную ответственность за результат.
Четкое разделение целей тоже дало результат: задачи перестали «переезжать» из спринта в спринт, потому что теперь каждая команда могла точнее оценивать свои возможности и планировать работу. Процесс разработки стал более предсказуемым.
Главным подтверждением эффективности нового подхода стал запуск полной версии личного кабинета заемщика в намеченный срок — до конца 2023 года. Мы не только не пролетели мимо дедлайнов, но и реализовали все запланированные фичи.
От теории к практике: как применить наш опыт
Наш эксперимент с разделением большой команды начинался как вынужденная мера, но превратился в системный подход к организации работы (сейчас другие команды нашего стрима тоже начали его перенимать).
Попробую дать несколько советов о том, как определить, что вашей команде необходимо «дробление», и какие основные принципы использовать при создании миникоманд.
Итак, если вы видите, что:
- встречи регулярно затягиваются, а их эффективность падает;
- часть команды не проявляет инициативы и «отсиживается» за более активными коллегами;
- задачи постоянно переносятся между спринтами;
- команде сложно сфокусироваться на конкретных целях;
- все чаще возникает желание (и слышатся призывы) решить проблему наращиванием численности команды…
…самое время собрать ретро и попытаться докопаться до того, с какого момента все пошло не так и почему все идет так, как идет. Возможно (!), то, о чем я пишу, не ваш случай, но если вышеописанные признаки совпадают с вашей ситуацией, имеет смысл подумать о пересборке процесса и распределить зоны ответственности по миникомандам.
Главное при этом — соблюдать несколько простых правил.
- Четко разделите ответственность
Каждая команда должна иметь ясную, самостоятельную цель и зону ответственности. - Сбалансируйте компетенции
Важно обеспечить каждую команду полным набором компетенций, «равномерно распределив» участников. - Сохраните синхронизацию
Регулярные общие демо и четкие точки интеграции помогают командам двигаться в одном направлении. - Поддерживайте инициативу
В небольших командах важно создать атмосферу, где каждый участник чувствует себя значимым и не боится предлагать идеи (и с миникомандой добиться этого на самом деле гораздо проще, чем в большой группе).
Напоследок еще раз оговорюсь: каждый проект уникален, и прямое копирование чужого опыта не обязательно приведет к успеху. Но базовые принципы, которые мы применили, — разделение большой команды на автономные группы с четким фокусом — могут быть адаптированы практически для любой ситуации, где требуется повысить эффективность разработки.
Читать первым в Telegram-канале «Код Дурова»
