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

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

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

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

Способ оценки и планирования

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

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

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

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

Критерий прохождения контрольной точки

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