Время тоже выступает в качестве одного из параметров настройки работы. Каждая стадия должна иметь индивидуальную длительность, чтобы у команды было достаточно времени для поиска решений, но при этом, поиск не должен зайти слишком далеко по ложному пути. Конечно, существуют подходы, когда длительность итераций в проекте устанавливается одинаковой, но на практике такого никогда не происходит. Разные задачи требуют соответствующих условий для их выполнения.
Четких правил для определения критериев оценки контрольных точек не существует – это творческий процесс, как и все в проектах типа «Мозги». В зависимости от выбранной стратегии можно по-разному подходить к набору стадий. В последней части главы я покажу пример структурирования проекта по принципу сериала. Но нужно помнить, что план – это всегда гипотеза, как и все остальное в проекте. За очередной контрольной точкой открывается новый вид на территорию, и проджект-раннеру вместе с проектной командой необходимо все время пересматривать маршрут.
Есть только одно важное условие, которое необходимо соблюдать – не ставить противоречивых или несвязанных между собой целей для каждой из стадий, иначе это собьет команду с толку. Напротив, ясные критерии оценки результатов дают возможность настроить работу единым образом. От стадии к стадии они могут отличаться, но должны быть одинаковыми для всех задач внутри одного этапа проекта. Так получится избежать смешивания разных подходов, ведь от характера работы зависит множество аспектов: способ планирования и оценки, уровень неопределенности, желательная длительность стадии, требования к участникам проектной команды и методы управления.
Из предыдущего абзаца логично следует, что гибкие команды – неотъемлемая часть проектов типа «Мозги». Если на разных стадиях проекта к его участникам предъявляются индивидуальные требования в соответствии с меняющимися задачами, то состав команды должен регулярно обновляться. Применительно к принципу сериала это означает, что участники меняются в зависимости от версии, которая готовится к выпуску. Это похоже на работу над настоящим сериалом, когда для съемок отдельных эпизодов привлекаются разные специалисты и актеры.
Но есть участники, все время участвующие в работе, – исполнители главных ролей, оператор, режиссер и костяк съемочной бригады. То, что в принципе гибких команд называется «несущей конструкцией проекта». В случае работы над цифровым продуктом это прежде всего проджект-раннер и те, кто отвечает за основные части системы. Они поддерживают культуру проекта и являются носителями его изначальных целей.
Будьте внимательны, проджект-раннер – не босс и не менеджер, а такой же участник творческого процесса. Он смотрит на весь проект целиком и настраивает работу остальных участников, но не «командует» ими, а направляет и создает условия, при которых они могут проявить свои лучшие качества. Его сила в том, что он ясно представляет образ конечного продукта и помогает его увидеть остальным участникам.
В гибких проектных командах нет выделенных менеджеров. Управление, в отличие от администрирования, составная часть технологического процесса: важно, в каком порядке выполняются задачи и как их результаты стыкуются. Менять план действий в зависимости от реального состояния дел с учетом технологических зависимостей невозможно без глубокого понимания устройства продукта и технологии его создания.
Это означает, что специалисты в исследовательских и креативных командах не могут быть «подчиненными» по отношению к менеджерам, они сами принимают решения, каждый на своем уровне абстракции, компетенции и ответственности. Управление предполагает наличие компетенций, что обязывает условных менеджеров быть самим специалистами.
По этой же причине в гибких командах нет обычных для проектов UX-дизайнеров, IT-архитекторов, тестировщиков, программистов и аналитиков. Фактически это список компетенций, а не ролей, но в современной проектной работе между ними принято ставить знак равенства. В продюсерском подходе набор ролей в проектной команде не определен заранее, как это происходит в классических методиках, и что более интересно – сами роли не связаны с какой-то одной профессиональной специализацией.
Вместо функциональных ролей в «Методе параноика» структуру гибкой проектной команды составляют ключевые участники. Их состав зависит от проекта, а компетенции и зона ответственности каждого связаны с моделью создаваемого продукта. Получается, проджект-раннер и остальные ключевые участники по определению должны быть мультидисциплинарными специалистами. По мере погружения на более детальный уровень специалисты должны становиться все более специализированными в отдельных компетенциях.