Иерархия артефактов и проектные тиски

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

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

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

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

В своей книге я пишу о пяти уровнях проекта, как раз представляющих иерархию артефактов: (1) бизнес, (2) функциональный, (3) интерфейсный, (4) технический и (5) организационный уровни. Первый уровень задает цели создания продукта, второй, третий и четвертый — как собственно должен быть устроен продукт, чтобы достигнуть с его помощью целей бизнеса, а пятый уровень определяет наши ресурсы, которые должны потребоваться для выполнения проекта.

Из этого кстати складывается одна интересная концепция, под названием тиски. Решения об устройстве продукта (2), (3) и (4) зажаты в пространстве между тем, что мы хотим (1) и тем, что мы можем (5). Управление проектом как раз и заключается в том, чтобы зажать этот проектный бутерброд и найти подходящие решения на каждом из его уровней.

Подробнее об этом в 7 и 8 главах книги «Метод параноика»