Рост команды на порядок

Александр начинает с контекста. Привлечение — сервисная линия внутри компании: нужно много и дёшево приводить новых клиентов, делать удобные интерфейсы и строить масштабируемые процессы в разных каналах — контекстная реклама, real time bidding, e-mail, SEO и собственные медийные проекты. Технически это гибкое управление контентом страниц, сплит-, A/B- и мультивариантные тесты, результаты которых различаются по сегментам и потому требуют персонализации, и сбор статистики, чтобы оценивать эффект своих действий. Отделений у компании никогда не было, поэтому веб — основной канал, а заказчики — все бизнес-линейки сразу, с несинхронизированными требованиями. Александр отвечает за неавторизованную часть: главную, страницы продуктов и лендинги. В конце 2016 года, когда он пришёл, весь код лежал в монорепозитории с монолитным приложением и странной декомпозицией: чтобы выкатить изменение, нужно было влить его в общую релизную ветку, скрестить пальцы и ждать долгий регресс, за время которого изменение успевало устареть.

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

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

Отдельный сюжет — где взять нового лида. Внутри компании это оптимальнее, и ради этого в департаменте впервые ввели performance review: поговорили с разработчиками об их планах и выделили потенциальных тим- и техлидов; параллельно открыли внешнюю вакансию. Александр напоминает трек роста: джуниор учится решать задачи, не дёргая команду по пустякам, мидл дорастает до сеньора — сильного специалиста, который сам разберётся почти в любой области, умеет учить других и потянет новое направление. Разговор о лидерстве имеет смысл именно с сеньором, а ключевой вопрос — хочет ли он качать софт-скиллы и отвечать за работу всей команды или расти технически. Из ответа вылупляется тимлид или техлид. Важна и безопасность: без обещанного отката назад в сеньоры люди боятся пробовать. Сильный разработчик согласился попробовать и забрал страховые продукты, активно их развивал, а через год перешёл в техлиды — устал от тимлидства.

Третий шаг — оптимизация усилий: команд стало явно больше пяти, точное число Александр не называет, и они по-разному делали похожее. Базовые части приложений вынесли из монолита в отдельные репозитории и стали подключать зависимостями. Появились продакт-менеджеры с бизнес-наполнением и роадмапом, а коммуникации замкнули на релиз-менеджера: он тюнит процессы, служит единой точкой там, где продакта ещё нет, отвечает за содержание релизов и помогает тимлидам, выросшим из технарей. Со скрам-мастером, замечает Александр, трудно понять, за что человек отвечает и как мерить его эффективность: легко получить все ритуалы без результата. Тогда же ввели метрики — терять нельзя объём функционала, скорость его запуска и качество: статистику из трекеров задач выгрузили в реляционную базу с BI поверх, графики помогла собрать одна из тимлидов. Стало видно, что с ростом числа команд росло число релизов, а задач в одном релизе становилось меньше; на кривой времени регресса два пика — команда около двенадцати человек до деления и момент, когда команд стало много и они начали мешать друг другу. Пропущенные дефекты вроде бы идут вниз, и Александр надеется, что автоматизация проверок удержит их внизу.

Четвёртый шаг — делегировать ответственность тимлидам. Мешал оставшийся монорепозиторий с общим каркасом: лид мог сказать, что его команда сработала отлично, но в релизную ветку безальтернативно приезжали чужие изменения, а последствия правки общего кода для соседей понять было нельзя. Приложения развели по отдельным репозиториям, а общий инструментарий — движок страниц, движок продвинутых форм и библиотеку трекинга — стали подключать зависимостями и развивать как внутренний open source: нормальный README, описание архитектуры, пример использования и точки расширения через плагины, чтобы логика конкретных продуктов не залезала в движок. Движки ведёт core-команда с архитектором и техлидами; она же собрала на них маленькое бизнес-приложение, и A/B-тест дал, по словам Александра, процентов десять-пятнадцать прироста конверсии против старого решения. Шаг не доведён до конца: формы части продуктов ещё предстоит перенести на новый движок. Метафорически лид растёт от детского сада, где поделки уносит воспитатель, через школу с релизом вместо домашней работы и университет с курсами-инструментами во взрослую жизнь, где сам выбираешь зависимости и отвечаешь за решения. Не сойти с ума при этом помогают понятые цели бизнеса, согласованное видение архитектуры и ясность, что входит в обязанности тимлида на текущем шаге, а что нет.