Не всякая работа должна становиться проектом. Но некоторые инициативы опасно оставлять просто задачей в бэклоге.
Представьте: приходит начальник и говорит: «Мы переделали стратегию. Теперь нам нужно запустить новую систему к 1 декабря».
«Никаких проблем», — говорите вы и заводите новый эпик в бэклог. Но через пару недель выясняется:
- работу делают 5 команд;
- нужно привлечь подрядчика;
- архитектура ещё не согласована;
- есть зависимость от юридического отдела;
- бизнес уже пообещал дату клиенту;
- бюджет ограничен;
- а через три месяца кто-нибудь должен всё это ещё и закрыть.
И возникают вопросики: а может быть, это не просто задача в бэклоге, а самый настоящий проект? А мы вообще можем этим управлять?
В этой статье разберём, почему Agile сам по себе не позволяет управлять крупными и сложными инициативами и почему даже Spotify сталкивается с проблемой управления ими.
Для начала классифицируем объекты управления
Задача
Это когда есть понятный результат, понятный исполнитель и относительно локальный контур работы. Например: «Добавить оплату через СБП».
Epic / большая задача
Работы больше, но управление всё ещё можно осуществлять внутри существующего продуктового потока. Эпик рассыпается на несколько элементов бэклога: задачи, энейблеры (если надо что-то изучить или создать ценность, не видимую для клиента), юзер-стори и так далее.
Инициатива
Есть значимый для бизнеса результат, который требует координации нескольких участников. Вот тут и начинаются проблемы: команды сами по себе без координации не склонны работать над общим результатом, возникают вопросы приоритизации, синхронизации и интеграции общего результата.
Проект
Инициатива становится проектом, когда появляется временная система управления ради конкретного результата. То есть ей невозможно управлять в рамках существующего порядка в организации.
То есть ключевой вопрос:
Не насколько задача большая, а насколько ей нужен отдельный контур управления.
Как понять, с чем мы имеем дело? Проведём экспресс-диагностику
Первый диагностический вопрос: можем ли мы сформулировать конкретный результат инициативы?
«Сделать новую платформу» — это не результат, он не отвечает элементарным критериям SMART. А вот «запустить платформу, которой смогут пользоваться 20 000 сотрудников до конца квартала» — это уже вполне конкретная амбиция.
Любой проект начинается не с перечня задач, а с формулировки изменения, которое должно произойти в бизнесе, процессе или продукте.
То есть:
Проект — это не набор отдельных работ. Проект — это способ получить определённый результат за определённое время и бюджет.
Второй вопрос: есть ли конечная точка?
Это один из самых сильных признаков, ведь у продукта работа может продолжаться бесконечно: гипотеза — действие — результат — знание — новая гипотеза, и так пока не надоест.
В свою очередь, у проекта есть момент, после которого можно сказать: «Мы закончили».
При этом не обязательно должна быть жёсткая дата, но должен быть ожидаемый результат и способ понять, что мы достигли его.
Например:
- внедрить ERP;
- открыть новый завод;
- вывести продукт на новый рынок;
- провести миграцию;
- реализовать регуляторное требование.
Следующий вопрос: есть ли внешняя дата, которую нельзя просто сдвинуть?
Наличие дедлайна не превращает работу в проект автоматически. Вопрос в другом: «Что произойдёт, если мы не успеем?»
Например:
- потеряем контракт;
- не выйдем на рынок;
- сорвём регуляторный срок;
- не проведём мероприятие;
- не сможем запустить производство.
Чем выше цена дедлайна, тем сильнее необходимость отдельного контура управления.
Вопрос кросс-функциональности: пересекает ли работа несколько команд?
Пока работа живёт внутри одной команды, её часто можно оставить в обычном delivery-потоке.
Но как только появляются бэкенд, ИБ, платформа, юристы, маркетинг, Жора и Гога, внезапно главным вопросом становится не «Кто что делает?», а «Как сделать так, чтобы все эти работы сошлись в одну точку?».
Интеграция — ключевой бенефит проектного подхода, и иначе как через проект получить хороший результат, не меняя оргструктуру, практически невозможно.
Продолжим с организацией: есть ли зависимости, которыми нельзя управлять внутри одного бэклога?
Как только инициатива стала кросс-функциональной, работы из SCOPE проекта распределяются по бэклогам многих команд. И, естественно, возникают взаимные зависимости:
- команда А может начать работу только после команды Б;
- команда Б зависит от архитектурного решения;
- архитектурное решение зависит от бизнеса;
- бизнес ждёт оценки команды А.
Получается как в том меме со Спайдерменами: все ждут всех, работа не движется, а из срочных и важных задач команды предпочитают более понятные.
Получается, что проектный менеджмент нужен не для контроля задач. Он нужен для управления системой зависимостей, не требуя изменения постоянной оргструктуры.
Далее надо понять, нужна ли временная организация людей?
Иногда существующей организационной структуры недостаточно. Для инициативы приходится:
- собрать рабочую группу;
- определить роли;
- договориться о правилах взаимодействия;
- выделить ресурсы;
- установить ритм синхронизации;
- определить, кто принимает решения.
То есть возникает временная организация поверх постоянной структуры компании. Это, пожалуй, ключевой признак того, что вам нужен проект.
Далее нужно разобраться с ограничениями: есть ли отдельный бюджет или ограниченный ресурс?
Хорошо, если у вас нет ограничений — что, конечно же, не встречается в живой природе. Обычно компании ограничены в ресурсах, и инициативы в контуре организации за них конкурируют. Менеджмент не спит ночами, думая:
- куда потратить деньги;
- что является обязательным;
- что можно исключить;
- где нужен подрядчик;
- какой объём можно сделать имеющимися командами.
И тогда SCOPE, сроки, ресурсы и стоимость начинают образовывать систему ограничений. А проект позволяет эту систему описать: идентифицировать ограничения, установить взаимосвязи, понять целесообразность и границы ограничений.
Бонусный вопрос: есть ли высокая цена ошибки?
Даже небольшая по объёму работа может оказаться проектом. Для таких инициатив, как, например, «изменить схему расчёта зарплаты для всей компании», стоимость ошибки высока. Представьте, что, не учтя ограничения стейкхолдеров и финансовое положение организации, вы «поразите в правах» какую-то важную группу сотрудников, и, увидев расчёт за месяц, они «сделают выбор ногами». Или, наоборот, убьёте всю прибыль компании выплатой бонусов.
Последствия ошибки настолько велики, что потребуются:
- отдельное планирование;
- согласование;
- тестирование;
- коммуникация;
- управление рисками;
- контроль запуска.
Поэтому размер работы ≠ сложность управления. Проект нужен тогда, когда цена ошибки слишком велика.
Контрольный вопрос: нужен ли отдельный контур управления?
После оценки всех критериев мы готовы ответить на главный вопрос:
Можно ли успешно выполнить эту работу существующим способом — через обычный бэклог, имеющиеся роли, ритмы и процессы?
Если да — скорее всего, проектный контур не нужен. Если нет — стоит задуматься о проекте.
Важно: универсальной аналитической или диагностической модели для оценки целесообразности запуска проекта не существует. В некоторых организациях на уровне локальных нормативных актов критерии отнесения работы к проекту прописываются строго, но в реальной жизни ими зачастую пренебрегают, поскольку реальный мир куда сложнее любой модели.
Когда проект вам точно не нужен
Для таких задач, как:
- запуск A/B-теста;
- небольшая доработка продукта;
- регулярная маркетинговая активность;
- исправление нескольких дефектов;
- исследовательская задача без фиксированного результата;
- обычная работа команды,
проект — это лишняя бюрократия.
Иногда организации склонны упаковывать всё на свете в отдельные проекты, но это скорее следствие дефектов организационной культуры. У менеджмента может быть слепая вера в то, что проект спасает от ошибок. К сожалению, это не так.
Оставайтесь рациональными: искусство менеджмента — это умение правильно делать правильные вещи, подбирая правильные инструменты.
«Что происходит, когда проект маскируется под задачу»
Блиц-бинго:
Симптом № 1: у задачи появляется 30 подзадач.
Симптом № 2: в комментариях Jira начинается управление рисками.
Симптом № 3: PM начинает вручную собирать статусы у семи команд.
Симптом № 4: появляется таблица Excel «для руководства».
Симптом № 5: каждый второй созвон начинается со слов: «Мы ждали команду А, поэтому не делали работу, которую ждёт команда Б».
Если для управления задачей вы уже создали отдельную систему управления — возможно, это давно не задача.
Финальный чек-лист
Проверьте свою инициативу
| Вопрос | Да / Нет |
| Есть конкретный бизнес-результат? | ☐ |
| Есть конечная точка? | ☐ |
| Есть значимая внешняя дата? | ☐ |
| Работа затрагивает несколько команд/функций? | ☐ |
| Есть существенные зависимости? | ☐ |
| Нужны выделенные ресурсы или бюджет? | ☐ |
| Нужны новые правила взаимодействия? | ☐ |
| Высока цена ошибки или срыва? | ☐ |
| Нужны регулярные управленческие решения вне обычного бэклога? | ☐ |
Чем больше ответов «Да», тем вероятнее, что перед вами уже не просто элемент бэклога, а инициатива, которой нужен отдельный проектный контур.
В качестве заключения
Определить, что перед вами — задача, эпик, инициатива или проект, — только первый шаг.
Дальше возникают гораздо более интересные вопросы:
- Как договориться о результате?
- Кто принимает решения?
- Как вовлечь команды, которые вам не подчиняются?
- Как управлять зависимостями?
- Как спрогнозировать срок?
- Как понять, что проект действительно создаёт ценность, а не просто производит очередной набор артефактов?
Именно с этого и начинается современное проектное управление. Ответы на них и пошаговые инструменты успешной реализации сложных инициатив мы разбираем на тренинге Управление проектами для продуктовых команд
ПОДЕЛИТЬСЯ:
