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

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

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

это я) KODE
это я) KODE

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

Зачем нужны правила или фреймворки

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

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

KODE
KODE

Теория фреймворков — практика бюрократии

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

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

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

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

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

Важно отбросить слепое следование — темную сторону бюрократии.

Поэтому ориентироваться в этом море правил и границ помогает осознанность и гибкость.

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

Правило №1: не описано, значит нет

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

KODE
KODE

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

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

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

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

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

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

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

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

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

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

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

Правило №2: Часы приема

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

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

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

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

И мы приняли решение возродить такую практику как часы приема (привет, бюрократия!).На первый взгляд контрпродуктивно.

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

Правило №3: нет таски, нет работы

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

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

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

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

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

Правило №4: рутину в чат, продуктив в митинг

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

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

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

Чек-лист и итог

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

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

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

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

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

Чек-лист по работе с новым правилом:

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

К размышлению

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

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

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

1919
8 комментариев

Достаточно просто и понятно

1
Ответить

Спасибо

Ответить

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

Ответить

Я немного только покопал в сторону Notion, но по моему там не получится сделать автоматический ченджстатуса. И Notion имеет только одну проблему  - постоянные платежи. Та же самая развернутая дома jira обходится дешевле.

1
Ответить

При разработке мобильных приложений возможно документация и не нужна. Это вообще не ПО, просто оболочка. Но вы попробуйте вести разработку без документации к ПО самолета. Интересно будет когда "ключ" выйдет из проекта. В общем в итоге именно проект определяет подход. Нет никаких правильных наборов подходов и методолгий. 

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

И да, продукт подразумевает расчет финансовой модели, аналитику и прочее прочее. У вас просто проект (ы).

Спасибо!

Ответить

Согласен полностью. Про это и пытался сказать, что это конкретный кейс, в продукт, в котором документации уделялось слабое внимание. Но. Я тут был на ProductCamp 2020 с этим докладом. 
Так вот, оочень многие компании, которые стартуют свой продукт не ведут спек вообще. Некогда потому что, юнит вроде сошелся, таски к MVP в юзер-сторях описали и понеслась, а через пару лет бешеный легаси.
Но не в этом суть статьи ) А в том, что думать надо всегда, и на старте и в полете.

Ответить
Автор

Ну мы же пишем про общение внутри команды, а не с заказчиком. Про это мы отдельной темой обязательно расскажем ( как и про расчет финансовой модели и аналитику).

Ответить