Agile, kanban и бюрократия: перемешать, но не смешивать. Опыт команды мобильной разработки КODE

Как внедрять новые правила в команде и все не сломать, рассказываем на кейсах и чек-листах.

Меня зовут Вова и я PM в KODE — ТОП-4 разработчиков мобильных приложений России по версии Рунета. Мы разрабатываем продукты для авиакомпаний, банков, телемедицины, бизнеса и развиваем свои бренды.

Я руковожу мобильной разработкой для крупной авиакомпании. Этот проект в портфеле KODE уже 4 года. За это время накопилось много командного опыта и интересных решений, о которых я хочу рассказать.

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

Какой мостик использовать: kanban, scrum, waterfall и обязательно ли один тот же? Думаю над этим задумывается каждый, кто хотя бы раз брался за проект. Почему бы не нарушить правила, чтобы прийти в точку Б быстрее и как при этом не превратить все в анархию? Волшебной таблетки не будет, будет гибкость и осознанность.

Сейчас модно говорить про гибкость и осознанность, вокруг только и разговоров про очень гибкие процессы. И я считаю, что у этого есть веские причины. Я не знаю ни одной компании, которая использует, допустим, scrum в чистом виде. Любой фреймворк диктует нам строгое следование правилам, нарушил, все — ты уже не true. На практике же мы все чаще наблюдаем такой процесс: команда вооружившись одной системой беспрекословно следует правилам, уверовав в их эффективность. Потом, как правило, начинается всевозможный улучшайзинг и как результат — полный игнор любых теоретических правил. В итоге никто не пользуется каноническими фреймворками. В подтверждение тренда — появление Scrumban, гибрида двух популярных методологий, где визуализация структуры от канбана, а приверженность ритуаламам от скрама.

В своей работе мы используем Scrum, Waterfall, Kanban и различные гибриды. Мы постоянно миксуем и от чего-то отказываемся, сейчас добрались до Scrumbana, но пока только осознаем новые правила.А кое-что мы подсмотрели у старой доброй бюрократии.

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

С помощью бюрократии, так же как и Scrum-а, можно получить ожидаемый результат в нужные сроки (берем человека, даем ему инструкции, получаем результат).

Только после этого можно добавлять сегменты разных подходов и новые правила.

Гибкий подход предполагает минимум документации. Все знания находятся в головах команды, важен только time-to-market и общий перфоманс. Это отлично подходит для стартапа, когда надо в кратчайшие сроки запуститься и проверить гипотезу. Но в развивающемся готовом продукте это усиливает bus-фактор.

Мой продукт начался летом 2016 года. Сначала была пара фич с простой структурой и бэком, потом добавилось еще и еще. За 3 года сменилось 2 или 3 поколения разработчиков и несколько менеджеров. В продукте не осталось ни одного человека, который бы имел знания обо всем продукте.

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

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

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

Чтобы подобное больше не происходило ввели правило: не описано — значит нет. Сначала было сложно, потому что надо было разобраться, что именно описано, что нет, что не бьется с реальным положением дел.

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

Что мы имеем сейчас?

Каждая фича облеплена артефактами, бизнес-требованиями, техническими заданиями, клиентскими требованиями, комментариями в коде, сиквенс-диаграммами от разработчиков, схемами по openapi, тест-кейсами от QA и т.д. Если что-то меняется в фиче, меняются и артефакты.

Сейчас описание продукта находится на высоком уровне и любой новый разработчик быстро находит нужные для работы знания и уходящий разработчик не уносит их с собой.

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

Это противоречит гибкому подходу, но это очень круто работает. Поэтому не описано — значит нет.

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

Когда команда состоит из разных специалистов и не взаимозаменяема, некоторые роли могут оказаться в центре излишнего внимания. В нашем случае, чаще других на этом месте были аналитики и бэкенд разработчики. Это случилось когда документация еще была на низком уровне.

Все члены команды приходили с вопросами к аналитикам и бэкендерам. Они постоянно отвечали на вопросы. Сказать команде: “Не приходите” значит, остановить работу. Оставить как есть — лишить аналитиков и бэкенд состояния потока. Если еще один разработчик приходит к 9 утра, второй к 11, третий к 13, все превращается в балаган и сплошные митинги.

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

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

Кейс для работы в длинном продукте. В моей жизни я встречал очень много разработки на основе chat-driven (постановка задач в чатиках или возле туалета). Если мы говорим про стартап, это абсолютно нормальный метод быстро выйти на рынок. Но у нас стабильный продукт с миллионной аудиторией.

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

К этому правилу я бы добавил еще одно: бери в работу первую таску сверху. Получается отличная смесь — вся работа в виде тасков в тасктреккере, не надо выбирать что делать — бери первую сверху.

Поэтому, нет таски — нет работы.

Планы на день и отчет о выполненной работе вчера скидываем в общий чат.

В большой команде не всегда понятен действительный объем выполненной работы. Так вся команда видит кто чем занят. Ежедневный письменный отчет помогает самодисциплинироваться, потому что если ничего не делать, то нечего будет писать. Утром вся команда настраивается на работу в течение дня. Время на митингах тратим на решение проблем - рутину в чат, продуктив в митинг.

Пока это правило носит статус on-going experiment, но первые результаты нас радуют.

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

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

Для этого определяем важную для нас сейчас метрику, например:

• time-to-market,
• количество фич в спринт,
• количество доработок фич после тестирования,
• количество просочившихся в прод багов.

После, вместе с командой определяемся, как можно повлиять на эту метрику. И тестово устанавливаем правило.

• Проверка на здравый смысл. Правило должно быть понятным всем, одинаково трактуемым, решающим какую-то конкретную проблему или вносящим какой-то профит.
• Качество правила. Какую метрику качаем, как будем измерять и можно ли измерить. Устанавливаем себе рамки для принятия решения.
  
• Установить срок годности правила: когда его нужно пересмотреть, оценить результаты его работы.
  

Если не будет правил извне, то все будут пользоваться своими принципами:

• чувство ответственности,
• этикет: “можно отвлекать или нельзя”,
  
• самостоятельность (до какой меры я буду сидеть и жечь часы на разбирательство).

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