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

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

Модель продукта

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

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

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

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

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

Разработка

Цель стадии и характер работ

Стадия разработки – вторая часть «рана» в цикле выпуска новой версии продукта. Здесь фокус смещается с системного уровня на инструментальный. Это не означает, что поиск решений заканчивается, и начинается чисто механическая работа. Разработка требует не меньше изобретательности от специалистов, чем проектирование, но на другом уровне абстракции. Цель стадии разработки – воплотить решения в реальности.

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

Требования к участникам

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