На тренингах я рассказываю о том, что гибкие практики ориентированы на оптимизацию по скорости. Это очень легко понимается и принимается группой. Что тут сложного? Мы не за стопроцентную утилизацию, нам важно обеспечить максимальную скорость изменений. А дальше? Дальше я рассказываю о том, что целевая картинка – это не прирост скорости на 10-20-50 процентов, а кратное увеличение скорости поставки. Вот тут уже начинаются вопросы.
Люди, знающие разработку ПО не понаслышке, которые годами решают практические задачи в своем бизнесе, за редким исключением, не могут представить себе кратного ускорения без увеличения ресурсов. Для них рассказ о том, что возможно выпускать обновления кратно быстрее без переработок и увеличения количества людей, выглядит как попытка продать волшебную таблетку. Их сомнения явно читаются в задаваемых вопросах. Для того, чтобы двигаться дальше, нужно вернуть доверие.
В первую очередь, стоит еще раз напомнить, почему нам нужно кратное ускорение, а не прибавка в 10-50 процентов. Не секрет, что основная претензия бизнес-заказчиков в адрес команд разработки – это скорость. Бизнес работает в конкурентной среде с высокой неопределенностью, и быстрое получение новых возможностей от собственного ИТ является вопросом выживания. Гибкие практики призваны за счет культурных, структурных и инженерных преобразований увеличить скорость поставки. Но давайте смотреть правде в глаза. Эти преобразования на большом и сложном ИТ-ландшафте стоят дорого, очень-очень дорого. И без кратного ускорения эти затраты на такие преобразования никогда не окупятся.
Теперь поговорим о том, откуда можно взять это самое кратное ускорение. Давайте для начала представим жизненный путь задачи следующим образом:
Там, где находится желтый флажок, – возникла идея. Это еще не задача, которую разработка может начать решать. Это некоторое видение проблемы, решив которую, бизнес может получить преимущества или снизить свои риски. Идей у бизнеса всегда много. Гораздо больше, чем у разработки имеется фактических возможностей по их реализации. Часть этих идей погибнет в эволюционном отборе, про некоторые из них разработка даже никогда не узнает. Тем не менее, именно от момента возникновения идеи мы считаем время вывода на рынок, тот самый time-to-market, за который так переживает бизнес-заказчик. Итак, некоторое количество идей, преодолев естественный отбор, доходит до зеленого флажка. В этот момент происходит принятие решения о том, что мы точно будем делать эту штуку, и идея превращается в задачу (а скорее в набор задач) для разработки. Но мы помним, что задач у нас по-прежнему гораздо больше, чем возможностей. И очень редко у разработки есть возможность немедля начать работу над задачей, которую только что принесли. Особенно комичной в этом контексте выглядит попытка определить срок поставки задачи в точке принятия решения. Даже если мы сегодня можем точно оценить время, необходимое на производство этой задачи и тех задач, что стоят перед ней (а это уже неправда), все равно никто нам не сможет гарантировать, что завтра очередь будет такой же. Так что попытка угадать срок поставки в момент принятия решения о разработке – дело неблагодарное. Тем не менее, решение о производстве принято, и заказчик уже ожидает от разработки результат, несмотря на то, что разработка еще не начала работать над задачей. От зеленого флажка до поставки результата считается время ожидания (Customer Lead Time).
Что же дальше? Дальше команда разработки начинает работу по производству изменений. Именно за красным флажком, при переходе задачи через точку принятия обязательств, у разработки возникают обязательства доставить результат заказчику. Конечно, заказчик по-прежнему может отказаться от задачи. Это может произойти в любой момент, даже тогда, когда большая часть работы выполнена. Мы все читали «Манифест гибкой разработки» и знаем про постоянную готовность к изменениям. Но являясь ответственными, мотивированными профессионалами, (манифест писали именно для таких ребят) мы должны помнить о том, что чем ближе задача к стадии готовности, тем дороже обходятся связанные с ней изменения. Разработка должна помнить об этом и не давать забывать заказчику. От красного флажка (точки принятия обязательств) до момента поставки считается время в системе (System Lead Time). Это очень важный показатель. Время в системе – одна из ключевых характеристик, определяющих насколько эффективной является разработка. Анализируя статистику по этому показателю, можно с высокой вероятностью предсказывать сроки выпуска для новых задач, выявлять риски и классифицировать задачи. Но сейчас мы используем эту метрику для того, чтобы показать, каким образом можно добиться кратного ускорения поставки, не нанимая дополнительных людей и не работая шестнадцать часов в день вместо восьми.
Давайте пока рассмотрим только нашу производственную систему, не обращая внимания на то, что происходит перед ней. Итак, внутри нашей системы, как правило, много задач, очень много задач. Там присутствуют задачи разных типов, приоритетов и размеров. Этих задач гораздо больше, чем людей в команде. Я видел от нескольких десятков до нескольких сотен задач у команд из 7-9 человек. Эти задачи не возникли из ниоткуда и не собрались там по злому умыслу разработчиков. Все дело в том, что, разрываясь между срочным и важным, люди склонны отказываться от выбора и выбирать понятное. Зачем нам разбираться с текущей задачей, где ничего не понятно и нужно спросить человека, который вчера ушел в отпуск? Как раз для таких задач у нас есть статус «отложено». А вместо нее мы возьмем новую интересную задачку, мы же не бездельники… В итоге между точкой принятия обязательств и точкой поставки (исполнения обязательств) находятся десятки задач, в которые «вморожены» сотни человеко-часов. Очень недешевых человеко-часов! Мало того, что значительная часть этих трудозатрат станет безусловными потерями в чистом виде (задачи «протухают»), беда еще и в том, что наличие большого количества задач в системе затрудняет координацию и приоритизацию. Управлять этим застывшим потоком и поставлять хотя бы что-то оказывается непросто. Сомневаетесь? Это кажется незначительным? Давайте посмотрим на то, как выглядит обычная история жизни задачи в производственной системе.
Для отдельной задачи из всего времени, которое она находится в системе, в среднем 90% составляет время ожидания! А для большого количества команд эта цифра еще выше – 95-97%. Не верите, что у вас так? Давайте попробуем измерить реальное время производства (Touch Time) для выпущенных вами задач и соотнести его с временем в системе. Только честно!
Отношение времени производства ко времени в системе, выраженное в процентах, называется эффективностью потока. Как было сказано выше, для обычных команд разработки этот показатель находится в диапазоне от 3% до 10%. А теперь представьте себе, что благодаря сокращению количества работы в системе мы можем сократить ожидание для отдельно взятой задачи, с 95% времени до 70%. Эффективность в 30% – нормальный показатель для команд, управляющих работой в потоке. При этом время производства у нас останется тем же. Не нужно делать работу быстрее, достаточно только перестать начинать «лишнюю» работу и фокусироваться на доведении дел до конца. А если при этом мы еще за счет автоматизации минимизируем время на этапах, не добавляющих ценность (например, при тестировании) и избавимся от лишней работы? Вот вам, как минимум, трехкратный прирост в скорости на одной только производственной системе. Разумеется, это все не бесплатно. Уменьшая количество элементов (задач) в системе мы, скорее всего, получим некоторое снижение количества элементов, поставляемых за интервал времени (Delivery Rate). Но при этом мы получим кратное уменьшение времени в системе для всех поставляемых элементов и существенное снижение времени ожидания каждой задачи для бизнес-заказчиков. Выбирая между количеством и скоростью, мы делаем выбор в пользу скорости потому, что именно скорость является основным требованием бизнеса.
О том, с чего начинается путь к скорости и что же происходит там, где «водятся драконы», читайте в следующей статье. А лучше приходите на наши курсы по гибким практикам, и там мы разберем историю с кратным ускорением поставки более подробно.