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

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

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

<p>Модель продукта</p>

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

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

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

<p>Глава 10</p><p>Принцип вовлеченности бизнеса</p>

Структура главы:

• Ответственность бизнеса

• Действующий бизнес

• Стартапы

• Customer Development и архитектура бизнеса

<p>Ответственность бизнеса</p>

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

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

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