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

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

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

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

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

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

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

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

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

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

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