Корпоративный мир ушёл далеко вперёд. Если 10 лет назад сотрудники выходили на работу, чтобы создавать продукты «с нуля», то сегодня конъюнктура изменилась. IT-ландшафт крупных компаний перенасыщен решениями на любой вкус. На смену классическому проектному управлению, ориентированному на создание чего-то нового, пришло управление продуктами, где гибкие методологии работают на развитие и стабилизацию уже существующих систем.
Но любой продукт когда-то был просто идеей. Поэтому давайте договоримся о терминах: в этой статье проект — это нулевая ступень, фундамент, с которого начинается жизненный путь любого продукта. Я приведу пример из личной практики.
Меня зовут Ярослав, и четыре года назад я в роли руководителя проектов присоединился к команде MAGNIT OMNI – бизнес-группе ритейлера «Магнит», отвечающей за создание единого омниканального опыта для клиентов. Перед нашей группой из 20 человек стояла амбициозная задача: создать MVP интернет-магазина «Магнит Косметик» и занять нишу наравне с такими серьёзными игроками, как «Подружка» и «Золотое яблоко».
Это был классический проект с понятной целью, жёсткими сроками и ограниченным ресурсом.
В ходе реализации проекта размер команды быстро вырос с 20 до 100+ человек. Нам поэтапно открывали финансирование по факту достижения конкретных результатов. Продукт проекта постепенно развивался, словно цветок в горшке, за которым системно ухаживают. А если сравнивать со строительством — это было похоже на небоскрёб, который возвели у нас на глазах: приложения для Apple Store и Google Play, веб-сайт, 19 модулей в бэкенде.
В итоге мы реализовали проект, результатом которого стал маркетплейс, предлагавший своим клиентам более 7,5 тыс. SKU.
Классная история, правда? Но, не все подобного рода проекты успешны. Немало проектов закрываются на середине своего пути.
За мои 10+ лет в управлении проектами я так и не нашёл паттерн, объединяющий успешные проекты по их параметрам. Все проекты разные: масштабы, цели, среды, команды, ресурсы, качество, стейкхолдеры. Но почему одни проекты успешны, а другие сходят с дистанции? Неужели нет универсальных принципов, опираясь на которые можно с высокой долей вероятности предсказать судьбу инициативы?
Мне кажется, такие столпы существуют. Вот пять из них, на которые я обращаю внимание.
Дисклеймер: к сожалению, универсальный рецепт успеха не содержится ни в одном учебнике. Я вывел эти принципы методом проб и ошибок, управляя проектами в условиях жёстких ограничений и нехватки ресурсов. Поэтому все пункты в этой статье — выжимка из моего реального опыта, а не просто красивая теория.
1. Куратор
Понимание роли куратора — это база. Многие «старички» проектного управления до сих пор считают эту роль избыточной. Если вы тоже так думаете — пора обновить свои знания.
Куратор проекта — это руководитель высшего звена, который обеспечивает необходимые условия и поддержку для реализации проекта. Он представляет интересы заказчика и обладает полномочиями утверждать ключевые изменения. Именно куратор — главное лицо, по-настоящему заинтересованное в результате.
Заказчики — это те, кто будет использовать результат. Они могут сопротивляться изменениям, ведь в прошлом им жилось неплохо.
Инвестор не всегда на��одится в контуре компании. Его задача — получить прибыль, а не вникать в детали реализации.
Руководитель проекта (РП) — это управленец, который балансирует между интересами всех сторон.
Если коротко: у заказчика — потребность, у инвестора — деньги, у РП — ответственность. Но только у куратора есть и власть, и мотивация довести дело до конца.
Куратор находится внутри компании, он ставит цель и глубоко убеждён, что результат нужен бизнесу. Это главный начальник инициативы. Именно к нему приходит РП, когда нужно разблокировать задачу, тормозящую проект.
Если куратор не назначен или не идентифицирован, считайте, что у проекта нет реального «хозяина» в высшем руководстве.
2. Сроки
Часто на этапе предпроектного анализа можно услышать: «Эту работу сейчас невозможно оценить, давайте планировать по ходу пьесы». Это ошибка.
Приведу пример, который я почерпнул у Павла Алтуфьева в книге «Проектное управление». История строительства Саграда Фамилия в Барселоне идеально иллюстрирует этот тезис.
Хронология: Строительство началось в 1882 году при императоре Александре III, а завершение планируется аж на 2026 год (или позже) — к столетию смерти Гауди. Стройка пережила войны, революции и смену эпох.
Почему так долго? Дело не только в отсутствии денег. Главная причина — сложность замысла и отсутствие жёстких коммерческих сроков. Гауди проектировал собор как «служение», понимая, что результат увидят другие.
Это архитектурный феномен, но для бизнеса он губителен. Отсутствие временных рамок размывает фокус. Если результат не нужен к конкретной дате, он, скорее всего, не нужен никому. Жёсткий дедлайн — это не тирания, а способ концентрации ресурсов и подтверждения ценности инициативы.
3. Discovery
Любой проект предполагает творческий подход на старте и системный — на фазе реализации. Вернёмся к моему примеру с MVP «Магнит Косметик».
Итак, проектная команда получила вводные. Что дальше? Составлять план-график рано — ещё неясны все работы. Формировать иерархическую структуру работ (ИСР) тоже рано. Здесь наступает этап Discovery.
Задача РП на этом этапе — собрать максимум данных о будущем результате. В каждом проекте Discovery уникален, но их объединяет наличие итогового артефакта — Discovery Report, или отчёта об исследовании.
В нашем случае отчёт включал:
Основной флоу производства и реализации товара.
Законодательные нормы (маркировка «Честный знак», «Меркурий»).
Целевую архитектуру системы.
Матрицу ответственности (RACI) для ключевых бизнес-процессов.
Выявленные ограничения и риски.
Многие при слове «документирование» лезут на стену, путая бюрократию с бюрократизмом. Но чем больше структурированной информации мы собираем в начале, тем прогнозируемее результат. Устав проекта, или паспорт, я советую оставлять неизменным — это своего рода «конституция». А Discovery Report — это «рабочая конституция», которую мы расшариваем на команду. При отклонении от курса мы указываем на рамки, зафиксированные в этом документе.
Важно: Discovery Report можно и нужно редактировать, но только если изменения действительно качественно влияют на результат (например, добавились неучтённые требования информационной безопасности).
4. Командная культура
В разных компаниях мне приходилось сталкиваться с разной корпоративной культурой. Отлично, если она есть и развита. Но если вам повезло меньше, must-have — создать свою культуру внутри проектной команды.
Важно, чтобы группа умела двигаться синхронно и прозрачно. Для этого нужно держать фокус на брутальной честности, открытости и психологической безопасности, когда люди не боятся говорить о проблемах.
Начните с себя как с руководителя. Вам помогут регулярные митинги, встречи 1-на-1 и открытая документация. Вы не измените кардинально личности участников за время проекта, но вы способны регулировать их взаимодействие. Чем справедливее вы относитесь к команде, тем благосклоннее её участники будут друг к другу и к внешним контрагентам.
Пример из практики: На одном из проектов моя команда очень эмоционально общалась с подрядчиком, от которого зависело развитие наших сервисов. Результат — срывы сроков и демотивация. Я начал демонстрировать максимально лояльное и уважительное отношение к своей же внутренней команде. Эффект оказался заразительным: они перенесли эту культуру справедливой взаимности на подрядчика. В итоге мы добились глубокой вовлечённости внешней команды и наладили процесс.
5. Метрики: проект, продукт, сервисы
Ближе к завершению проекта команда часто живёт в состоянии «ну когда же результат?». Если этот вопрос звучит с интонацией усталости и опустошения, а не здорового азарта — это плохой сигнал. Он говорит о том, что команда выг��рела, не понимает где находится и для чего она работает. Как и в любом деле, в проекте важно видеть результат в динамике, следить за тем что получается, получать мотивацию и корректировать, если что-то идет не по плану.
Поэтому старайтесь использовать расширенный набор метрик в контуре управления проектом.
Проектные метрики. Эти метрики позволят контролировать ход реализации проекта (например, Burn-down и Burn-up charts).
Продуктовые метрики. Если вы запускаете продукт, они вдохновляют команду. Рост Retention, DAU, WAU, MAU, NPS — это сигнал: «Мы на верном пути, наш труд приносит пользу людям».
Как мы говорили выше, проект — это нулевая ступень, фундамент, с которого начинается жизненный путь любого продукта. Поэтому справедливо будет сказать, что задача руководителя проекта — оставить после себя не просто работающий, а стабильный продукт с минимальным техническим долгом. Для этого используйте технические метрики.
Технические метрики. Никто не обрадуется, если итоговый сервис будет работать с лагами. Отток пользователей из-за плохого опыта может убить продукт, даже если он закрывает все функциональные потребности. Используйте то, что поможет вам отслеживать качество систем. Например, кол-во запросов в секунду (RPS), время ответа сервиса (RT) и количество ошибок (ER).
Вот пример элемента продуктовой борды, которую команда проекта наблюдала на еженедельном stand up. Если показатели были критичными, то тут же они разлетались по профильным чатам и начиналась проверка — есть ли у нас инцидент.
По этому элементу было понятно, когда стоит обратить внимание на здоровье сервисов.
Итог и напутствие
Проектное управление за всю свою историю обогатилось множеством стандартов и фреймворков. Одни развиваются, другие остаются в базовом виде.
Я же желаю каждому, кто начинает работу над новым проектом, получить удовольствие. Будьте технократами и оставайтесь открытыми новым знаниям. В эпоху перемен примите простую истину: эффективный руководитель проекта — это своего рода локальный CEO, CTO, CIO и CPO «в одном лице».
Если хотите быть успешным и запускать успешные продукты, мыслите так: «Моя команда создаёт продукт с пользой для конечного заказчика, удовлетворяя требования куратора и принося прибыль инвестору». Это даёт вдохновение на весь производственный цикл.
А для карьерного трека держите в голове: «Возможно, результат этого проекта — то, что мне предстоит развивать или сопровождать в будущем. Поэтому его качество должно быть настолько высоким, чтобы мне самому было с ним комфортно работать».
Спасибо, что дочитали до конца! Надеюсь, этот опыт будет вам полезен.
А как вы считаете, какой из этих пяти столпов самый важный? С чего начинаете проверку проекта вы? Делитесь опытом в комментариях!
