Вместо роста — перезагрузка: как ускорить разработку без увеличения команды

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

Эта история о том, как мы обнаружили, что «больше» не всегда значит «лучше», и как реорганизация команды помогла уложиться в сроки и повысить качество работы. Меня зовут Игорь Котов, я СТО стрима Ипотека, и в этой статье я поделюсь нашим опытом. Возможно, он будет полезен тем, кто ищет способы ускорить разработку без увеличения команды.

С чего мы начинали

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

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

На первый взгляд всё казалось несложным: к маю 2023 года мы собрали команду из более 20 человек. Это были опытные инженеры, знакомые с продуктом, новички, аналитики и тестировщики. Работа организовывалась по классическим agile-принципам: двухнедельные спринты, дейли, демо и ретро.

На бумаге всё выглядело идеально, но на практике появились проблемы. Дейли затягивались до 40 минут: каждый участник говорил пару минут, а остальное время люди ждали своей очереди или слушали нерелевантные обновления. В итоге на такие встречи уходило больше 13 часов в неделю.

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

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

К какому решению пришли

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

Каждая получила чёткую зону ответственности и полный набор компетенций для автономной работы:

• Одна команда занялась функциями работы с созаемщиками.
• Вторая — модулем загрузки и обработки документов.
• Третья — анкеты заемщика.

Мы тщательно перемешали составы: опытные сотрудники и новички распределились равномерно. Это позволило сбалансировать компетенции и создать условия для обучения внутри команд.

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

Такое разделение изменило подход к планированию: теперь каждая команда могла сосредоточиться на своей задаче, а не пытаться двигать несколько фич одновременно. Уже через два спринта стало очевидно, что новый формат работает.

Каких добились результатов

Реорганизация принесла ощутимые улучшения. Дейли сократились до 15 минут, планирование занимало около часа, а ретро стали откровеннее и конструктивнее. Это позволило устранить чувство безответственности: каждый участник ощущал свою значимость.

Фокусировка на отдельных задачах избавила от постоянного переноса задач из спринта в спринт. Процесс разработки стал предсказуемым. К концу 2023 года мы запустили кабинет заемщика в срок с полным набором фич: от удобного интерфейса для созаёмщиков до автоматизированной обработки документов. Результат подтвердил, что выбранный подход оправдан.

Как понять, что вашей команде нужно изменение

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

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