Всем привет! Меня зовут Денис Ульянов, и я продолжаю серию статей «От разработчика к руководителю». В предыдущей статье я объяснил, почему управлять людьми сложнее, чем писать код. Сегодня хочу рассказать о том, как мы создавали и адаптировали собственную методологию разработки.

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

«Каждому проекту — свою методологию», — Алистер Коберн

Мой опыт с разными подходами

За свою карьеру я встречал разные подходы к организации разработки: от абсолютного хаоса и «чайка-менеджмента», до детального планирования на год вперёд с чётким указанием недели, когда фича должна выйти в продакшен. Где-то внедрялся Scrum, где-то применяли Kanban-like подход. Иногда методология действительно работала, а иногда превращалась в карго-культ, существующий лишь для галочки.

Старт с нуля

Когда я пришёл в Wildberries, передо мной стояла амбициозная задача: за 9 месяцев собрать команду с нуля и запустить продукт к «Чёрной пятнице». Старт с нуля давал свои преимущества: можно нанимать людей и сразу выстраивать процессы под конкретные задачи и особенности проекта.

Начало без лишних активностей

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

Когда команда сформировалась, мы начали работать без привычных всем митингов, задач в таск-трекере и планов на салфетках после вечерних посиделок. Почти полгода мы жили по простой схеме: «в актуальной wiki — актуальная информация, код должен быть приведён в соответствие». Отказ от ежедневных митингов, ретро, демо и грумингов позволил команде полностью сфокусироваться на самом важном — разработке и запуске продукта.

Полгода без митингов и задач

В таком режиме мы проработали полгода. Отсутствие дейли-митингов, демо, ретро, грумингов и прочих привычных активностей освободило нам массу времени и энергии на главное — создание продукта.

И это действительно работало. Команда двигалась быстро, без лишней бюрократии, полностью фокусируясь на ценности для пользователя.

Изменения неизбежны

Со временем команда выросла, продукт был запущен в production, и работать по старой модели уже не получалось. Именно тогда мы начали постепенно корректировать методологию, подстраивая её под изменившиеся условия:

• увеличился размер команды— стала сложнее координация

• продукт в продакшен с живыми пользователями — требуется больше контроля и порядка

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

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

Поэтому нельзя просто внедрить все сразу и пытаться посмотреть что из этого выйдет. К тому же любая активность имеет свою цену. Мы тратим не только время, но и очень ценные ресурсы — наше «мыслетопливо». Чем больше встреч, тем меньше остаётся ресурса на действительно важные задачи. Поэтому любые активности должны быть оправданы и приносить больше пользы, чем затрат.

Наш текущий подход

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

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

Где-то я услышал фразу, которая очень точно описывает наш подход:

«Нельзя успеть всё, но можно успеть то, что нужно»

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

Разборы, новости, экспертиза наших разработчиков и вакансии — в телеграм-канале, подписывайтесь!