«Самая опасная ошибка – пытаться управлять сложными проектами по одной схеме». Почему даже сильные команды терпят неудачу

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

— Денис, принято считать, что успех проекта зависит от того, насколько подробно его удалось спланировать в самом начале. Вы с этим не согласны. Почему?

— Потому что любой крупный проект начинается совсем не так, как выглядит на итоговой презентации. Обычно сначала это хаос. Люди еще не понимают, какой должна быть конечная цель, существуют разные точки зрения, много неизвестных. И если в этот момент пытаться строить детальные планы на полгода вперед, они устареют быстрее, чем будут согласованы.

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

— Вы говорите, что любой крупный проект начинается с хаоса. Что это означает на практике?

— Хороший пример – проект по созданию единого центра коммуникации на крупнейшей платформе для размещения вакансий и поиска работы, которым я руковожу. Для компании это была не новая функция, а изменение модели взаимодействия работодателей и соискателей, которая существовала четверть века. Раньше вся логика строилась вокруг отклика на вакансию. Но рынок менялся, появлялись новые способы общения, и возник вопрос: можно ли объединить отклики, чаты, звонки и видеозвонки в одну систему?

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

— Как в такой ситуации руководителю проекта удержать команду?

— Многие думают, что руководитель должен сразу прийти с готовыми ответами. На самом деле чаще всего его задача противоположная – организовать правильные вопросы. Я специально создаю пространство, где участники могут открыто спорить. Важно не сгладить разногласия, а сделать их видимыми. Когда все аргументы оказываются на столе, обычно удается сократить десятки вариантов до двух-трех реалистичных сценариев. Уже после этого руководители продукта принимают решение, а команда получает общую точку опоры. Если этот этап пропустить, дальше люди начинают двигаться в разные стороны. Каждый уверен, что делает правильную работу, но общего проекта уже не существует.

— Когда заканчивается этот этап неопределенности?

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

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

— Получается, именно здесь начинают работать гибкие подходы к управлению?

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

— А когда можно снова переходить к классическому проектному управлению?

— Когда эксперимент подтвердил жизнеспособность идеи. В нашем проекте пилот показал, что даже базовыми возможностями новой системы начали пользоваться около 20% работодателей платформы. Для нас это стало главным сигналом: рынок готов. И вот здесь характер проекта меняется полностью. Теперь уже не нужно искать направление. Нужно масштабировать решение. Появляется возможность планировать кварталами, распределять ответственность между несколькими командами, системно управлять рисками и зависимостями. То есть методы управления снова становятся более классическими, но уже потому, что изменилась сама задача.

— Получается, одна и та же команда за время проекта работает сразу в нескольких режимах?

— Да, и в этом, на мой взгляд, заключается следующий этап развития проектного управления. Еще несколько лет назад компании спорили, что лучше – классический подход или гибкие методологии. Сегодня этот спор постепенно теряет смысл. На практике почти любой крупный проект использует оба подхода. Вопрос только в том, способен ли руководитель вовремя почувствовать, что проект перешел в новую фазу.

— Насколько сложно вовремя заметить этот переход?

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

— Можно сказать, что сегодня руководитель проекта управляет уже не столько задачами, сколько изменениями?

— Думаю, именно к этому все и идет. Современные проекты становятся слишком сложными, чтобы их можно было провести по заранее написанному сценарию. Поэтому руководитель проекта все меньше занимается контролем отдельных задач и все больше – тем, чтобы команда сохраняла общее понимание цели, быстро адаптировалась к изменениям и вовремя перестраивала способ работы. Именно это сегодня отличает управление проектами от простого контроля исполнения.

— Какой главный вывод вы сделали за годы работы с подобными проектами?

— Проект не остается одинаковым от первого дня до последнего. Сначала это поиск направления. Потом серия быстрых экспериментов, а затем – масштабирование уже проверенного решения. На каждом этапе нужны разные инструменты управления, разная скорость принятия решений и даже разная роль руководителя проекта. Когда начинаешь воспринимать проект как постоянно меняющуюся систему, становится проще работать с действительно сложными задачами. И именно это, как мне кажется, сегодня становится одним из главных навыков современного руководителя проектов.

Василий Черный