При переходе к гибкому управлению разработкой очень часто можно столкнуться с проблемой, когда поток создания ценности отстроен частично, и в какой-то момент стыкуется с проектным управлением ИТ-разработкой. Такие гибридные модели организации труда существенно снижают пользу от перехода к гибкому управлению.
Ключевое преимущество гибкого управления ИТ-разработкой в динамично развивающемся бизнесе – это скорость создания новых возможностей для пользователей программного продукта. Когда нет потребности в быстрой адаптации к рынку и клиентскому поведению, когда развитие информационных систем идёт по заранее известным требованиям, проектный подход прекрасно работает и нет необходимости его трансформировать в Agile. Однако, если ИТ-продукты встроены в бизнес-модель и к темпам их развития предъявляются требования высокой скорости, то очень важно отстроить поток создания ценности End-to-End: от непрерывного потока требования со стороны бизнеса, до быстрой и равномерной поставки решений.
И достаточно часто можно наблюдать, что ИТ-разработчики трансформируют свой рабочий процесс до определённого момента, но в конце, «на последней миле», задачи существенно задерживаются. Там возникают процессы, препятствующие непрерывной поставке: релизные циклы, длительное приёмочное тестирование, синхронизация со смежниками. Привычный для проектного подхода этап внедрения результатов сохраняется в изначальном виде и не встраивается в потоковую систему.
В итоге мы наблюдаем кратное ускорение процесса разработки, которое на «последней миле» налетает на барьер медленного донесения ценности до бизнеса и теряет всё преимущество. А при том, что переход к управлению на основе Agile всегда сложен для компании, важно продумать, как будет организована поставка ценности, чтобы сохранить гибкость end-to-end.
Постарайтесь уйти от релизных циклов
Как правило такая фрагментарная поставка обусловлена силой привычки, сложившейся при итеративно-инкрементной поставке на основе этапов проекта. Таким способом в проектном подходе подерживается возможность получить от бизнес-заказчика информацию, сопровождающую требования к разработке. Но это не единственный способ организации циклов обратной связи.
Потоковое управление так же живёт в циклах планирования задач и подтверждения попадания в ожидания заказчика, но рекомендует делать это на основе непрерывной поставки ценности, CI/CD-конвейера. Обмен информацией идёт по каналам коммуникации в регулярных циклах, но сами требования бизнеса реализуются и поставляются в продуктивную среду непрерывно.
Методологически такой подход организуется на основе DevOps. Группы разработки и эксплуатации объединяются в единую команду, которая несёт ответственность и за весь процесс создания бизнес-ценности, и за её донесение до потребителя. Обслуживание потока требований координируется DevOps-командой совместно и целиком. Такая организация труда также рассчитана на автоматизацию всех процессов, не требующих интеллектуальных затрат высококвалифицированных специалистов.
При этом часто можно услышать возражение, что установка в продуктивную среду требует каких-то особых условий, например минимальной пользовательской активности, чтобы провести её безболезненно. И иногда это действительно так.
Важно подойти к оценке таких ограничений с позиции выгоды и потерь для бизнеса. Если стоимость задержки реализации конкретных требований выше стоимости предполагаемых рисков от временного нарушения работоспособности ИТ-продукта, то нет причин тормозить непрерывную поставку, подвешивая готовые задачи до релиза. Разумеется, при этом непрерывно необходимо заботиться о качестве технических решений и совершенствовать информационную инфраструктуру, чтобы избежать неприятных инцидентов при эксплуатации ИТ-продукта.
Если же стоимость риска потери работоспособности системы для бизнеса высока, необходимо определиться для всех ли категорий задач это справедливо. Как правило в потоке создания ценности присутствуют задачи с очень разной стоимостью задержки и рисков. Необходимо выделить те категории задач, которые можно доносить до потребителя непрерывно, и не тормозить их, собирая в релизный пакет «за кампанию» с задачами, требующими особых условий эксплуатации.
Категоризация задач и выработка системы правил, обеспечивающей уход от релизного цикла к непрерывной поставке хотя бы части потока создания ценности, позволяет сделать поставку для бизнеса более равномерной и доносить больше ценности в коротком периоде времени. То есть ускоряет поток.
Согласовывайте действия между ИТ-разработкой и бизнесом
Ещё одним частым барьером на пути потока создания ценности встают так называемые приёмочные испытание или тестирование на стороне бизнеса. В основном это происходит из-за того, что в бизнесе не произошла организационная перестройка от проектного подхода, когда приёмка отдельных этапов могла идти параллельно деятельности разработчиков, а следовательно, не задерживала их работу.
Гибкие методологии управления основаны на концепции клиентоориентированности, т.е. необходимо быстрое подтверждение от бизнеса, что ценность создана, иначе обязательства разработчиков не считаются выполненными.
Это обусловлено необходимостью непрерывно извлекать опыт и корректировать свой производственный процесс, чтобы поддерживать интенсивный поток задач, проходящий через разработку. Без извлечения опыта разработчики не могут определить пропускную способность потока и темпы развития ИТ-продукта. А это, в свою очередь означает, что теряется возможность прогнозировать сроки поставки для бизнеса.
То есть, если на «последней миле» задачи задерживаются, поскольку не поступило подтверждение от бизнеса, что работа сделана, невозможно посчитать, сколько задач делается в определённый временной промежуток (например, в неделю). И не возможно достоверно определить среднюю продолжительность работы над задачей.
А это означает, что, когда бизнес запрашивает сроки реализации своих требований, разработчики не могут опираться на точные данные при их определении. Так и возникает знаменитое «сделаю за час в течение недели».
Чаще всего такая поломка на выходе потока создания ценности обусловлена проблемами с планированием на входе. Циклы обратной связи выстроены недостаточно регулярно. И бизнес слишком поздно получает информацию о том, какие задачи идут в работу, а следовательно, не успевает подготовить изменения в физическом мире или выделить ресурсы для проверки изменений в ИТ-продукте, которые произвели разработчики.
Здесь невозможно провести какие-то односторонние изменения только на стороне разработки, а требуется отстройка совместного управления потоком создания ценности. Я ни в коем случае не проповедую Business Agility, для многих компаний гибкость в иерархических структурах управления в бизнесе невозможна, да не нужна. Однако определённая трансформация процессов взаимодействия между бизнесом и ИТ-разработкой потребуется, чтобы не потерять преимущества ускорения Time-to-Market.
Бизнесу необходимо активно включаться в планирование темпов развития ИТ-продукта и синхронизировать свои действия во внешней среде с тем, что делают разработчики в настоящее время. В работу не должны поступать задачи, которые бизнес не готов принять на выходе.
Не стоит забивать и замедлять поток создания ценности требованиями, реализация которых не нужна прямо сейчас. Лучше предоставить разработчикам возможность организовать свою рабочую среду или улучшить компетенции, чем утилизировать ресурсы и загружать их невостребованной работой.
Часто можно услышать, что интересантам со стороны бизнеса не хватает времени и возможности соучаствовать с командой в планировании потока задач. Однако эта проблема легко решается равномерностью циклов обратной связи. Чем они более регулярные и стабильные, тем проще поддержать нужную интенсивность обмена информацией.
Собраться на 1-2 часа раз в неделю или две с продуктовыми командами разработки и обсудить, какими задачами пополняется очередь на вход в поток создания ценности, потребует гораздо меньше усилий, чем неделями напролёт согласовывать через переписку приёмочное тестирование для уже готовых задач.
Чёткая регулярность встреч, хорошая подготовка повестки и грамотная фиксация результатов обсуждения – самый простой способ сэкономить время и облегчить управленческие затраты в потоке создания ценности.
Позаботьтесь о развитии команд
Ещё одна распространенная проблема рассинхронизации, тормозящая поставку ценности на «последней миле» возникает, когда сложные бизнес-задачи решаются за счёт одновременного изменения сразу нескольких ИТ-продуктов, обслуживаемых несколькими командами ИТ-разработки. В этом случае каждая команда создаёт свой кусочек бизнес-ценности, но воспользоваться ею можно, только когда все кусочки будут созданы и объединены в общую поставку ценности.
Тут часто возникают две проблемы. Во-первых, как и в случае синхронизации с бизнесом, наблюдается расхождение процессов планирования в нескольких зависимых командах. И здесь можно дать все те же рекомендации по выстраиванию регулярных циклов обмена информацией и созданию правил оперативного информирования о любых изменениях, влияющих на зависимые задачи.
Во-вторых, возникают проблемы интеграции и тестирования общей сборки решения в едином тестовом контуре. Не понятно, кто должен принимать на себя ответственность организовать процессы, чтобы интеграция состоялась.
Гибкие методологии управления довольно требовательно относится к самоорганизации команд. Перекладывать усилия на одного ответственного исполнителя – плохой способ решить проблемы, когда мы говорим об управлении потоком, а тем более о синхронизации нескольких потоков. Тут требуется совместная ответственность и усилия всех команд, задействованных в решении крупной бизнес-задачи.
При этом интеграция решений зачастую требует серьёзной технической и аналитической экспертизы, а следовательно, специалистов, обладающих соответствующими знаниями. Это проблемная зона, которую стоит прорабатывать и развивать при управлении быстро развевающимися ИТ-продуктами.
Поскольку самоорганизация и профессионализм являются принципиальными требованиями к гибким командам, требуется приложить определённые усилия к выстраиванию системы развития команд. А кроме того необходимо будет диагностировать и анализировать общий уровень зрелости производственной системе, чтобы взаимодействие между командами делалось на основе понимания зависимых процессов. Лучше всего такой анализ проводить на основе объективных данных, собранных через метрики, характеризующие поток создания ценности.
Вам потребуется не только трансформировать отдельные команды, но выровнить общий уровень зрелости для зависимых команд, чтобы добиться ускорения для поставки ценности по сложным и объёмным бизнес-задачам. Альтернативой является необходимость разрывать интеграционные зависимости между смежными командами, но такое решение возможно не во всех организациях. Поэтому позаботиться о развитии и синхронизации команд сложный, но, зачастую, единственный путь совершенствования.
Правильно установите «финишный флажок»
Так или иначе прохождение «последней мили» требует фокуса внимания и ответственности со стороны всех соучастников управления потоком создания ценности: интересантов от бизнеса, разработчиков и группы эксплуатации. И здесь важно визуализировать поток создания ценности и грамотно выставить финишную черту, пересекая которую задача считается выполненной.
Часто разработчики склонны ставить финальный флажок после этапа тестирования, поскольку не обладают полномочиями влиять на инфраструктуру и, тем более, организационные процессы в бизнесе. Эта потеря фокуса и провоцирует остановку уже готовой задачи и недонесения её до адресата ценности.
Очень важно, чтобы бизнес, разработка и эксплуатация действовали сплоченно в финале. Для этого они должны иметь совместную ответственность и полномочия по управлению задачами. Иначе все призывы к новой организации труда так и останутся красивой декларацией, не имеющей отношения к реальности.
Процесс отстройки коммуникаций и взаимодействия между всеми соучастниками, управляющими потоком создания ценности, действительно сложен. Но все необходимые изменения возможны при комплексном системном подходе к организации совместной работы и разумном следовании принципам гибких методологий.
