Текст книги "Менеджмент цифрового продукта. От идеи до идеала"

«Давайте сначала все по договору закроем, а потом начнем вносить правки», – именно так я отвечал клиенту, управляя небольшой компанией заказной разработки. Планы разработки шли тогда 3 4 квартала и уже на 1-2-м квартале накапливалось смещение сроков, и изменения в процессе – даже очевидные и существенные – были подобны смерти.

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

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

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

➠ Проектирование, в результате которого мы получаем проект отеля на 20 номеров разной комфортности и вместимости, с открытым бассейном.

➠ Вырываем котлованы под основное здание и под бассейн.

➠ Возводим стены этаж за этажом.

➠ Ставим крышу.

➠ Проводим отделку.

➠ Строим бассейн.

➠ Запускаем постояльцев.

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

Гибкий подход позволяет возвращать инвестиции как можно раньше, постепенно наращивая объем входящего денежного потока.

Рассмотрим строительство отеля с активным применением гибкого подхода:

➠ Привозим на участок жилой блок-контейнер.

➠ Делаем рекламу и запускаем жильцов.

➠ Собираем обратную связь об их предпочтениях: например их полностью устраивает уровень комфорта блок-контейнера.

➠ Входящий денежный поток позволяет закупить в сезон еще несколько контейнеров.

➠ По обратной связи мы понимаем, что вместо открытого бассейна постояльцам не хватает теннисного корта.

➠ Возводим теннисный корт.

➠ Собираем статистику по составу отдыхающих семей, что позволяет скорректировать проекты блок-контейнеров по наиболее востребованным сценариям; это позволило увеличить наполняемость и снизить расходы на рекламу

➠ Полученные данные о финансовой модели привлекли инвестора, который вложил деньги в еще несколько контейнеров и расширение участка.

Рис. 3.1. Сравнение водопадного и итеративного подходов

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

Разумеется, гибкий подход не всегда и не везде показывает максимальную эффективность. Давайте рассмотрим области применимости разных типов подходов.

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

В 1999 году Дэйв Сноуден из IBM Global Services предложил свою модель классификации «миров», в которых приходится действовать. Модель называется Cynefin (среда обитания, пристанище), и в ней определены четыре операционных контекста:

➠ Simple (понятный или очевидный) – мы находимся в предсказуемой среде, все объекты и процессы знакомы и можно применять сложившиеся лучшие практики для достижения результата.

➠ Complex (комплексный, сложный в значении многосоставный) – в этом операционном поле причинно-следственные связи можно получить ретроспективно, в результате совершенного действия. Тут работает цикл «исследуй-восприни-май-реагируй».

➠ Complicated (запутанный, сложный в значении содержащий неизвестные элементы) – в этом домене мы осознанно двигаемся в неизвестную область. Это мир, где нужно разобраться в новых сущностях, приобрести экспертизу в новом деле, например открыть новый рынок для уже существующей компании.

➠ Chaos (хаотичный) – мир, в котором нельзя полагаться на прогнозы и нужно экспериментировать. Это как идея для стартапа, его жизнеспособность может быть доказана только после коммерческого эксперимента.

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

Впоследствии Ральф Стейси в своей книге «Стратегический менеджмент и организационная динамика – вызов сложности» связал операционные контексты с уровнем ясности требований «что мы делаем» и наличием экспертности «как мы делаем».

Рис. 3.2. Квадрант операционных контекстов

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

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

Рис. 3.3. Пример диаграммы Ганта

Классическое представление водопадного плана – диаграмма Ганта, приведенная на рис. 3.3.

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

В моей практике был период, когда я делал сайты-визитки на заказ. На каждый этап работ был определен объем трудозатрат каждого участника, например «дизайн одного варианта главной страницы по утвержденной концепции» включал в себя 16 часов работы дизайнера, 2 часа арт-директора и2 часа аккаунт-менеджера. Суммарная длительность этапа, соответственно, составляла 8 часов. Подобная унификация позволяла считать бюджет и формировать график работ автоматически с использованием специального калькулятора в Excel, практически в реальном времени общаясь по телефону с потенциальным заказчиком.

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

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

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

Рис. 3.4. Горизонтальная и вертикальная декомпозиция

Горизонтальная декомпозиция порождает горизонтальную интеграцию[31]31
  Горизонтально интегрированная компания – это компания, элементы структуры которой связаны со стадиями производства, например департамент дизайна, департамент разработки и пр., в отличие от вертикально интегрированных компаний, элементы структуры которой связаны с источниками прибыли и, по сути, представляют собой обособленные бизнесы внутри одной компании.


[Закрыть] компании, при которой она распадается на этажи, отвечающие за определенный этап.

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

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

Симптомом может служить ситуация, когда дизайнеры начинают жаловаться, что сделали классный дизайн, а вот они (показывают в неопределенном направлении) опять все испортили – не смогли сверстать.

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

Требования к качеству артефакта становятся все выше и избыточнее (это же проблемы верхнего этажа!), а процедура приемки – все дольше. Как следствие, мы имеем отходы на переработку артефакта и смещение сроков из-за цикла доработок.

Водопадный подход плохо переносит исключительные срочные ситуации. Например, если нужно срочно что-то починить и доработать в одном из проектов, это смещает сроки по остальным. На этот момент компания становится вертикально-интегрированной, и все работают сообща в кросс-функциональной[32]32
  Кросс-функциональная команда – объединение людей с разными компетенциями для достижения общей цели.


[Закрыть] команде для достижения цели.

Итак, водопадный подход максимально эффективен, если понятно, что и как делать. Идеально, если это регулярно повторяемые однотипные проекты.

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

Когда есть четкое понимание, что делать, но нет понимания как, лучше всего работает Scrum. Детально мы будем разбирать этот фреймворк в и. 3.2, а сейчас обсудим общие идеи.

Для описания Scrum идеально подходит поговорка «слона нужно есть по частям». Комплексная задача разделяется на несколько поменьше, и, решая небольшие задачи, команда постепенно приобретает экспертизу и приходит к цели.

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

Один из основных принципов Scrum – это итеративность, при этом каждая итерация должна нести ценность для конечного пользователя. Каждую итерацию команда проясняет объем функциональности, который планирует реализовать в следующем спринте. В конце каждого спринта команда демонстрирует результат, анализирует актуальность процессов, корректирует их при необходимости и планирует, что будет реализовано в следующем спринте.

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

Scrum позволяет быстро достигать видимых результатов. Это создает позитивную атмосферу динамики и движения вперед.

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

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

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

Из минусов можно отметить его контринтуитивность и тесную связь с культурой компании.

Как уже говорилось ранее, компании быстро интуитивно могут прийти к водопадному процессу. Scrum же требует высокоуровневого понимания всех элементов и их связи.

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

Идеально, если Scrum внедряет сертифицированный эксперт с опытом внедрения и обладающий практическим опытом работы по фреймворку в роли Scrum-мастера.

Scrum подразумевает прозрачность, плоскую структуру, высокий уровень самостоятельности и фокус на результат.

Если среди проблем участники команды перечисляют:

➠ непонятные цели поставленных задач или беспричинную срочность;

➠ двоевластие;

➠ недоступность владельца продукта или стейкхолдеров;

➠ выработку человеко-часов важнее ценности поставки,

то, скорее всего, Scrum/Agile внедрен в компании декларативно, а за фасадом скрываются совсем другие процессы.

В этом случае Scrum может показать обратную эффективность.

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

Kanban (яп. , – вывеска, рекламный щит) – это важнейший элемент бережливого производства, который глубоко интегрирован в гибкие подходы к разработке.

Изначально Kanban был создан для визуализации прохождения артефактов в процессе производства Toyota.

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

Например, в цикле открытий, который подробнее будем рассматривать в главе 4. Лица, ответственные за дискавери с фиксированной периодичностью (например, один раз в неделю), собираются для фиксации прогресса.

На рис. 3.5 представлен пример Kanban для цикла дискавери.

Рис. 3.5. Пример Kanban для управления циклом открытий

Следует обратить внимание на ограничение количества спикеров в каждой ячейке (практика WIP limit[33]33
  WIP limit (сокр. Work In Progress limit, с англ. – ограничение работ в процессе) – практика ограничения элементов, которые одновременно в работе.


[Закрыть]). Подобный подход не дает возможности сфокусироваться на одной работе за раз и, не накапливая промежуточные артефакты, доводить дело до конца.

Еще одна важная практика Kanban – четкие критерии перехода из стадии в стадию.

Третий инструмент, «плавательные дорожки» (swimlane), позволяет видеть зависимости между двумя командами, которые работают в продукте, и приходить на помощь в случае, если у кого-то происходит «пробуксовка».

Kanban позволяет быстро выявлять проблемы в процессе. В случае, показанном на рис. 3.5, у второго владельца продукта происходит «затоваривание», он набирает много задач и из-за потерь на переключении падает фокус. При этом много задач застревает в накопителях, а значит, он не доводит дело до конца. У третьего владельца продукта проблемы другого рода – у него есть пустые ячейки, что говорит о том, что время, возможно, расходуется недостаточно эффективно.

Kanban может использоваться Scrum-командой для ежедневного отслеживания прогресса – движения элементов функциональности (пользовательской истории) от ToDo[34]34
  ToDo (образовано от англ, to do – работы к выполнению) используется разработчиками во многих случаях, в том числе в статусах задач.


[Закрыть] к Done или для движения задач разработчиков в процессе выполнения одной пользовательской истории в отдельной дорожке (такой Kanban называется Scrum-доска или Scrum-борд).

Рис. 3.6. Scrum-доска (слева) и Kanban-доска статуса функциональности (справа) для управления спринтом в режиме «роения»

В примере на рис. 3.6 команда взяла в спринт три истории и разбила реализацию каждой из них на задачи отдельных исполнителей. Современные таск-трекеры типа Jira могут отображать Scrum-доску в двух представлениях: в разрезе задач и в разрезе поставленной функциональности (историй). Если все задачи по истории перенесены в Done, то и история переносится в Done. Подобный подход позволяет делать акцент на том, чтобы двигались пользовательские истории (конечный артефакт, ценный для пользователей), а не на том, как двигаются задачи разработчиков (промежуточный артефакт). Это позволяет избежать ситуации, когда к концу спринта закрыто большинство задач, но не сделано ничего ценного. Вторая хорошая практика – фокусироваться на одной истории за такт (практика «роение»). Это дает максимальный фокус и уменьшает потери при переключении между историями.

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

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

Бережливый означает, что проверить потенциальную жизнеспособность продукта нужно с минимальным количеством отходов.

Для этого из продукта и из процесса его разработки нужно убрать все лишнее, чтобы минимальными затратами и максимально быстро проверить гипотезу жизнеспособности. Такой продукт называется минимально жизнеспособным продуктом или общепринятым сокращением MVP. Часто в этом значении используется термин «пилотный проект».

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

Вариант 1. Гипертрофированный водопадный подход:

➠ Закупить партию велосипедов.

➠ Арендовать склад.

➠ Арендовать магазин.

➠ Заказать брендинг для компании.

➠ Заказать дизайн интерьера.

➠ Сделать ремонт в магазине.

➠ Пошить униформу.

➠ Нанять персонал.

➠ Сделать сайт с каталогом продукции.

➠ Заказать в рекламном агентстве кампанию.

Вариант 2. Гипертрофированный Lean startup подход:

➠ Дать бесплатное онлайн-объявление о том, что продается винтажный велосипед, используя фото из интернета.

➠ В случае, если кто-то откликнется, перепродать велосипед, доставив самостоятельно.

➠ Проанализировать, может ли бизнес быть прибыльным и как увеличить объем продаж:

➠ заказ напрямую у поставщика;

➠ закупка оптом;

➠ организация собственной службы доставки;

➠ др. вариант.

➠ Итеративно внедрять улучшения в бизнес, чтобы дать ценность максимальному количеству пользователей.

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

Проблема первого варианта в том, что затрачен максимальный объем инвестиций еще до того, как ценность была доказана. В случае неуспеха риск потери очень велик. Бизнес, созданный по этому варианту, обладает множеством компонентов, и в случае неудачи непонятно, какой элемент нужно улучшить. Еще одна, менее очевидная проблема первого варианта – он с самого начала начинает генерировать расходы.

Подход бережливый стартап (второй вариант) позволяет без избыточных издержек протестировать гипотезу жизнеспособности продукта, фиксируя при этом риски на каждом этапе. Как только становится понятно, что модель не сходится[35]35
  Сходимость финансовой модели – когда для моделируемого объекта (бизнеса, продукта и т. п.) наступает момент прибыльности (доходы превосходят расходы).


[Закрыть], есть возможность моментально отказаться от продолжения эксперимента.

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

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

Есть несколько популярных способов добиться сокращения издержек на тестирование гипотезы жизнеспособности.

1. Ограничение функциональности. Убрать из продукта все лишнее, оставив только те функции, которые позволяют проверить гипотезу жизнеспособности. Как правило, это новые, уникальные функции (дифференциаторы), которых нет у конкурентов или неизвестна их эффективность.

2. Ограничение качества реализации функциональности. Намеренное занижение качества пользовательского опыта для сокращения стоимости и сроков разработки. Например, использование готовых компонентов интерфейса может быть не оптимальным с точки зрения клиентского путешествия – потребуется большее количество действий для достижения результата, чем если бы компоненты разрабатывались непосредственно под данную задачу с учетом лучших практик. Другой вариант: использование чат-бота в мессенджере вместо классического приложения с экранными формами. Это позволяет очень быстро разработать функциональность с ограничениями в UX[36]36
  UX (англ, user experience) – пользовательский опыт.


[Закрыть], свойственными диалоговым интерфейсам.

3. Ограничение стабильности. Продукт работает стабильно только для количества пользователей, достаточного для получения репрезентативных данных[37]37
  Репрезентативные данные – данные о выборке объектов, достаточные, чтобы с необходимой точностью сделать предположение о всей генеральной совокупности объектов.


[Закрыть] [36]36
  UX (англ, user experience) – пользовательский опыт.


[Закрыть]. Применяется дешевый или бесплатный стек технологий, домашняя или грантовая[38]38
  Облачные сервисы очень часто предоставляют гранты стартапам, чтобы они могли проверить свою гипотезу.


[Закрыть] облачная инфраструктура.

4. «Волшебник страны Оз»[39]39
  «Волшебник страны Оз» – метод исследования, когда исследователь имитирует функциональность. Название связано с моментом в одноименной книге, когда герой говорил от имени кукол, изображающих волшебника.


[Закрыть]. Человек имитирует действия системы, например изображая интеллектуального чат-бота.

5. «Педальный привод». Часть функциональности берет на себя человек, например сотрудник службы поддержки.

6. Ограничение аудитории. Сокращая пользовательский сегмент, можно сократить разработку. Например, сначала сделав разработку для пользователей с операционной системой Android, а потом переходить на iOS или web-версию. Также можно ограничить поддерживаемые версии операционных систем или браузеров, что значительно может уменьшить сроки эксперимента.

7. Более дорогое решение. Если идея вашего продукта – удешевление уже существующего сервиса, то можно использовать более дорогой сервис под капотом для тестирования. Например, для тестирования приложения доставки персональной еды можно использовать существующие сервисы доставки и рестораны. Да, Юнит-экономика[40]40
  Юнит-экономика – экономика одной поставки, способ оценки эффективности бизнеса путем оценки прибыльности (суммы доходов и расходов) одной поставки. (Подробнее об этом см. и. 4.3.2.)


[Закрыть] не будет сходиться, но можно сделать выводы о востребованности продукта и готовности пользователей за него платить. С появлением больших лингвистических моделей типа ChatGPT появилась возможность использовать его для решения более простых задач, вроде проверки корректности вводимых данных. Например, указал ли клиент отчество ребенка и совпадает ли оно с именем отца. В случае удачного эксперимента можно начать использовать более дешевые специализированные алгоритмы.

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

Популярный слоган адептов – «Fake it till you make it» («Имитируй, пока не сделаешь»).

Например, прежде чем разработаешь продукт, можно организовать предзаказ или кампанию на Kickstarter и таким образом замерить интерес. Или сделать «Fake door» (фальшивую дверь) – одну или несколько рекламных кампаний, чтобы протестировать, какие свойства будущего продукта или стилистика оформления будут наиболее привлекательны.

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

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

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

Табл. 3.2. Пример записи гипотез и контргипотез пилотного проекта

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

Рис. 3.7. Связь процессов из оперативных контекстов с циклами открытия и поставки

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

Например:

1. Проработка идей того, какие гипотезы стоит проверить, – это запутанный мир, где следует применять Kanban.

2. Проверка гипотезы – хаотичный мир, где лучше всего работает бережливый стартап.

3. Превращение гипотезы в продукт для большого количества пользователей – комплексный мир, где зарекомендовал себя Scrum.

4. Если в процессе появляется ранее воспроизводимая операция, то максимальную эффективность показывает водопад.

Важно отметить, что предложенный каскад процессов – лишь общая практика, и многие процессы могут ситуативно меняться, например:

➠ На этапе стартапа, когда компания строится вокруг одного продукта, может быть рано применять конвейер открытий.

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

➠ Если внутри одной поставки недостаточно очевидно распределение ролей в команде, то не обязательно использовать водопад для планирования и действовать параллельно для достижения результата.