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

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

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

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

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

Первое правило: каждое решение должно уменьшать неопределенность

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

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

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