Разгоняем Delivery: как ускорить поставку, не загнав команду

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

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

Что такое Delivery

Delivery – это часть end-to-end-процесса поставки ценностей. Условно его можно разделить на три части:

• Discovery, который отвечает за аналитическую часть, исследование и проверку гипотез;

• Delivery – этап, когда происходит техническая реализация проекта;

• Пост-анализ – этап, когда мы уже вывели решение на прод и проверяем, достигли ли того, чего хотели.

Весь end-to-end-процесс – это путь от зарождения какой-то потребности или идеи до ее полной реализации.

Сам процесс Delivery можно условно разделить на три этапа:

1. Техническую проработку решения,

2. Непосредственно реализацию – разработку плюс тестирование,

3. Поставку решения на прод.

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

Команды и процессы

На разных этапах зрелости командам могут подходить те или иные инструменты и практики. Я условно разделил команды, о которых буду рассказывать, на три типа: незрелые, развивающиеся и зрелые.

За этим делением не стоят конкретные критерии, по которым я его проводил. Оно чисто интуитивное, и дальше станет понятно, почему я так сделал.

Незрелая команда: хаос и ручные релизы

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

Незрелая команда – это та, у которой практически все плохо. У нее нет четкой методологии. Фактически ребята просто получают задачи и выполняют их, то есть никакой конкретной системы нет.

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

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

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

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

Со временем этот процесс совершенствовали, но буквально за пару кварталов пришли к тому, что исполняли коммитменты на 95–100%.

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

Развивающаяся команда: период бурных улучшений

Развивающиеся команды уже находятся в потоке изменений. У них есть какой-то фреймворк, они наладили планирование, появилась даже определенная автоматизация CI/CD.

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

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

В тот момент за тестирование отвечали сами пользователи. Они тестировали каждую нашу доработку. Мы передавали им задачи, отмечали в них пользователей, а задача зависала на 10–15 дней. Каждый день или раз в три дня им приходилось напоминать, и в конечном итоге они кое-как проводили тестирование. Мы очень сильно зависали на этом месте.

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

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

Мы договорились о конкретных шагах. Стали указывать исполнителей, добавлять в Jira лейблы задач по ответственной команде или направлению – кадровый учет либо расчет зарплаты. Сделали Jira-фильтры с ежедневной рассылкой на почту, а также доску, на которой пользователи видят свои задачи, когда те попадают к ним на тестирование. Добавили пуши в корпоративные мессенджеры, чтобы они не забывали о задачах.

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

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

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

Такие поставки не подпадают под фризы, их можно очень быстро заменить, откатить и так далее. Таким образом, мы ускорили вывод части задач, которые ожидали релиза. Но далеко не всех: примерно для 60% задач проблема оставалась. Мы продолжили решать ее дальше.

Зрелая команда: точечные улучшения

Зрелая команда – это команда, у которой уже есть нормальный фреймворк для управления потоком задач, автоматизирован CI/CD, налажены процессы, прокачаны планирование и приоритизация, каждый знает свою роль и функцию.

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

Инструменты и практики

Кейс: сокращение фризов

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

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

Главное – у пользователей и руководителей направлений кадрового учета и расчета зарплаты существовали серьезные предубеждения и опасения, что мы опять что-то сделаем и что-то сломаем.

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

План по сокращению фризов:

• Автоматизация тестирования

• Патчи от вендора

• Документирование изменений

• Продвинутая поддержка

• Баг-фиксы патчами

• План отката

• Ручное тестирование фичей

• Мониторинги

• Оптимизация процессов разработки

• Статистика

Я остановлюсь на нескольких ключевых пунктах этого плана.

Первое и главное – автоматизация тестирования. Весь критичный функционал должен быть покрыт тестами. К тому моменту у нас уже сформировалась команда аналитиков по расчету зарплаты и кадровому учету, которые писали сценарии критичных тестов. Мы их автоматизировали. На данный момент еще не на 100%: по HR критичный чек-лист автоматизирован уже полностью, по расчету зарплаты – примерно на 70%.

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

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

Еще один важный момент – мониторинги. Смысл мониторинга в том, чтобы узнать о проблеме до того, как она случится. Весь критичный функционал, все наши сервисы и интеграции мы покрываем мониторингом именно для того, чтобы вовремя понять: интеграция по нашему SLA должна отрабатывать за 50 минут, а она крутится уже два часа – значит, что-то не так. Мы идем смотреть еще до того, как к нам придет пользователь и скажет: «Ребята, что-то не выгрузилось, что-то не работает».

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

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

Discovery и Delivery: единый процесс

Если говорить о более зрелых командах, то для ускорения Delivery – технического этапа реализации задачи – нужно посмотреть на весь end-to-end-процесс в целом. Здесь важно взаимодействие с Discovery-командой: аналитиками и другими участниками – бизнес-аналитиками, продуктовыми аналитиками, самими продактами и так далее.

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

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

Помимо качественного описания, стали требовать описанные тест-кейсы. Должен быть зафиксирован чек-лист приемки и заведены тест-кейсы, по которым потом сам аналитик будет проверять задачу во время тестирования.

Мы начали применять практики shift-left testing. В частности, проводим встречу «3 амиго» до начала разработки. Когда анализ уже завершен, аналитик собирает встречу, в которой по классике участвуют разработчик, тестировщик и аналитик.

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

Почему, например, у незрелой команды этап разработки такой длинный? Почему Delivery занимает много времени? Потому что требования меняются по ходу работы, тестирование длится бесконечно. Поэтому самое главное – зафиксировать требования и договориться, что после перехода задачи в разработку они не меняются. Если нужно что-то изменить, заводится отдельная задача и проходит по стандартному флоу, включая приоритизацию.

Прочие инструменты улучшений

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

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

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

Более зрелый инструмент – WIP-лимиты, то есть ограничение количества задач в работе. WIP-лимиты используют далеко не все, хотя это очень классный инструмент. Я читал статьи разных Delivery-менеджеров, которые указывали, что только за счет WIP-лимитов можно ускорить процесс поставки на 20%.

С этим инструментом действительно нужно разобраться и правильно подобрать ограничения. WIP-лимиты можно установить на статусы или на конкретного человека – это очень гибкая система.

Четкие правила создания задач, декомпозиции, приоритизации. Еще одно классическое канбан-правило: важно формализовать и четко описать все договоренности. Для всех членов команды должно быть понятно, кто и когда создает задачи, при каких условиях вы передвигаете их из статуса в статус и когда устанавливаете флаг. Все эти договоренности должны быть зафиксированы и понятны всем. Их действительно нужно объяснять и проговаривать.

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

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

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

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

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

Фокус и ограничение незавершенной работы

В прошлом году мы как раз внедряли WIP-лимиты в своих командах. Здесь стоит вспомнить книгу Голдратта «Цель». Когда Голдратта спросили, как он может описать теорию ограничений систем одним словом, он ответил, что это слово «фокус».

Александра Брызгалова в своей статье о теории ограничений и конфликтах //infostart.ru/pm/2729715/ заметила, что теория ограничений – это не только про узкие места, не только про bottleneck. Там много всего: и «тучи», которые рисуют, и конфликты. Но для нашего кейса важен именно фокус.

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

Мы предположили, что и здесь могут быть проблемы, и задумались, можно ли ускорить этот статус. Решили попробовать две вещи.

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

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

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

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

Это два конкретных действия. Буквально в первые два месяца после их внедрения мы увидели, что наш lead time снизился с 20 до 15 дней по 85-му перцентилю. Этого удалось добиться за счет фокуса и отсутствия переключений.

Метрики

У нас существует отдельный процесс, который мы называем ревью сервиса поставки. В нем мы вместе с командой смотрим на метрики. Вовлекать команду в этот процесс важно.

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

Мы рассматриваем пять категорий метрик:

• Delivery – непосредственно метрики поставки, на которых я остановлюсь подробнее;

• QA – метрики качества: сколько у нас багов, каково их количество относительно выпущенных на прод задач, сколько критичных багов в разных разрезах;

• Incident – сколько у нас критичных сбоев различного уровня в зависимости от критичности сервиса, насколько надежный сервис мы поставляем;

• Support – CSAT и количество обращений, закрытых на первой, второй и третьей линиях;

• Security – метрики безопасности. Здесь важно SLA: насколько быстро мы успели закрыть критическую уязвимость. Такое бывает редко, но мы отслеживаем эти показатели.

Главная метрика поставки, на которую мы смотрим, – Lead Time. Это время от коммитмента команды разработки на выполнение задачи до вывода на прод. Именно от коммитмента, а не от начала разработки.

Если вы закоммитились на задачу и забрали ее в свою команду разработки, Lead Time уже начал тикать, хотя разработчик может быть еще занят. Это первое узкое место, над которым нужно подумать: зачем вы коммититесь на задачу, если не готовы ее делать?

Следующая метрика – Time to Build. Она показывает время от попадания задачи в бэклог до вывода на прод. Именно от попадания в бэклог, а не от создания задачи. Время от создания задачи – это Time to Market, то есть весь жизненный цикл задачи.

Time to Build хорошо показывает, как в связке работают процессы Discovery и Delivery. Если эта метрика слишком большая, значит, вероятно, либо одна из составных частей – Discovery или Delivery – слишком длинная, либо между ними есть разрыв.

Если между этими двумя этапами есть разрыв, возникает вопрос: не делают ли аналитики задачи в стол – то, что потом почему-то не идет в разработку? Может быть, у вас неправильная приоритизация? Почему задача не переходит дальше? Возможно, вы не умеете планировать и вам нужно поработать над проектным менеджментом.

Focus factor – практически классическая скрамовская метрика: доля эффективного времени команды. Вычитаем время на баги, инциденты, созвоны и все остальное. То, что остается, – эффективное время. Наш целевой показатель – 75%, и нам удается его достигать.

Предсказуемость – еще одна очень полезная метрика. Она показывает, насколько точно вы можете спрогнозировать, когда завершите задачу, и помогает при планировании.

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

Если сроки сильно разбросаны, поставка непредсказуема. Вы не можете сказать заказчику, закроете задачу через 10 дней или через 20. Если поставка предсказуема, вы можете с вероятностью 85% прибавить Lead Time 85-го перцентиля к дате начала выполнения задачи и спрогнозировать дату окончания. Можно автоматизировать диаграммы Ганта – все что угодно. У вас будут готовые «колбаски», по которым можно отслеживать сроки.

Также мы смотрим на пропускную способность команды (Throughput) и Time in Status, то есть время в статусах. Последняя метрика очень хорошо помогает замечать узкие места: видно, что в определенном статусе задачи задерживаются слишком долго.

День сурка

Напоследок расскажу о небольшой практике, которую мы назвали «День сурка». Название появилось потому, что первый раз мы проводили ее 2 февраля, в День сурка, и оно прижилось.

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

Вы сократите lead time, хотя могут возникнуть проблемы с предсказуемостью. Но здесь важно понимать: не вы существуете ради метрик, а метрики – ради вас. Если вы можете объяснить, почему показатель предсказуемости вдруг вырос, это нормально. Не нужно подгонять процесс под метрики. Важно уметь их интерпретировать.

Заключение

Выводы:

• Ускорение Delivery – это комплексный процесс,

• Автоматизация + инженерная культура + метрики = успех,

• Фокус на узких местах (привет ТОС),

• Процесс улучшений касается даже зрелых команд,

• Главное – начать.

Ключевая мысль в том, что Delivery – комплексный процесс. Я умышленно ничего не говорил про автоматизацию CI/CD. Мы все понимаем, что за счет автоматизации на разных этапах можно схлопнуть весь процесс поставки.

Никогда не поздно развивать свои процессы. Какой бы зрелости ни была ваша команда, выбирайте соответствующие инструменты. Главное – с чего-то начать: выберите самую большую проблему и действуйте.

И небольшой чек-лист «Как начать разгон Delivery» в качестве бонуса:

• Визуализируйте поток задач,

• Установите четкие правила работы с задачами (декомпозиция, переходы),

• Ограничьте WIP (например, 2 задачи на разработчика),

• Введите ежедневные митинги по блокерам,

• Автоматизируйте тестирование и деплой,

• Начните измерять Lead Time.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.