Dec 16, 2024 • 20:20

Больше ≠ лучше: как ускорить разработку, не увеличивая команду

Dec 16, 2024 • 20:20

Данная страница содержит «вставки» с других сайтов, скрипты которых могут собирать ваши личные данные для аналитики и своих внутренних потребностей. Редакция рекомендует использовать браузеры с блокировкой трекеров для просмотра таких страниц. Подробнее →

«Нужно больше минералов людей!» — частая реакция на отставание проекта от дедлайнов. Но что делать, когда увеличение команды не только не решает проблему, но и усугубляет ее?

В конце 2022 года наша команда столкнулась с задачей — разработать новый личный кабинет заемщика для ипотечных клиентов банка. Масштаб изменений требовал серьезных ресурсов, мы пошли по классическому пути — собрали большую команду из 20 с лишним человек, но вместо ожидаемого ускорения получили обратный эффект.

Эта история о том, как мы обнаружили, что «больше» не всегда значит «лучше», и как простое решение по реорганизации команды помогло нам не только уложиться в сроки, но и повысить качество работы.

Меня зовут Игорь Котов, я СТО стрима Ипотека, и в этой статье я поделюсь историей о том, как забуксовала большая команда, как мы диагностировали проблему и какие решения нам помогли все решить. Наш опыт может быть полезен тем из вас, перед кем стоит похожий вопрос — как ускорить разработку, не увеличивая команду?

Как все начиналось

От современного банка клиенты ждут современных сервисов. А как вы уже поняли из вступления, наш процесс подачи заявки на ипотеку был немного устаревшим. Поэтому в прошлом году было решено сделать удобный и современный личный кабинет заемщика. Вот что в нем должно было быть:

заполнение заявки в онлайн-формате с возможностью сохранить черновик и вернуться к его заполнению в удобное время;

прозрачное отслеживание статуса рассмотрения заявки;

возможность добавление созаемщиков;

загрузка и обновление документов;

доступ к кабинету с любого устройства через авторизацию по номеру телефона.

План был логичен и прост: собрать команду опытных специалистов, выстроить поэтапный подход к разработке, к осени 2023-го — MVP, затем последовательное добавление фич и релиз полного решения в конце года.

Стартовый состав и организация

К маю была окончательно собрана команда, в которую вошло больше 20 человек. Ядро команды составили опытные инженеры, хорошо знакомые с продуктом и спецификой, к ним присоединились новые специалисты, недавно пришедшие в банк. Команду усилили аналитиками, тестировщиками и сотрудниками с другими необходимыми ролями.

Работу организовали по классическим agile-принципам: двухнедельные спринты с дейли для синхронизации. В конце каждой итерации демо и ретро. Декомпозиция на отдельные фичи и user stories, чтобы сделать разработку более управляемой.

На бумаге все выглядело правильно: большая команда, четкий процесс разработки, понятные цели. Но несколько спринтов спустя стало понятно, что что-то идет не так. Оценки по срокам постоянно не совпадали с реальностью, задачи переносились из спринта в спринт…

К сентябрю, когда мы выпустили-таки MVP, стали ясны две вещи:

а) команда почти выгорела,
б) при текущем подходе зарелизить кабинет в срок не удастся.

Когда размер имеет значение: подводные камни большой команды

Мы стали разбираться, что пошло не так. Одной из проблем, на которую вышли почти сразу, оказались непомерно разросшиеся командные ритуалы. Дейли превратились в пытку: они занимали более 40 минут, при этом каждый участник говорил всего 1–2 минуты.

Получалось, что большую часть времени люди просто ждали своей очереди, а потом слушали обновления, которые часто их напрямую не касались. В команде из 20+ человек такие потери времени существенны — суммарно все тратили больше 13 часов в неделю только на дейли-митинги.

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

Третья проблема — отсутствие фокуса. При таком размере команды оказалось практически невозможно сконцентрироваться на одной конкретной цели спринта. Мы пытались параллельно двигать несколько крупных фич, что приводило к распылению внимания и ресурсов. В результате задачи регулярно «переезжали» из спринта в спринт, подрывая веру в возможность достижения конечной цели в срок.

От монолита к микросервисам

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

Поэтому мы решили попробовать разобраться с проблемой по-другому. Вместо набора новых специалистов разделили большую команду на три миникоманды. Каждая получила свою четкую зону ответственности: одна занялась разработкой функций по работе с созаемщиками, вторая — модулем загрузки и обработки документов, а третья — полной версией анкеты заемщика.

Каждая команда получила полный набор компетенций для автономной работы над своей частью продукта, были четко определены точки интеграции. Составы команд мы перемешали, в каждую вошли как старожилы, так и новички.

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

Так как каждая миникоманда получила четкую цель, это кардинально изменило подход к планированию спринтов: теперь вместо множества параллельных задач команда могла сосредоточиться на чем-то конкретном.

Мы понимали, что меняем устоявшиеся процессы и выводим людей из зоны комфорта. Но уже первые два спринта после разделения показали, что решение было верным.

Результаты

Компактный размер команд радикально повысил эффективность коммуникации: дейли стали занимать не больше 15 минут, на планирование спринта хватало часа, а ретро стали более откровенными и конструктивными: отсидеться больше не получалось — каждый чувствовал личную ответственность за результат.

Четкое разделение целей тоже дало результат: задачи перестали «переезжать» из спринта в спринт, потому что теперь каждая команда могла точнее оценивать свои возможности и планировать работу. Процесс разработки стал более предсказуемым.

Главным подтверждением эффективности нового подхода стал запуск полной версии личного кабинета заемщика в намеченный срок — до конца 2023 года. Мы не только не пролетели мимо дедлайнов, но и реализовали все запланированные фичи.

От теории к практике: как применить наш опыт

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

Попробую дать несколько советов о том, как определить, что вашей команде необходимо «дробление», и какие основные принципы использовать при создании миникоманд.

Итак, если вы видите, что:

встречи регулярно затягиваются, а их эффективность падает;

часть команды не проявляет инициативы и «отсиживается» за более активными коллегами;

задачи постоянно переносятся между спринтами;

команде сложно сфокусироваться на конкретных целях;

все чаще возникает желание (и слышатся призывы) решить проблему наращиванием численности команды…

…самое время собрать ретро и попытаться докопаться до того, с какого момента все пошло не так и почему все идет так, как идет. Возможно (!), то, о чем я пишу, не ваш случай, но если вышеописанные признаки совпадают с вашей ситуацией, имеет смысл подумать о пересборке процесса и распределить зоны ответственности по миникомандам.

Главное при этом — соблюдать несколько простых правил.

Четко разделите ответственность
Каждая команда должна иметь ясную, самостоятельную цель и зону ответственности.
Сбалансируйте компетенции
Важно обеспечить каждую команду полным набором компетенций, «равномерно распределив» участников.
Сохраните синхронизацию
Регулярные общие демо и четкие точки интеграции помогают командам двигаться в одном направлении.
Поддерживайте инициативу
В небольших командах важно создать атмосферу, где каждый участник чувствует себя значимым и не боится предлагать идеи (и с миникомандой добиться этого на самом деле гораздо проще, чем в большой группе).

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