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

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

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

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

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

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

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

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

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