Работая над созданием ценности, команда ИТ-разработки живёт в привычных для неё организационных процессах. Непредвзято взглянуть на свой поток и разобраться, где в нём существуют проблемные зоны, требующие улучшения, бывает очень не просто. Задачки ставятся и двигаются от этапа к этапу по сложившемуся маршруту. И кажется, что все логично, что ускорить этот процесс нельзя без увеличения количества исполнителей. Но так ли это на самом деле?
Внутри потока создания ценности могут существовать процессы, существенно замедляющие его течение, делающие его непредсказуемым и неравномерным. Давайте рассмотрим причины, которые препятствуют движению элементов работы в потоке.
Недостаточно информации для решения задачи
Для того чтобы элементы работы продвигались по потоку создания ценности, они должны сопровождаться информацией, помогающей определить выбор варианта реализации. Эта информация должна давать ответ на вопрос, в чем ценность от изменений, которые создаются при решении данной задачи.
В момент постановки задачи на развитие продукта, возникает информация, описывающая ожидания заказчика: что должно измениться в мире, какие возможности получает пользователь, в чем ценность новой функциональности? Далее, при движении задачи по этапам потока создания ценности, эта информация детализируется и пополняется: формализуется требования, определяется приоритет, проектируется системное решение, определяются тестовые сценарии и т.п.
Очень частая дисфункция в потоке создания ценности – недостаток информации при переходе с этапа на этап. Как следствие, требуются многократные уточнения постановок, требований, логики, тест-кейсов и т. п. Задача возвращается по этапам, специалисты постоянно отвлекаются на уточнения, нарушается направленное движение элемента работы к завершению, к поставке ценности. И зачастую это происходит не из-за некачественно сделанной работы, а из-за отсутствия зафиксированных и понятных всей команде критериев, обеспечивающих всю полноту необходимой информации.
Разработка ИТ-продуктов происходит в очень неоднородной среде. Все задачи разные и по размерности, и по содержанию. И, казалось бы, не могут обладать универсальным набором критериев готовности к переходу на следующий этап технологического цикла. Однако, процесс обработки задач вне зависимости от их особенностей, в целом сходен. А следовательно мы можем закрепить требования к этому процессу.
Важно собрать и зафиксировать вопросы, возникающие у специалистов на каждом этапе разработки, и закрепить ответы на них в явном виде. Где находятся задачи и как определяется, кто над ними работает в данный момент? В каком формате фиксируется понимание ценности? Какая информация обязательно должна присутствовать в описании задачи после каждого этапа обработки? Какие есть типичные группы задач и кем в команде они обрабатываются?
Создав список вопросов в виде чек-листа критериев готовности задачи к переходу на следующий этап в потоке создания ценности, и обеспечив его заполнение, можно избежать дополнительных уточнений и возвратов по этапам.
Отсутствие проверки рисков
Помимо недостаточности информации, фокусирующей на создании ценности, ещё одной частой причиной возвратов задачи и её застревания на каком-то этапе в потоке создания ценности, является отсутствие проверки на риски перед взятием элемента в работу.
Все задачи в очереди на вход в поток создания ценности должны проходить проверку на готовность к принятию в работу. Помимо фиксации требований, описания ценности и приоритизации необходимо определить, не будет ли элемент заблокирован внешними или внутренними факторами риска.
К внутренним рискам относятся стоп-факторы, связанные с наличием достаточного количества функциональных ресурсов в команде, то есть специалистов, способных продвинуть задачу к решению в данный период времени. Может кто-то уходит в отпуск, на курсы повышения квалификации, или это внешний специалист, работающий по собственному графику. Все это необходимо учесть, до взятия задачи в поток. Кроме того, могут возникать внутренние риски, связанные с решением технических вопросов: выплатой технического долга, рефакторингом, автоматизацией и подобными процессами, оттягивающими на себя ресурс команды.
К внешним рискам относится синхронизация с другими командами в случае жёстких интеграционных зависимостей. Такая синхронизация должна проводиться пока задача находится в очереди на вход в поток создания ценности, чтобы элемент работы не оказался заблокирован на выходе из-за того, что зависимая команда не готова к его обработки. Кроме того, необходимо учесть риски блокировок в ходе перенастройки тестовых сред, API, среды эксплуатации и т.д. Информация о таких потенциальных ситуациях должна быть собрана по каждой задачи на входе в поток создания ценности.
Не следует брать в работу задачу, для которой высок риск оказаться заблокированной в потоке создания ценности. Это повод согласовать с заказчиком понижение ее приоритета до того времени, когда риск будет снят. Разумеется, для устранения риска необходимо приложить все возможные усилия, и обеспечить принятие задачи в работу как можно быстрее.
Возникновение обратного движения в потоке
Выше уже описан один из вариантов обратного движение элементов в потоке создания ценности – возврат задач на предыдущий этап для уточнения требований. Он особенно часто встречается, когда отстройка течения через систему правил только начата, и идут первые шаги эволюционных улучшений.
Но зачастую обратное движение элемента в потоке регламентируется как неотъемлемая часть жизненного цикла задачи. Например, очень часто для всех задач выделяется отдельный этап ревью кода. Поскольку на данном этапе ценность не создаётся, но специалисты расходуют свои ресурсы на интеллектуальную работу над задачей, в потоке возникает завихрение, повторная обработка элемента работы.
Задумайтесь, действительно ли такая трата ресурсов идёт на пользу вашей производственной системе? Чем обусловлена необходимость дополнительной обработки? Если это история про передачу навыков, про развитие компетенций молодого специалиста, то тут можно увидеть целесообразность. При этом завихрение в потоке создания ценности существует временно, пока не произойдёт передача опыта. Однако, если это привычное существование, в котором усматривают возможность защититься от человеческих ошибок, то это нерациональная интеллектуальная деятельность специалистов. При таком подходе теряется фокусировка на создание ценности. Оцените, так ли много бывает у вас ошибок, чтобы каждый элемент работы проходил двойную проверку? В чем причина частых ошибок, что стоит улучшить, чтобы избежать лишних трат интеллектуального ресурса?
Ревью кода – это яркий, но не единственный пример, когда привычная организация рабочих процессов создаёт неоправданные сложности в движении элементов в потоке создания ценности. Причём зачастую, такие этапы обработки являются скрытыми, не проявленными в рабочем процессе. Без правил управления движением задач через них. И очень важно разобраться в рабочем процессе и понять, где задачи движутся против потока создания ценности, где ведётся деятельность, ценности не добавляющая и имеющая сомнительную пользу.
Длительное время в очередях
В отличие от возвратного движения, которое можно и нужно избегать, очереди в потоке создания ценности присутствуют всегда. Это происходит из-за наличия «узких горлышек» – участков производственной системы, где обработка элементов идёт медленнее, чем на предыдущем этапе. Это нормальная ситуация, позволяющая балансировать нагрузку на каждый участок потока создания ценности. Очереди регулируют вытягивающую систему, подготавливая элементы, готовые к передачи на следующий этап. Главное, не давать очереди разрастаться и вовремя останавливать обработку задач перед «узким горлышком».
В ИТ-разработке элементы работы не материальны и обладают разной размерностью, а процесс их обработки является слабо формализуемой интеллектуальной деятельностью. Очень трудно предсказать, насколько сложно пойдёт поиск вариантов реализации для каждой задачи. Поэтому управление очередями и поиск баланса нагрузки на каждом этапе создания продукта – это процесс сложный. Очень важно, чтобы все очереди были проявлены и качественно визуализированы.
При этом, так же как с этапами, очереди могут быть скрытыми. Чаще всего это связано с необходимостью дополнительных согласований в процессе разработки с различными соучастниками процесса – заказчиками, подрядчиками, службой безопасности и т.п. Такие процессы так же могут быть не оправданы с точки зрения пользы для производственной системы, а складываться из унаследованных рабочих процессов, к которым команда просто привыкла. Всегда необходимо задаваться вопросом, нужны ли дополнительные согласования, и как мы можем минимизировать потери времени, связанные с ними?
Самым популярным вариантом накопления очереди, пожалуй, является создание длительных релизных циклов. Эта очередь может складываться из ручного регресса, согласование поставки ценности на выходе, длительной проверки на тестовых группах и т.п. То есть всё, что тормозит поставку ценности конечным адресатам, когда работа над созданием ценности уже завершена.
Не менее часто очереди возникают из-за того, что визуализацию задач превращают в «записную книжку». Пусть эта задачка повисит перед глазами, чтобы не потеряться. Кажется, что так проще увидеть объем нагрузки, который предстоит реализовать специалисту. Кажется, что это ускорит процесс взятия задач в работу. Но вместо ускорения происходит потеря фокусировки, теряется понимание приоритетов, возникают ненужные переключения с задачи на задачу, требующие дополнительных когнитивных затрат.
Такие перегруженные очереди не только замедляют поставку ценности, но и создают застой в потоке, увеличивая затраты на управление процессами. Ведь скопившаяся очередь требует внимания со стороны разработчиков, аудита состояния, дополнительных действий по проверке текущего статуса элемента работы и т.п. Производственная система становится менее прозрачной, а поток элементов работы превращается в застойное болото.
Поэтому важно не копить очереди, а равномерно двигать задачи к завершению, придерживаясь принципа вытягивания. Чётко проявленная и хорошо визуализированная очередь на каждом этапе создания ценности позволяет понять реальную пропускную способность производственной системы, измерить её для более продуманного баланса нагрузки на команду. А также выявляет проблемы с организацией коммуникаций между различными соучастниками цепочки создания ценности. Ведь скопившаяся очередь на каком-то этапе или на выходе, зачастую означат проблемы с проверкой полноты информации на входе: заинтересованные лица не были готовы к согласованиям или приёмке работы, когда команда принимала на себя ответственность за выполнение задачи.
Поиск таких дисфункции позволяет проявить, какие организационные изменения необходимо предпринять, чтобы улучшить работу над созданием ИТ-продукта. Каких критериев важности и правил управления задачами не хватает? В каких местах плохо организовано взаимодействие и обмен информацией? Какие последовательные эволюционные шаги по ускорению потока создания ценности нужно предпринять?
Как найти проблемные зоны в потоке создания ценности?
Привычный рабочий процесс может быть непрозрачен для самой команды разработки. Чтобы разобраться в том, как движутся задачи в производственной системе, визуализировать и взять под осознанное управление полезно использовать такой инструмент, как картирование потока создания ценности.
Картирование потока (Value Stream Mapping, VSM) позволяет проявить и визуализировать этапы обработки задач, объединить их с информационными потоками и связанными метриками, что обеспечивает лучшее понимание качества организации процессов в производственной системе. Создание визуальной карты потока даёт возможность увидеть, где фактическая ценность добавляется в ИТ-продукт, а где присутствуют проблемные зоны, замедляющие поток создания ценности.
Картирование потока создания ценности позволяет ответить на вопросы, как сейчас организована производственная система as is, чтобы можно было запланировать шаги по улучшению процессов. В ходе картирования можно получить ответы на целый спектр важных вопросов. Кто является источником запросов на создание ценности, сколько их? Как выстроена сквозная приоритизация, как балансируются задачи от всех источников на входе в поток? Достаточно ли информации, фокусирующей команду на ценности, дающей понимания о выборе предпочтительных вариантов реализации? С кем выстраивать коммуникации? Как организована передача задач между этапами в потоке создания ценности? Где есть завихрения, возвратное движение элементов работы, как часто и почему оно возникает? Все ли этапы обработки задач проявлены, визуализированы и необходимы? Все ли очереди визуализированы, откуда они берутся и как балансируются? Как организован выход потока создания ценности, как осуществляется приёмка и подтверждение от бизнеса, что ценность поставлена адресату, а обязательства команды разработки выполнены?
Если вам интересно подробнее узнать об этом инструменте, вы можете посетить наш мастер-класс на IT Management Forum «Картирование потока создания ценности – при чем тут поток и что такое ценность?». Для наших читателей мы дарим скидку 15% на участие в форуме по промокоду itmf21promo15Cleverics Ссылка на регистрацию.
Проявив проблемные зоны в потоке создания ценности, можно разобраться какие действия, согласования, уточнения являются лишними, тратящими время ценных специалистов на деятельность, не создающую ценность и не способствующую её созданию. Такие процессы должны быть устранены за счёт последовательных организационных изменений, создания системы правил, задающих прямое русло течения потока и способствующих непрерывному движению элементов работы от очереди на входе до поставки ценности и получению обратной связи.
Устранение лишней работы в конечном итоге приводит к ускорению потока создания ценности, обеспечивает быструю, равномерную и предсказуемую поставку. Как говорится, делайте то, что нужно, а что не нужно – не делайте!
