Каждый консультант по Agile (и подобным штукам) неоднократно бывал на встречах, где потенциальный заказчик просит помочь с организацией продуктовых команд или чего-то похожего. А на вопрос: “зачем вам это?” – отвечает, что поставлена задача: кратно ускориться, то есть сократить Time to Market. Первым практическим шагом очень часто является сокращение до аббревиатуры T2M, но, кроме этого, кажется, ожидается что-то ещё.

Да что уж там говорить, мы тоже на своих учебных курсах рассказываем про кратное ускорение – кому нужно, зачем, как принципиально добиться, сколько стоит и чем придётся пожертвовать. Рассказываем убедительно, но верят не все. Сказки же, понятное дело. Вон сколько компаний вокруг нас прошло через Agile-трансформации, а результат где? То-то же.

Почему сразу сказки?

Не верят – и правильно. Всем известно, что айти – сложная область, запутанная, сильно связанная. Изменения идут сплошным потоком. Конца поступающим бизнес-требованиям, идеям и инициативам не видно. Заказчики сами толком не знают, чего хотят, а время начинают отсчитывать от момента “мы вам сообщили о своей новой гениальной идее” – в таких условиях Time to Market может быть бесконечно большим.

Да и рабочий процесс обычно организован известно как. По меткому выражению Энди Ханта, одного из соавторов Agile-манифеста, “современная разработка ПО означает, что мы делаем кое-как половину Скрама, и у нас есть Jira”. Давайте это кратно ускорим? Давайте. Удачи.

“Agile now means, we do half of Scrum poorly and use Jira”

Andy Hunt

При этом важно заметить, что под кратным ускорением имеется ввиду именно кратное ускорение, как бы странно это не звучало. То есть: не стать эффективнее на 10-20%, а сократить время выдачи новой прекрасной функциональности в разы. В разы означает: хотя бы в два, а лучше в три. Совсем хорошо – в пять-десять раз. Ну точно же сказки.

Можно ли в сказку попасть?

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

1. Принцип организации ресурсов. Прошу прощения за цинизм, речь про ИТ-персонал. Как известно, в вопросе выделения ресурсов под задачи есть условный спектр от иерархии до (почти) самодостаточных команд. Выбранный принцип организации ресурсов даёт определённые возможности и накладывает понятные ограничения. Ветвистые иерархии принципиально не могут быть высокоскоростными, зато они достаточно экономичны. Поэтому для кратного ускорения иерархии придётся в какой-то степени от этой иерархии отказаться.
2. Архитектурная и технологическая составляющая. Некоторые ИТ-системы, которые мы создавали годами, поколениями программистов, которые мы связали со всем, чем можно, а ещё и внутри себя в безумный монолит, где аббревиатура “CI/CD” вызывает удивление, неприятие или нервный смех – такие системы кратно ускорить не получится. Это не означает тупика; это означает, что для ускорения придётся разбираться и принимать очень непростые (и недешёвые) технические и архитектурные решения.
3. Работа со входом. Даже самая прекрасная производственная система может быть под завязку забита мусором. Time to Market прекрасен, но Time to Market чего? Того, что попросил заказчик (ведь каждая его идея гениальна и принесёт миллиарды денег)? Или нашего тех. долга? Или задач по эксплуатации и сопровождению того, что уже насоздавали? Если под самые интересные бизнес-задачи доступна только незначительная ёмкость производственной системы, если эта ёмкость непредсказуема по объёму, если у нас не замыкается пресловутый цикл обратной связи и мы не оцениваем результаты того, что сделано, в бизнес-показателях, то кратного ускорения нам не видать.
4. Организация производства. Вспоминаем слова про поток создания ценности, про потери и их методичное устранение, про Канбан-метод и его WIP-лимиты, про порядок и про ограничения, позволяющие порядок поддерживать. По ходу дела неожиданно осознаём, что новая организация производства – не такая уж и высокая наука, почти всё очень логично и довольно просто. А ещё находиться в такой производственной системе комфортно (что, несомненно, приятный бонус).

Пункты выше приведены не в порядке приоритета. Так уж получается, что понятие “приоритет” для этих пунктов не применимо – они нужны все.

– Мне нужно 500 тысяч, и по возможности сразу, а не частями.

– Может, всё-таки возьмёте частями?

– Я бы взял частями, но мне нужно сразу.

И. Ильф, Е. Петров, “Золотой телёнок”

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

А можно пример?

Можно. Самый яркий пример, который в далёком 2017 году слегка перевернул моё отношение к этим кратным ускорениям – это опыт, который я получил на деловой игре “Проект Феникс”. Из списка выше второй пункт на игре никак не представлен (всё же игра – это лишь один рабочий день и никаких компьютеров), а вот остальные можно ощутить на себе.

Участников изначально “размещают” в единую команду. В течение дня, через четыре итерации, команда будет вынуждена разобраться и со входом (над чем работаем), и с процессом (как работаем).

Примечательно, что почти все команды в начале дня организуют свою работу так, как принято у них в компании. Игра – это такое зеркало. Бывает, что принято не задавать вопросов о задачах, которые принёс бизнес; “договориться” о рабочем процессе на словах; отдать право принятия почти всех решений начальнику; охранять свою территорию и не пускать на неё посторонних; активно помогать всем вокруг, внося ещё больше хаоса – много чего бывает. Измеренный Time to Market после первого раунда обычно составляет 25 минут на одну выполненную задачу, а доля задач, взятых в работу и дошедших до продуктива – от 25% до 50%, выполненных задач – от 1 до 3.

В конце дня часто видны другие результаты: Time to Market составляет от 40 секунд до 1,5 минут на одну задачу, доля взятых в работу и завершённых – 85-100%, выполненных задач – более 10. За то же астрономическое время раунда.

Вот это меня и поразило. Те же участники, что и утром, “ускорились” с 25 минут до 1. Не потому, что поняли, наконец-то, правила и механики игры – правила очень просты. Не потому, что игру “хакнули” – можно, конечно, но нет. Потому что в тестовом кейсе из четырёх пунктов выше проработали три. И если им с утра сообщить, что ожидается ускорение в 25 раз, то реакция будет предсказуемой – сказки же. Не бывает такого.

Верно, не бывает. Но точнее сказать так: бывает, но не у всех. Не каждая группа получает такой результат.

ТРЕНАЖЁР

Kanban Flow Metrics: управление потоковым производством на основе данных

Тренажёр про метрики на реальных примерах