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

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

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

(6) Завершающим шагом является проверка результатов работы проектной команды. Мы должны быть уверены, что достигнуты первоначальные цели, а не просто выполнены поставленные задачи. Инструментом для такой проверки выступает все та же модель продукта, которая служит эталоном для сравнения. Такой подход позволяет понимать статус проекта в понятной для всех участников системе координат. Сравнивая код с моделью продукта и выявляя места расхождения, мы можем говорить о готовности частей продукта и степени их соответствия модели, а не оперировать количеством строчек кода или произвольными процентами готовности, не имеющими отношение к реальности.

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

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

Шкура проджект-раннера на кону проекта

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