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

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

Правило предварительной проверки команды

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

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

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

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

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

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

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