Как, вопреки закону Брукса, удовлетворить возрастающие потребности бизнеса, ежегодно удваивая команду разработки? Болезни роста и рецепты выздоровления, проверенные на практике.

В докладе будут рассмотрены несколько основных вопросов.

Зачем расти?
• расширение продуктовой линейки, при этом все продукты очень тесно интегрированы и не могут быть отданы на аутсорс
• увеличивающийся поток задач, многие из которых срочные
• как следствие - увеличивающийся технический долг
• необходимость повышения bus factor

Как меняется структура?
• плоская структура становится трудноуправляемой уже при 10-15 сотрудниках, нужно вводить дополнительные уровни, чтобы количество прямых подчинённых не превышало 5-7
• формируем разработчиков в команды по 3-7 человек, выращиваем и нанимаем руководителей отделов и тим-лидов
• создаём команду QA
• вводим новые роли PM (product/project/program manager) и аналитиков
• создаём команду UX/UI

Кого, где и как брать на работу?
• три-четыре junior-разработчика на одного senior'а способны вывести его из строя и уменьшить суммарную производительность, в то время как два-три новых mid- и senior-специалиста позволяют сформировать эффективную команду
• стараемся использовать все возможности для поиска квалифицированных кадров - формируем команды разработки в региональных офисах (сейчас треть команды из почти 90 технических специалистов находится в офисах в Брянске, Минске и Зеленограде, две трети - в Москве), при этом опыт показывает, что для уверенного старта необходим опытный член команды из главного офиса, впитавший корпоративную культуру, искать нового тим-лида на месте - не лучший вариант
• в поиске и отборе людей начинают принимать участие (и решения) большее количество людей (руководители отделов и тимлиды проходят бизнес-тренинги по управлению персоналом и говорят с HR-специалистами на одном языке)

Как выстраивать новые процессы и измерять их эффективность?
• крайне важно наличие актуальной документации, включающей как документацию по коду, так и внутренние стандарты, процессы, "курсы молодого бойца", и т. п.
• развиваем направление QA, вводим continuous integration, метрики качества
• вводим 100%-ое code review, разработчики в обязательном порядке пишут unit- и функциональные автотесты
• продукты покрываются метриками (как техническими - для разработчиков, так и бизнес - для PM-ов, кураторов и разработчиков)
• формируем команду devops для централизованной работы над инструментами, инфраструктурой и мониторингом качества кода с точки зрения безопасности, производительности и масштабируемости (дополнительные еженедельные code-review)
• изолируем разработчиков от прямого доступа к ним заказчиков, всё взаимодействие осуществляем через PM-ов
• формируем бэклоги команд (в составе: PM, тим-лид, заказчик) и еженедельно делаем бэклог-груминг (анализ и уточнение постановки задач незадолго до взятия их в работу, в том же составе, лучше с привлечением QA)
• у каждого продукта появляется PM и стейкхолдер (куратор), они согласовывают KPI продукта и отвечают за их выполнение
• каждая команда может самостоятельно выбирать методологию, но обязательными для всех являются ретроспективы, а ежедневные стендап-митинги настоятельно рекомендуются
• ресурсы между продуктами перераспределяются исходя из потребностей бизнеса, выделение дополнительных ресурсов осуществляется в рамках комитета, где PM-ы защищают необходимость своих продуктов перед другими PM-ами и топ-менеджментом

Что получается в результате?
• заказчики счастливы - R&D для них перестаёт быть чёрным ящиком, они вовлечены в процесс разработки и понимают, какими ресурсами располагают, что и когда будет сделано
• разработчики счастливы - заказчики перестают их выводить из состояния потока, над ними больше не нависают бесконечные неприоритезированные бэклоги задач, и можно сконцентрироваться на задачах текущей одно-двух-недельной итерации