Портал №1 по управлению цифровыми
и информационными технологиями

Почему стоит меньше рассуждать об Agile и больше о потоке

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

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

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

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

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

Чтобы двигаться вперёд, вам прежде всего необходимо проявить в потоке:

  • метрики, позволяющие оптимизировать решения на основе данных
  • фокус на ценностно-ориентированной гибкости через восходящую аналитику

Проблема производительности

Многие компании добились больших успехов в обеспечении полного жизненного цикла программного обеспечения. DevOps и непрерывная интеграция привели к тому, что компании быстро и часто доносят ценность до заказчиков.

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

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

Проблема ценности

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

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

Поток как инструмент раскрытия ценности

Технологии выявления ценностей во многих случаях недостаточно развиты и не ориентированы на ожидания заказчиков. Клиентоориентированность является отправной точкой для нового подхода к выявлению ценности.

Выявление ценности (discovery) в бережливых гибких методологиях – это по большей части способ поиска баланса. То понимание, которое даёт нам минимально жизнеспособный продукт (MVP) и итерационный подход к разработке, по сути является оценкой ценности, но это не процесс её выявления. Фактически, это приводит к очень «небережливой» беспорядочной форме использования новых решений. Компаниям предлагается попробовать и выяснить, имеет ли идея ценность в поставке (вниз по течению), а не исследовать ценность на ранних этапах (вверх по течению).

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

  • Часто предприниматель приходит из крупной компании, в которой он и его коллеги агрегировали потребность в новых продуктах для непокрытых сегментов рынка в течение длительного времени.
  • Исходя из личного опыта, предприниматель просто знает, что перед ним есть востребованный потенциал
  • Предприниматели знают, как использовать известную технологию для адаптации к новым потребностям рынка

Так возникают подрывные инновации, как описывал Клейтон Кристенсен. Проработанный механизм выявления ценности (discovery) помогает компаниям обнаружить потенциальные стрессоры рынка на раннем этапе, прежде чем они попадут в руки стартапа, который сможет ответить новыми ценностными предложениями.

Поток создания ценности использует глубокую сегментацию рынка, чтобы удовлетворить растущие потребности клиентов. Он позволяет акцентировать интерпретацию факторов на успех у клиентов в этих сегментах — идея, заимствованная у SaaS.

Поток помогает оценить существующее программное обеспечение, уникальные преимущества и базу активов ИС, чтобы узнать, нужно ли вам создавать, обновлять или адаптировать существующие активы. Существуют серьёзные последствия для ресурсов, когда вы выбираете стратегию построения или выбора новшеств, а не адаптации имеющихся резервов.

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

Выявление ценности (discovery) должно способствовать достижению ряда целей:

  • Является источником идей, которые действительно актуальны для существующих клиентов или способствуют привлечению новых клиентов
  • Позволяет понять, что сделает клиентов более удовлетворёнными
  • Уменьшает спекулятивные проекты и сокращает нагрузку на бэклог продукта
  • Даёт пространство для маневра или отката командам разработки, в случае, если новая функциональность не оправдывает ожиданий и вряд ли доставит ценность
  • Обеспечивает передовую линию защиты от конкурирующих компаний, получивших эту ценность раньше

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

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

Не скрывайте измерение ценности в потоке

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

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

Гайдн Шонесси , Фин Голдинг, Мик Керстен 
Оригинал статьи: Why You Should Be Talking Less Agile and More Flow

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT