Российский продакт-менеджмент построил сильную школу discovery и почти не построил школу delivery. Это самый дорогой пробел в продакт-образовании, и с приходом ИИ он становится только дороже.
Анализ 22 ведущих российских продакт-курсов (Karpov Courses, GoPractice, Skillbox, Яндекс Практикум, программы ВШЭ и других) показал: ни один из них не покрывает все семь ключевых практик доведения проекта до результата. За более чем десять лет менторства продактов я вижу один и тот же паттерн снова и снова — продакт отлично знает, что именно надо делать, но теряет ритм на этапе реализации.
Дальше — восемь признаков того, что ваш проект застрянет, и семь инструментов, которые я применяю в работе. Все они опираются на проверенные источники, но без PMBOK и PRINCE2: тяжёлая методология здесь избыточна.
Что такое delivery, и почему ему не учат
Discovery представляет собой исследовательскую часть работы продакта: это кастдевы, метрики, эксперименты, гипотезы. Этому у нас учат хорошо. Откройте курс любой школы — там точно будут разделы про Jobs-to-be-Done, продуктовые метрики, A/B-тесты, customer development и так далее в этом же духе.
Delivery — это всё, что находится между «знаю, что строить» и «команда сделала, и это работает на проде». Фактически это умение разбить проект на задачи, оценить сроки от бюджета времени, а не от потолка, договориться, кто принимает решения, митигировать риски до того, как они возникли, держать стейкхолдеров в курсе и понять, когда «готово».
Обе части — основа работы продакт-менеджера. С ними бизнес получает три вещи: фичи попадают в реальную потребность клиента, ресурс команды тратится на правильные задачи, инвестиции в продукт окупаются более предсказуемо. Без них — постоянные переделки, выгорание команды и провальные релизы.
В очередной раз разбирая с менти дорожную карту на следующий квартал, я понял, что где-то что-то происходит не то в образовании продактов. Мне стало интересно — в чём проблема? Я из любопытства посмотрел 22 ведущих российских продакт-курса (помимо уже упомянутых — Нетология, ProductStar, МФТИ и другие) на предмет того, что в них есть про delivery.
Ни один из 22 курсов не покрывает все семь ключевых практик: разделение цели и результатов, декомпозиция, pre-mortem, DACI, фиксация границ объёма проекта, критерии готовности, ритм коммуникации со стейкхолдерами. То есть фактически ни один курс обучения продактов не учит быть продактом полностью от «А» до «Я».
Десять из 22 школ продают курс «Менеджер проектов» как отдельную профессию параллельно с программой для продакт-менеджеров. С точки зрения бизнеса это логично: сначала обучаем управлению продуктом, ждём, когда человек начинает буксовать на delivery, и допродаём соответствующий курс. Но это и есть рыночное признание того, что в профиль продакта delivery не включено.
В итоге джуны и мидлы выходят с курсов умеющими исследовать, тестировать гипотезы, проектировать решения (если повезёт), но без системных знаний, как доводить это всё до реального результата.
Ещё пятнадцать лет назад дыра в этих навыках оставалась терпимой. Команды были больше, у продакт-менеджера часто был отдельный проджект, конкуренция была мягче. Если фича делалась шесть недель вместо четырёх, это поглощалось общим темпом роста. Сейчас давление выросло сразу с двух сторон: рынок труда сжимается и перестаёт прощать неэффективное delivery, а ИИ превращает методологию в множитель — к тому, кто владеет системным подходом, добавляется производительность, а к тому, кто не владеет, добавляется только объём беспорядка. Задачи в духе «продумать архитектуру» ИИ-агент превращает в красивую галиматью, и вы тратите на её разбор больше времени, чем сэкономили. Общую динамику внедрения ИИ в бизнес я разбирал в отдельной статье.
Восемь признаков того, что ваш проект начнёт буксовать
У проектной дисциплины восемь болевых точек. Каждая из них — конкретный паттерн, который тяжело лечится постфактум, но легко ловится и правится на старте.
1. Нет цели проекта.
На вопрос «зачем мы это делаем» часто звучит ответ в формате «потому что так решили на встрече» или «маркетинг попросил». Цель есть в голове и в ощущениях, но не зафиксирована в документе.
Последствие: команда и стейкхолдеры трактуют цель по-своему. Объём проекта расползается, и при провале не на что опереться — нечего сравнивать с тем, что получилось.
2. Нет описания результата.
На вопрос «что мы произведём в конце» конкретного ответа нет. Есть только формулировки-процессы: «улучшим онбординг», «оптимизируем уведомления», «обновим главную страницу». Отсутствует список конкретных артефактов, которых не было, но которые должны появиться.
Последствие: непонятно, когда проект готов. Команда что-то сделала, вы или стейкхолдер говорите «не то», и у каждого своя картинка, которая утыкается в бесконечные переделки.
3. Абстрактные задачи.
На вопрос «что конкретно делает исполнитель» ответа нет. Задачи в плане звучат как намерения: «продумать архитектуру», «согласовать дизайн», «учесть пограничные случаи».
Последствие: оценка временных затрат плавает в три-пять раз. «Продумать» — это сколько? Четыре часа? Четыре дня? Никто не знает. Прогресс по таким задачам контролируется слабо, отметить «сделано» нечем.
4. Не учитываются риски.
«Всё будет норм», «зависимостей нет», «мы такое уже 100 раз делали» — знакомо? Если риски не зафиксированы, значит, они не предусмотрены.
Последствие: проект буксует на ровном месте, потому что не учли отпуск ключевого инженера, новый релиз iOS или время на заключение контракта с подрядчиком, который сначала согласился, потом решил внести в договор правки, потом эти правки смотрели ваши юристы, потом юристы подрядчика, потом снова потребовались правки. Часто это не форс-мажоры, а предсказуемые события, о которых просто никто не подумал заранее.
5. Нет ответственных.
На вопрос «кто финально принимает решение X» все пожимают плечами. «Договоримся на встрече», «команда решит» — типичные ответы, не закрывающие сам вопрос.
Последствие: решения откладываются неделями, возникают скрытые конфликты, а к релизу всплывает что-то типа «а мы думали, что это твоя зона».
6. Сроки с потолка.
Это моё любимое. Сколько раз сталкивался с «да недели за две сделаем» или «к концу месяца будет готово». При этом декомпозиции нет, обоснования нет и запасов на непредвиденное тоже нет.
Последствие: к дедлайну успели сделать только часть задуманного и либо сидим все выходные, либо переносим срок и теряем доверие стейкхолдеров. Чаще всего — сразу комбо.
7. Нет коммуникации со стейкхолдерами.
Так вышло, что вы работаете в вакууме, и стейкхолдеры узнают про детали проекта либо на демо, либо в момент релиза.
Последствие: за день до релиза от заказчика звучит «а почему вы не учли наше пожелание», и происходят блокировка, переделка, скандал. Стейкхолдер, узнавший о неподходящих ему деталях только на демо, уже с сильно меньшей вероятностью захочет помочь, зато гораздо вероятнее просто заблокирует релиз.
8. Цель и Результаты смешаны.
Вы считаете, что «провалили проект», если после релиза не сдвинулась целевая метрика. Или «у нас успех», когда метрика сдвинулась, но команда сделала всё кое-как впопыхах, и через два месяца на проде что-то отвалится.
Последствие: команда выгорает на «провалах», которые на самом деле часто вовсе не провалы. Стейкхолдеры спрашивают «что вы делали», а у вас нет внятного ответа. Уроки не извлекаются, и непонятно, виновата реализация или неправильно поставлена цель.
Этот восьмой признак — самый дорогостоящий. С него и начнём.
Цель и Результат проекта разные вещи
Если нет времени читать статью до конца, рекомендую ограничиться этим разделом. Уверен, он уже сильно поможет, если вы увидели в описанной проблеме себя.
Цель проекта — это изменение продуктовой или бизнес-метрики либо поведения пользователя после релиза. Фактически это попытка решить проблему, ради этого проект инициируется и запускается. Например, «конверсия активации выросла с 32% до 50%» или «отток B2B-клиентов сократился на 5 процентных пунктов».
Результаты проекта — это конкретные артефакты, то, что команда произведёт в результате выполнения задач. Например, «спроектирован новый сценарий онбординга», «написан скрипт для телемаркетинга», «обучены операторы поддержки», «проведён A/B-тест 4 недели».
Цель — гипотеза. Результат — конкретный артефакт. Прошу, не путайте — это разные вещи.
Я сам путал их довольно долго, получая граблями болезненные уроки, и разделяю эти категории в работе и менторстве уже много лет. Именно это различие — в продуктовой литературе его называют outcomes против outputs (Джош Сайден, «Outcomes Over Output», 2019) — даёт больше всего противоречий: пока продакт его не принял, остальное не работает. Что ломается, когда цель и результаты смешиваются?
Во-первых, элементарно словить выгорание. Цель вероятностна, как исход раздачи в покере, а не ход в шахматах. Подтвердится она или нет, зависит от рынка, конкурентов, сезона или других продуктовых изменений. Вы не контролируете рынок — вы контролируете результаты, то, что команда производит. Если вы называете «провалом» каждый проект, где не сдвинулась метрика, через два-три таких «провала» вы перестаёте верить в свою работу. И команда тоже.
Во-вторых, вы имеете слабую позицию перед стейкхолдерами. Стейкхолдер спрашивает: «Метрика не двинулась, что вы делали?» Без разделения вы начинаете защищаться. С разделением отвечаете: «Результаты проекта сделаны — вот они. Цель не достигнута — гипотеза не подтвердилась, вот данные. Выводы такие. Делаем дальше то-то». Это разговор. Защита — это монолог.
В-третьих, нет основы для обучения. Если цель не достигнута, но результаты сделаны — это вопрос к гипотезе. Может, мы решали не ту проблему, может, выбранное решение было не тем. Всё это — данные для корректировки в будущем. Если результаты не сделаны — это вопрос к реализации: декомпозиция подкачала, риски не учли, кто-то затащил дополнительные задачи. Это два разных диагноза, и следующие шаги для них тоже разные. Без разделения вы не понимаете, что чинить — гипотезу или реализацию.
В-четвёртых, путаница в коммуникации. Команда работала над результатами. Стейкхолдер измеряет цель. Когда продакт говорит «мы провалили», команда не понимает: это мы что-то плохо сделали или всё-таки гипотеза не подтвердилась.
Главное правило закрытия проекта: проект закрыт, когда сделаны результаты. Это критерии готовности. Цель замеряется отдельно — через две, четыре, восемь недель после релиза, в зависимости от метрики. Возможен исход «все результаты готовы, но цель не достигнута», и это нормально. Это лишь означает, что способ решения проблемы оказался неверным или недостаточным, а значит, в следующий раз можно выбрать более подходящий способ.
Мой ящик из семи инструментов
Сразу оговорюсь: это не «семь шагов в идеальный проект». Это семь конкретных вещей, которые я обычно применяю в проектах от двух недель и больше. Каждый закрывает одну или две из восьми болей. Все вместе они собираются в единый документ — бриф проекта, о котором речь пойдёт ниже.
1. Цель проекта — состояние после релиза, не путь к нему
Закрывает боль: 1 (Нет цели) + 8 (смешение Цели и Результатов).
Цель формулируется как состояние после релиза (логика Working Backwards, Amazon). Не «перестроим онбординг», а «через месяц после релиза 30% новых пользователей доходят до второго ключевого действия; конверсия шага активации вырастет с 34% до 50%».
Я не использую SMART (Доран, 1981) как ритуал, но проверяю по нему, есть ли число, срок и насколько реалистично выглядит цель. Если хотя бы в одну из трёх вещей стыдно поверить, скорее всего цель сформулирована плохо.
Антипример: «перестроить онбординг к концу квартала».
Хороший пример: «к концу квартала после релиза новый B2B-пользователь доходит до второго ключевого действия за 5 минут против 12 сейчас. Конверсия шага активации поднимется с 34% до 50%. Замер через 30 дней после полного раскатывания».
2. Результаты — артефакты, а не намерения
Закрывает боль: 2 (Нет описания результата) + 8 (смешение Цели и Результатов).
Ещё раз акцентирую: результат — то, что команда произведёт. Его можно показать, передать или проверить.
Правило формулирования: глагол совершенного вида («спроектирован», «сделан», «обучены», «измерено»), конкретный артефакт, без «должны», «постараемся», «учтём». Три-семь результатов на средний проект.
Антипримеры: «сделать всё хорошо», «учесть все требования», «улучшить онбординг».
Хороший пример:
Спроектирован новый сценарий онбординга для B2B (Figma-макеты + спецификация)
Реализован новый сценарий регистрации
Обучены операторы поддержки (12 человек, материалы переданы)
Проведён A/B-тест 4 недели, подготовлен отчёт
Обновлена внутренняя и клиентская документация
По каждому пункту можно однозначно сказать «есть/нет».
3. Shaping — описание проекта на одной странице
Закрывает боль: 3 (Абстрактные задачи) + защита от разрастания объёма проекта + частично 6 (Сроки с потолка) через бюджет времени.
Shape Up — подход компании Basecamp к продуктовой разработке (Райан Сингер, «Shape Up», 2019). Из всего метода нам важна одна часть — формирование проекта (shaping): оформить его в одностраничный документ из пяти полей до того, как вы декомпозируете проект на задачи.
Поля следующие:
Проблема — в чём боль клиента или бизнеса, конкретно, с примером.
Бюджет времени (appetite) — сколько времени мы хотим или готовы потратить.
Набросок решения — как решаем на уровне идеи, без деталей реализации.
Кроличьи норы — детали, в которых команда может уйти не туда.
Что НЕ делаем — функциональность или сценарии, которые мы намеренно исключаем.
Здесь два важных нюанса. Первый: бюджет времени — это не оценка. Оценка отвечает на вопрос «сколько времени займёт производство ЭТОГО решения?». Бюджет отвечает на вопрос «сколько времени мы ГОТОВЫ потратить на эту проблему?». Если команда не влезает в бюджет, режется состав задач, а не двигаются сроки. Этот принцип называется «fixed time, variable scope» — фиксированное время, переменный объём.
Второй нюанс: список «что НЕ делаем» — это не список идей, отложенных «на время». Это список того, что кто-то обязательно предложит на третьей неделе, и нам нужно попробовать заранее определиться с ответом «нет».
По моему опыту, метод одностраничного описания имеет смысл применять на проектах от двух недель. На однонедельных он избыточен — там хватит трёх предложений в чате команды. Проекты от двух месяцев без одностраничного описания расползаются за две-три недели до неузнаваемости.
Российский вариант — принцип ФФФ (Fix Time, Fix Budget, Flex Scope) Бюро Горбунова: логика та же, «фиксируем время, гибко двигаем функциональность».
4. Pre-mortem — работа с рисками за 30 минут
Закрывает боль: 4 (Не учитываются риски).
В день старта проекта, до первой задачи, соберите команду на 20-30 минут — четыре-шесть человек: продакт, тех-лид, дизайн, QA, опционально стейкхолдер.
Скажите им что-то вроде: «Представьте, что наступила дата окончания проекта. Мы провалились — не доехали, сделали не то, выкатили фичу с критичными багами. Почему это случилось?»
Каждый молча пишет 5-10 причин на стикерах или в Miro/FigJam. Вы их собираете, группируете, ранжируете по принципу «вероятность × ущерб». Затем по топ-5 пишете план реагирования или явно принимаете риск.
Это лучшая 30-минутная инвестиция в проекте. Приём предложил Гэри Кляйн (HBR, 2007), его отмечал и Даниэль Канеман в «Думай медленно… решай быстро» (2011): pre-mortem удваивает количество выявленных рисков по сравнению с обычным «давайте подумаем о рисках». Не надо только тащить реестр рисков из PMI. Он перестанет быть актуальным через пару дней после создания, а у вас появится дополнительная головная боль в коммуникациях со стейкхолдерами.
5. DACI — четыре роли в принятии решений
Закрывает боль: 5 (Нет ответственных).
DACI пришёл из Intuit, его популяризировал Atlassian. На каждое ключевое решение в проекте выделяется четыре роли:
Driver (ведущий) — проталкивает решение, готовит варианты, организует обсуждение. Обычно это вы.
Approver (утверждающий) — финально принимает. Это всегда один человек: если двое, то решения нет.
Contributors (участники) — дают экспертизу, влияют на решение, но не решают.
Informed (информируемые) — узнают о решении, но не участвуют.
В брифе проекта находится таблица из 5-10 ключевых решений с DACI:
Решение | D (ведущий) | A (утверждающий) | C (участники) | I (информируемые) |
|---|---|---|---|---|
Финальный объём MVP | продакт | руководитель продукта | тех-лид, дизайнер | команда, маркетинг |
Технический стек новой части | тех-лид | CTO | продакт, архитектор | команда |
Дата релиза | продакт | руководитель продукта | тех-лид, маркетинг | вся компания |
DACI применяется не к ежедневным выборам, а к 5-10 крупным точкам, которые меняют курс работы команды.
Мне нравится использовать DACI (а не похожий RACI), потому что он всегда даёт одного утверждающего по ключевым решениями, и это снимает 80% разговоров вида «я думал, что это решает он».
6. Декомпозиция, INVEST и сначала самое рискованное
Закрывает боль: 3 (Абстрактные задачи, на уровне декомпозиции) + 6 (Сроки с потолка).
Декомпозиция — отдельный навык, и ему стоит уделить время. Базовый принцип: сначала планируется бюджет времени, потом делается декомпозиция, и после вы проверяете, влезаете ли в бюджет. Если не влезаете — режете объём работ.
Уровни декомпозиции проводятся от проекта вниз к задачам:
Уровень | Что это | Контрольный вопрос | Сколько |
|---|---|---|---|
Проект | Весь объём работы целиком | «Какую проблему решаем и за какой срок?» | 1 |
Цель | Сквозная цель проекта | «Какая метрика изменится и насколько?» | 1 |
Под-цели | Измеримые куски цели | «На какие части бьётся цель?» | 1-3 |
Результаты | Артефакты, которые произведём | «Что предъявим в конце? Что сможем показать?» | 3-7 |
Этапы | Большие куски проекта во времени | «До какой даты какие результаты готовы?» | 3-8 |
Задачи | Действия команды | «Кто конкретно делает и сколько часов?» | 5-30 на этап |
Если не уверены в уровне, есть простое правило: метрика с числом — это цель, артефакт-существительное — результат, отрезок времени с датой — этап, глагол с исполнителем — задача.
Каждую задачу перед стартом стоит проверить по семи критериям. Это адаптация INVEST (Билл Уэйк, 2003) для проектных задач. Если задача проходит все семь, оценка реалистична и исполнитель не возвращается с уточнениями. Если нет — возможно, перед вами намерение или этап, но не задача.
Проверка | Антипример | Хороший пример |
|---|---|---|
Глагол совершенного вида | «Архитектура БД» | «Спроектировать схему БД для онбординга» |
Один исполнитель/роль | «Согласовать с дизайном и юристами» | Две задачи: «Получить одобрение дизайна», «Получить юридическое заключение» |
Критерии приёмки прописаны | «Сделать страницу» | «Страница свёрстана, прошла дизайн- и код-ревью, работает в Chrome/Safari/Firefox» |
Оценка ≤ 3 рабочих дней | «Сделать backend онбординга» (2 недели) | Разбить на 5-7 задач: «Endpoint POST /workspace», «Логика приглашения», «Валидация»… |
Без «продумать», «учесть» | «Учесть пограничные случаи» | Отдельная задача на каждый случай: «Обработать сценарий: пользователь уже зарегистрирован» |
Привязка к результату проекта | «Заодно отрефакторим X» | Если рефакторинг нужен — записать его в результаты |
Единый уровень с соседними задачами | «Спроектировать БД» (3 дня) рядом с «Поменять цвет кнопки» (15 минут) | Соседние задачи внутри этапа — сравнимого размера |
Декомпозируйте детально только первый этап, остальные — верхнеуровнево, по 1-2 строки на каждый. По мере приближения каждого следующего этапа возвращайтесь и декомпозируйте его. Это называется скользящее планирование (rolling wave planning) — многоуровневое планирование подробно разобрано у Майка Кона («Agile Estimating and Planning», 2005).
И последнее, что часто пропускают: сначала берите в работу самое рискованное. В первую очередь выполняйте задачи с наибольшей неопределённостью — техническое исследование, интеграцию с внешней системой, юридическую проверку, любую задачу с зависимостью от подрядчика. Если такая задача проваливается на первой неделе, ещё есть время скорректировать проект. Если на последней — проект, скорее всего, провалится.
7. Карта стейкхолдеров и ритм коммуникации
Закрывает боль: 7 (Нет коммуникации со стейкхолдерами).
Карта стейкхолдеров — это список людей или групп, на которых проект влияет или которые влияют на проект. Маркетинг, поддержка, финансы, юристы, комплаенс, инфраструктура — вы должны продумать, кто из них и как часто должен быть в курсе.
Ритм следующий:
Команде — короткий статус ежедневно или 2-3 раза в неделю, в зависимости от методологии.
Стейкхолдерам — письменный апдейт раз в неделю: что сделали, что планируем, риски, что нужно от них.
Утверждающему — статус по запросу плюс сигнал, если что-то меняется в объёме, сроках или бюджете.
Если стейкхолдер узнаёт что-то важное только на демо, и ему это не нравится — это ваш провал, а не его.
Письменный еженедельный апдейт — самый недооценённый инструмент. Десять минут раз в неделю снимают 80% риска поздних возражений от стейкхолдеров, а с появлением больших языковых моделей его создание очень просто автоматизировать.
Шесть антипаттернов декомпозиции
Декомпозиция ломается предсказуемо. Далее шесть паттернов, которые я встречаю чаще всего.
1. Большая аморфная задача. Одна задача занимает 1-3 недели, один исполнитель. «Сделать онбординг» (3 недели, фронтенд-инженер). Это не задача, это этап. Что делать: декомпозировать на 5-10 задач по 1-3 дня.
2. Намерение вместо действия. Задача начинается с «продумать», «обсудить», «проработать», «учесть», «оптимизировать». Это не задачи — это направления мысли. Что делать: заменить на конкретное действие с артефактом на выходе или на встречу с критерием выхода — «продумать архитектуру» → «подготовить документ с описанием архитектурного решения: проблема, варианты, выбор и обоснование».
3. Скрытые зависимости. Задача внешне маленькая, но требует чужой работы, которая не названа. «Запустить новые письма» (1 день). Скрытая зависимость: тексты от копирайтера, перевод, юридическое одобрение, согласование с маркетингом. Что делать: каждую зависимость вынести в отдельную задачу с явным владельцем. Главная задача стартует, когда все зависимости сняты.
4. Всё сразу. Попытка декомпозировать весь проект на задачи в первый день — 80 задач в трекере. Поздние задачи всё равно будут переписаны после первого этапа. Что делать: применить правило скользящего планирование — детально только первый этап.
5. Задача без владельца (или с двумя). Задача висит в трекере без исполнителя — «кто-то возьмёт». Или, наоборот, двое владельцев, и каждый думает, что делает другой. Что делать: назначить одного исполнителя либо явного владельца назначения — кто и когда найдёт исполнителя.
6. Микродекомпозиция. Работа раздроблена на задачи по 15-30 минут: вместо «Endpoint POST /workspace» (1 день) появляются «настроить роутинг», «написать валидацию», «добавить тесты», «обновить документацию» — четыре задачи по полчаса. Это микроменеджмент: команда тратит время на закрытие галочек, а вы делаете работу инженера. Что делать: остановить декомпозицию там, где один подходящий исполнитель за один день понимает, что делать, без вопросов к вам.
Бриф проекта, в котором всё сходится
Семь инструментов выше не ведутся в разных документах, таблицах или досках. Это один общий документ — бриф проекта. Вы ведёте его от старта до закрытия.
Бриф содержит двенадцать секций:
Контекст — что происходит, почему сейчас.
Цель проекта — outcome, измеримое изменение после релиза.
Результаты проекта — список артефактов.
Shaping (одностраничное описание) — проблема, бюджет времени, набросок решения, кроличьи норы, что НЕ делаем.
Гипотеза (опционально, если проект-эксперимент) — «Я считаю, что [действие X] приведёт к [изменению Y], что можно измерить через [метрику Z]». Если формула в вашей компании отличается по количеству параметров, ничего страшного. Используйте ту, с которой все согласны.
Альтернативы — что ещё рассматривали и почему не выбрали.
DACI — ключевые решения и кто за ними.
Стейкхолдеры и коммуникация — карта + ритм.
Риски — топ-5 после pre-mortem с планом реагирования.
Декомпозиция и план — результаты → этапы → задачи (детально только первый этап).
Критерии готовности — все результаты сделаны и приняты утверждающим.
Журнал решений и ретроспектива — заполняются по ходу и после.
Время заполнения первой версии — 30-60 минут на средний проект.
В классической школе проектного менеджмента есть похожий артефакт — Project Charter, в русскоязычной традиции «Устав проекта». Бриф и Устав — разные вещи. Устав даёт формальное разрешение проекта от руководства; бриф направляет работу команды. Если в вашей компании уже есть устав, бриф ему не противоречит — они закрывают разные задачи.
Что НЕ нужно из проектного менеджмента
Чтобы не уйти в процесс ради процесса, отрезаем сразу:
Диаграммы Ганта. Полезны для проектов от трёх месяцев. Для фичи — лишний процесс.
WBS (Work Breakdown Structure). Замена — декомпозиция в брифе проекта.
Earned Value Management (метод освоенного объёма). Это про индустриальное проектное управление, не про продукт.
Формальные вехи с подписями. Замена — критерии готовности и контрольные точки с утверждающим.
Реестр рисков на 50 строк. Замена — топ-5 рисков из pre-mortem.
Project Charter, WBS, огромные Gantt-диаграммы для проекта продолжительностью от двух недель до квартала — это процесс ради процесса, чтобы показать, насколько хорошо вы умеете строить Gantt-ы и клепать презентации. Если очень хочется применить какой-то инструмент или ритуал, спросите себя: она экономит время команды или даёт мне ощущение контроля? Если второе — выкидывайте.
С чего начать в понедельник
Если вы впервые решили применить то, с чем только что ознакомились, действуйте по шести шагам:
Сегодня прочитайте эту статью (уже сделано) и шаблон брифа.
Завтра выберите ближайший проект, который только запускается.
Запланируйте в календаре час и заполните шаблон. Пусть не идеально — как получится.
Покажите бриф тех-лиду и одному стейкхолдеру, спросите совета, что можно улучшить. Сделайте их соавторами.
Дополните бриф по результатам обратной связи.
Через неделю посмотрите, что изменилось в работе команды. Зафиксируйте — это будет вашей ретроспективой.
Через 2-3 проекта управление через бриф становится навыком. Продакт перестаёт писать абстрактные задачи, перестаёт обесценивать работу команды на «провалах», начинает разговаривать со стейкхолдерами на одном языке.
Об авторе
Владимир Лунёв — независимый эксперт, автор методологии делегирования задач ИИ и Telegram-канала «Управление здорового человека». Более 15 лет в управлении IT: Ex. Руководитель бизнес-юнита МСБ Kaiten, Ex. Директор по развитию МСБ Bank CenterCredit, ex-СДЭК, ex-Яндекс.
