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