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

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

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

Тем не менее проверка взаимопонимания контролирует только часть неопределенности. Как быть с тем, что цели проекта не могут быть до конца определены, пока бизнес не проверит цифровой продукт на практике? Одно дело, когда руководитель предполагает, что инструмент поможет компании, и другое – когда сотрудники начнут его использовать.

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

Понимание того, каким должен быть продукт

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

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

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

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

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

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

Выбор специалистов, необходимых для работы над проектом