Всем привет! Сегодня хотел поговорить о процессах разработки. По мере роста компании не только развивается сам бизнес, но и копятся проблемы внутри, в частности в процессе разработки. Часто их пытаются решить внедрением каких-то практик и новомодных методологий. Увы, это насильное перестраивание процесса по книжкам и тренингам нередко это приводит к ещё большим проблемам — издевательству над людьми.
Недавно я выступал на конференции Saint TeamLead Conf 2019, в докладе я рассказал о том, как смог найти ряд проблем в рабочем процессе и потом постепенно поборол их. Здесь я постараюсь описать наиболее ценные практики, которые мне помогли не только наладить рабочий процесс, но и перестать издеваться над разработчиками. У сотрудников изменилось отношение к компании в целом и рабочему процессу.
Проблемы процесса разработки
Итак, когда готовые подходы не дали результата, а мы были близки к отчаянию, я занялся анализом процессов и стал разбирать всё по косточкам. В результате получился такой список проблем:
- Доска перегружена задачами — на ней был настоящий хаос. Глядя на доску, разобраться в процессах было практически невозможно.
- Не было нормальных оценок — мы не умели правильно оценивать задачи по времени выполнения, из-за этого сроки постоянно ехали, руководители от бизнеса наезжали на разработку.
- Постоянно факапили сроки — мы не могли точно сказать, когда фича выйдет в продакшен, чаще всего выкатывали её намного позже намеченного из-за внешних факторов, например, бизнес прибегал и просил быстро сделать какую-то срочную фичу в первую очередь.
- Не было понимания, как ускорить разработку — найм новых людей и загрузка инженеров работой на 100% не всегда делают процесс быстрее.
- Планирование и срочные задачи — если с текущими задачами как-то получалось строить планы и обозначать примерные сроки, то срочные задачи, которые обычно прилетали от бизнеса, ломали все планы.
- Встречи отнимают много времени — наша самая типичная ошибка: что-то не получается или надо расставить задачи по приоритету — а давайте соберёмся и обсудим. Или регулярные встречи, где разработчики сидели по часу-два и не понимали, что они там делают.
- Проблема мотивации и вовлечённости команд — часто какие-то нововведения начальство просто спускало сверху, не спрашивая мнения команды разработчиков, это не красило атмосферу в команде.
По сути задача любого руководителя, будь это TL или CTO, сводится к тому, что он должен стать связующим звеном между бизнесом и разработкой.
Чтобы как-то выбраться из сложившейся ситуации, мы обратились к Kanban-методу. Что он нам говорит? Давайте улучшать то, что уже есть. Ну и мы пошли улучшать наш процесс разработки.
Наводим порядок на доске
Мы начали рассуждать: если бэкендеры выполнили свою задачу и передали фронтендерам, то те сразу к ней приступят? Глядя на доску, это непонятно. По принципам Kanban мы поделили каждое направление разработки (у нас их было 5: бэкенд, фронтенд, DevOps, QA и дизайн) на две колонки: Do и Done. Сразу стало видно проблему: наша пропускная способность не позволяет сделать столько задач, сколько от нас хотят.
Ещё Канбан говорит: давайте введём WIP-limit и ограничим количество задач. Как мы определили лимиты? Эмпирическим путём. Конечно, пару раз промахнулись, но потом подобрали так, чтобы у нас не копились задачи в самом узком месте. Дополнительный профит WIP-limit — это триггер, который говорит о том, что как только у нас забрали задачу, мы можем взять следующую. Это своеобразная вытягивающая система.
К чему это привело? Инженеры стали внимательнее относиться к задачам, потому что когда они не могут решить задачу, то на неё ставится блокер. Больше задач взять нельзя, так как есть WIP-limit, инженеры должны ждать, когда им помогут её решить. Есть шанс остаться без задач.
Когда мы стали подробно разбирать проблему возвращающихся задач, выяснилось, что все делают их по-разному, например, кто-то пишет тесты, а кто-то нет. На этот счёт были правила, но те, которые спустило сверху начальство. Они не решали проблему разработчиков. Мы ввели новые правила (Definition of Done), которые интегрировали в доску. Они могли действовать как на какую-то колонку, так и на тип карточки. Например, для API нужно, чтобы бэкендер задокументировал все методы и прочее. Правила были всем доступны и видны на доске, а самое главное — шли от самих инженеров и решали их проблемы. Если что-то не было сделано, инженер это видел и шёл делать.
Оценки задач
Мы не умели оценивать задачи по срокам, а Канбан нам говорит: «No estimates». Что делать? Накопили статистику и построили такой график. Это спектральная диаграмма, зависимость количества задач от времени.
Начали её исследовать, увидели на графике 3 пика, которые соответствуют трём типам работ. На основе этих типов выработали классификацию и критерии таких работ. Мы ввели эти типы на доску задач, а потом для каждого в процессе добавили дополнительные правила. У нас получились такие:
Мы договорились с заказчиком, то есть с бизнесом, о соглашении качества сервиса (SLA). К нам приходит менеджер и спрашивает: «А за сколько вы сделаете эту фичу?» Мы не можем сказать, за сколько её сделаем точно, но зато можем сказать, сколько времени уйдёт на целую партию таких задач. Отпала необходимость в скрам-покере, и мы перестали пытать людей вопросами о сроках. Просто смотрели в статистику и называли бизнесу сроки.
Конечно, у этого подхода были и минусы. Например, это не работало с задачами нового типа, по которым у нас просто не было статистики. Прикидывали старыми способами, но потом накопили достаточное количество данных и такая проблема сошла на нет.
Потом мы столкнулись с тем, что некоторые задачи стали попадать в другие типы работ. Провели небольшое исследование и выяснили, что какие-то задачи делали намного быстрее, потому что бизнес что-то там обещал партнёрам и просил разработчиков сделать их срочно. А какие-то задачи наоборот были не так важны, их откладывали. Так у нас появились приоритеты, то есть соглашения о классах обслуживания сервисов (CoS), мы их разместили на доске. А чтобы бизнес не злоупотреблял этим и не ставил повышенную срочность для всех задач, ввели горизонтальные WIP-limits.
Как ускорить разработку
Опять обратились к статистике трекера задач. Обнаружили, что многие задачи зависают на доске в ожидании доработок, проверок или дополнительных данных, то есть поняли, что разработку можно ускорить. Стали смотреть, сколько задачи копятся, сколько простаивают, и обнаружили, что некоторые фичи разрабатывались меньше, чем ждали приёмку. Решили назначить день принятия фич, и время выпуска задач сократилось. А потом мы прикрутили CD (Continuous Delivery) и стали высылать уведомления.
Стало понятно, что нужен был инструмент для оценки наших улучшений. Решили использовать накопительную диаграмму потока. В двух словах, как она строится: каждому рабочему центру (колонкам на доске) присваиваем свой цвет, снимаем статистику, сколько в колонке элементов (задач) в единицу времени и наносим на график, разместив их один один под другим. На графике по оси X — время, по Y — количество задач.
Что мы отсюда извлекли? Тут легко увидеть lead time (время производства) — горизонтальная линия (ширина потока по оси X) начинается с постановки задачи и доходит до стадии готовности. Таким образом, тут видно, как задача проходит все стадии разработки — линия пересекает все цвета, каждый из которых соответствует своей стадии. А также суммарный WIP-limit доски — высота потока по оси Y. Как увеличить скорость разработки? Можно уменьшить WIP-limit (то есть сделать поток на графике более узким), а можно сделать так, чтобы наш поток, который направлен от начала координат в верхний правый угол графика, стремился вверх ещё сильнее (то есть задрать направление потока ещё сильнее вверх, уменьшить его угол относительно оси Y). Чтобы поток направить сильнее вверх, можно ввести какую-то новую практику, например, внедрить Docker или сделать удобную базу знаний. Это необязательно должно быть техническое нововведение, такой эффект может дать и новый подход в управлении.
Тем самым мы получили инструмент, который наглядно показывал, какие улучшения работают, а какие нет.
Планирование с бизнесом, срочные и бесполезные задачи
Планирование разработки с бизнесом было самой большой болью. Что мы делали? После получения задачи от бизнеса устраивали встречу аналитика и разработчика, где декопмозировали её, а разработчик предлагал решения. В итоге мы понимали сколько и каких ресурсов требует задача. А уже потом бизнес без нашего участия строил свои планы и считал, сколько мы можем выпустить фич. В Канбане это называется каденция по пополнению.
Условно говоря, мы выделяем слоты определённого размера, в соответствии с WIP-limits, куда можно положить задачи. Каждый слот вмещает только ограниченное количество задач. По-другому, этот метод называется «планирование стаканчиками».
Мы сделали для бизнеса простой инструмент (таблица в Excel), в которой он мог визуально планировать. Менеджеры дрались между собой, спорили, чья задача важнее, а потом уже приходили к нам и отдавали задачи в разработку.
Так как у нас уже были ограничения, то бизнес относился внимательнее к выбору задач, выбирал наиболее важные, а не заваливал нас всякой ерундой, которая им приходила в голову. И ещё один большой плюс: они отбирали задачи сами без нашего участия, не отвлекая разработчиков на совещания, те спокойно работали и не тратили время на встречи.
Также мы обратили своё внимание на проблему срочных задач. Стали анализировать статистику по ним и поняли, что эти задачи не такие срочные. Например, нужна акция по сезонной смене колёс у автомобилистов. Мы знаем, что это всегда происходит 2 раза в год. Раз они повторяются, давайте на доске резервировать слоты под такие задачи заранее. Не будет ничего срочного — возьмём другую задачу из очереди, без работы не останемся. В итоге мы выяснили, что 60% срочных задач на самом деле не срочные.
Была ещё одна проблема. Мы часто пилили фичи, от которых потом в итоге бизнес отказывался, потому что они оказывались бесполезными с точки зрения бизнеса. Мы предложили бизнесу делать MVP фич, которые требуют в разы меньше времени, чем обычная разработка. Обратная связь стала сниматься гораздо быстрее, и инженеры стали понимать, что это эксперименты. Раньше, когда в мусор выбрасывались недели проделанной работы, они переживали, это отравляло им жизнь.
Мы стали так тестировать 85% фич, что в итоге освободило кучу времени, которое потом тратили на проверенные на практике гипотезы. Они уже приносили компании деньги. Также если в процессе что-то шло не так, то заказчик фичи со стороны бизнеса мог вносить правки на ранней стадии, а не через весь цикл разработки.
В итоге открылся такой факт, что далеко не все идеи работают. А раз они не работают, то не надо их делать. С тех пор разработчики перестали заниматься мартышкиным трудом, а делали именно то, что приносит деньги компании.
Встречи
Улучшения, что мы ввели, к тому моменту уже поубивали ряд бесполезных встреч. Обсуждений приоритизации больше не было, так как мы это отдали бизнесу, планировали тоже без инженеров. Также мы отказались от пятиминутных набегов менеджеров с просьбой «быстро помоги». Остались только действительно нужные встречи. Ещё мы ввели правило, что теперь встречи назначаются на конкретное время, чтобы все могли планировать свой график.
В итоге все совещания по болтологии преобразовались в следующие типы встреч:
- когда аналитик хочет обсудить конкретную задачу с инженером, например, для поиска оптимального решения или декомпозиции;
- когда что-то застряло на доске. В этих случаях мы собирались и шли по доске справа налево, спрашивали инженеров, что случилось, кто может помочь. Важно, что мы шли от задач, а не пытались посчитать, чем занимались люди;
- когда планировали задачи на спринт (каденция по пополнению);
- когда принимали фичи;
- встречи между командами разработчиков, например, когда обсуждали формат API или решали, какие события передавать.
Ключевой момент: мы приглашали на встречи только тех людей, которые непосредственно участвовали в предмете обсуждения, а не звали номинальных слушателей, как раньше. У инженеров в корне поменялось отношение ко встречам, раньше они их не любили, а теперь всё наоборот, они им кажутся нужными и полезными.
Мотивация и вовлеченность команд
Всё что мы внедрили: WIP-limits, оценку задач на основе статистики, отказ от бесполезных задач и прочее, описанное выше, привело к тому, что у инженеров освободилось время. А чем они будут теперь заниматься? Самое большое заблуждение, что никто ничего не будет делать. Я сам неоднократно слышал от ребят: «Я бы этот код зарефакторил, а то там уже чёрт ногу сломит». Да, вначале инженер действительно выспится и отдохнёт 2–3 недели, а что дальше? Он сидит без задач, начинает подходить к коллегам с предложением помощи, помогает сделать задачи, потом уже оба сидят без задач. «Пошли баги пофиксим» — колонка с багами опустела. «Пошли код зарефакторим» — код стал быстрее писаться, WIP-limit можно увеличить. Дальше начинают внедрять CD/CI, пишут базу знаний. Что произошло? Инженеры начинают делать много полезного, до чего у них не доходили руки. Это и есть та скорость, которую хочет бизнес, но почему-то никак не может ни от кого получить. Раньше инженер был злой, хотел, чтобы от него все отстали, а теперь парадигма человека изменилась до: «А сейчас чем я могу тебе помочь?» Количество инициатив выросло, и все они шли снизу, а не сверху. И в итоге оказались куда полезнее.
Кратко об итогах
- Мы смогли найти узкое место в системе и понять, что мы не можем сделать больше, чем можем.
- Перестали закидывать разработчиков бесполезной работой и освободили время для более полезных задач.
- Когда инженерам стало нечего делать, они стали лучше оценивать задачи, разгребать баги, стали автоматизировать процессы, появилась база знаний.
- Инженеры перестали испытывать стресс и стали добрее.
- Мы смогли в 4 раза ускорить выпуск новых фич путём улучшений, оптимизацией работы (увеличивались WIP-limits за счёт автоматизаций и улучшений).
- Получили статистику для бизнеса и чёткое понимание, что и как у нас происходит с разработкой.
- Научились экономить время (отказ от ненужных задач, стали заранее продумывать задачи во избежание дополнительных факторов и т.д.).
- Совещания и встречи проводились, когда они действительно нужны (стали более гибкими).
- Все стали больше думать, количество инициатив выросло. Инициативы, которые рождаются в командах, всегда лучше, чем то, что спускается сверху. Процесс шёл постоянно, и в него все включились.
Выводы
В этой статье и докладе я хотел обратить внимание не только на инструменты и подходы, которые я применял, а скорее на самый важный аспект, который часто остаётся незамеченным, но, на мой взгляд, он не менее важен. Всю эту перестройку мы затеяли, потому что у нас были боли и мы хотели от них избавиться.
Можно внедрить что-то «в лоб», прочитав умные книжки или прослушав доклад про гибкие методологии, так возможно даже ускорится разработка или продукты будут работать лучше. Но мы часто забываем, что эти продукты делают люди, а чем лучше мы сделаем их жизнь, тем лучше они будут делать продукты. Я, например, хожу к ребятам и спрашиваю: «А какие у вас боли? Что не так?», перед тем, как что-то начать внедрять. И только благодаря такому подходу, мне удалось сделать то, что хочет бизнес — скорость и качество в разработке.
P.S. Мне рассказывали про одну компанию в Европе, там когда приходишь в офис, может показаться, что царит полная анархия: разработчики, как сыр в масле, играют в приставки, никто не работает. Но это только на первый взгляд, там для людей специально сделана такая атмосфера, чтобы они могли творить и улучшать. Один сотрудник в перерывах между задачами для развлечения на коленке написал решение, которое впоследствии внедрили, и оно стало приносить компании прибыль. Я надеюсь, наш российский менеджмент в ближайшем будущем будет двигаться в эту сторону. А если у вас почему-то не так, задумайтесь, что вы делаете. Ну или подкиньте начальнику эту статью, ну а вдруг поможет :)
Автор: Артур Дементьев
