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

Shopper App — приложение СберМаркета для сборщиков и курьеров. Через него проходят все заказы, и, если оно упадет, бизнес встанет.

В команде разработчиков Shopper App было всего пять человек, один из которых формально работал тимлидом. Когда СберМаркет вырос, разработчики перестали справляться с потоком задач.

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

Каждая часть СберМаркета — это направление, например экспресс-доставка за час. Задачи направления решают несколько команд из разработчиков, дизайнеров и продакт-менеджеров.

Продуктовые задачи направлений превращаются в функции и экраны приложения для сборщиков Shopper App. Его пишет одна команда Android-разработчиков.

Чем больше появлялось продуктовых команд, тем сложнее было правильно оценить и приоритизировать их задачи. Требования менялись в процессе разработки, сдвигались сроки, появлялись новые срочные задачи. Мобильная разработка начала захлебываться.

Получался замкнутый круг:

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

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

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

• нет точного понимания capacity команды;
• нет понятного бэклога, потому что постоянно появляются новые задачи;
• растёт технический долг;
• снижается стабильность приложения;
• не хватает людей, чтобы закрывать все задачи.

На основе болей придумали план выхода из кризиса.

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

Мы разработали стратегию перехода, по которой масштабировали команду Shopper App:

• Расширить команду Android-разработки. Начать с проджект-менеджера и тимлида и только затем нанимать новых разработчиков.
• Разделить разработчиков на core-команду Shopper App и команды в других направлениях.
• Добавить Android-разработчика в каждую продуктовую команду.

Мы решили привязать структуру направления Shopper App к количеству Android-разработчиков в команде. Второй этап начнется, когда будет 10 человек, третий — когда будет больше 15.

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

На первом шаге Android-разработчиков еще слишком мало, меньше 10 человек. Они получают задачи от всех продуктовых команд через проджект-менеджера и распределяют их между собой. Разделять команду Shopper App на этом этапе нет смысла, потому что людей всё равно не хватит на все направления.

Когда в команде Shopper App станет больше 10 человек, её можно будет разделить.

Несколько разработчиков станут core-командой. Она отвечает за общую стабильность приложения Shopper App, архитектуру, автоматизацию сборки билдов, автотесты, релизы и мониторинг.

Core-команда не работает с задачами от продуктовых команд, а учитывает вектор развития приложения. Она создаёт отдельные компоненты, которые ускоряют разработку в продуктовых командах.

Часть Android-разработчиков начнут работать в направлениях. Так им будет проще понимать задачи, которые ставят продуктовые команды внутри этих направлений.

Тимлид Android-разработки станет лидером направления Shopper App. Он будет отвечать за работу core-команды и распределение разработчиков Shopper App по направлениям.

Проджект-менеджер продолжит приоритизировать задачи. Также он будет совместно с лидером направления работать с техническим долгом, core-задачами.

Пока это одна команда, но с развитием разработки их появится несколько. А core-команда будет синхронизировать технические решения.

Когда в команде Shopper App станет больше 15 человек, мы начнем добавлять 1–2 разработчиков в каждую продуктовую команду внутри направлений.

Команды смогут генерировать и сразу передавать задачи Android-разработчику. Сократится цикл от идеи до реализации. Разработчики станут код-оунерами для каждой фичи.

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

Лидер направления Shopper App будет менеджерить всех Android-разработчиков, отслеживать их развитие. При необходимости он сможет перенаправлять ресурсы — например, добавить мобильных разработчиков в одну из продуктовых команд, если возникла горящая задача.

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

На момент выхода статьи в направлении Shopper App шесть Android-разработчиков, тимлид, проджект-менеджер и тестировщик. Хотя разработчиков всё еще немного, нам удалось погасить пожары и перевести команду в нормальный режим работы.

Успех стратегии можно оценить по конкретным результатам:

• определили capacity спринта. Раньше мы не планировали и не оценивали спринты. Теперь высчитываем Story Points, учимся правильно оценивать трудоемкость задач. Команда успевает сделать даже больше запланированного: фактические Story Points в среднем выше плановых на несколько единиц;
• сделали приложение для сборщиков более стабильным. Одновременно с текущими задачами разработчики стали брать больше задач по техническому долгу и багам. Еще в направлении Shopper App появился свой тестировщик;
• разработчики стали счастливее. Измерить этот показатель невозможно, но в их жизни точно стало меньше пожаров и стресса.

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

Сейчас мы ожидаем, что на втором этапе удастся построить команды внутри направлений. Это даст большую сплоченность между мобильными разработчиками и продуктовыми командами и увеличит скорость доставки фич в продакшен.

Пока мы не планируем дальше третьего шага стратегии. Когда переход на новые процессы закончится, команду мобильной разработки можно будет масштабировать до 30–40 человек. Скорее всего, больше Android-разработчиков нам не потребуется в ближайшие пару лет.

Если станет понятно, что даже 40 разработчиков не хватает, чтобы закрыть все задачи по направлению Shopper App, изменения будут на уровне всего СберМаркета.

****

Мы завели соцсети с новостями и анонсами Tech-команды. Если хотите узнать, что под капотом высоконагруженного e-commerce, следите за нами там, где вам удобнее всего: Telegram, VK.