Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

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

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

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

Оценка проектов типа «Мозги»

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

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

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