Что мешает реализовать крутые проекты

Кейсы из практики

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

Project 1 — съедал арт‑директоров, которые не выдерживали нагрузки и требований по проекту. За полгода сменилось 4 человека. Были горе‑разработчики, которые не могли внятно объяснить, что они сделали. Ненадёжный СТО отвалился на пятом месяце работы (из 12). Команда не выдерживала темпа, и из‑за этого сдвигался весь глобальный план. Пришлось навалится командой топ менеджеров и встать у руля проекта, в результате чего проект был реализован срок.

Project 2 — не вовлечённые проектные менеджеры. Был очень сложный проект с множеством багов на проекте, сложной архитектурой и особенностями и сложностями продукта. Проект начал работать только после прихода четвёртого ПМа. Были некомпетентные разработчики, которые срывали релизы. Всё удалось настроить, но ушло на это почти 5 месяцев и смена менеджера проекта.

Project 3 — за год сменилось три тимлида разработки, из‑за чего постоянно происходил новый найм, онбординг и замедление команды.

Project 4 — в начале проекта не были уточнены требования. На пресейле проект продали красиво, предложили больше тз, а делать начали «на коленке». В итоге вместо двух месяцев разработка заняла восемь, но всё‑таки проект дотянули и сдали. Помогло то, что вся работа шла через эскроу счета и команда обязана была доделать проект, чтобы получить вознаграждение за работу.

Project 5 — Для достижения первого релиза игры потребовалось сменить главного ПМ, и через 6 месяцев перед вторым релизом ПМ резко выходит из проекта по личным обстоятельствам (трагическое дтп), у команды падает уровень деливери, все это происходит за месяц до релиза, в итоге маркетинг не сходится и проект не собирает нужные метрики и закрывается.

Если обобщить, то на пути реализации проектов так же часто встречаются следующие препятствия:

• Частая смена ключевых сотрудников

• Недостаточная вовлеченность менеджеров

• Некомпетентность отдельных членов команды

• Неточности в начальных требованиях

• Срыв сроков и превышение бюджета

Есть много прикольных мемов и картинок на эту тему, вот одна из них:

Решение проблем на проектах

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

Почему система управления в проекте — это не просто «доска задач»

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

Именно поэтому я всегда подхожу к планированию и системе управления особенно тщательно. Могу привести конкретный кейс: в одном проекте мы проводили тендер на разработку мобильного приложения с бюджетом 15 миллионов рублей. Из 10 команд в шортлист вышли две, и мы выбрали именно ту, у которой проектный менеджмент был выстроен на 100%. Был удобный план проекту в Ганте, прописан ресурсный план, понятная система отслеживание прогресса, высокая техническая экспертиза.

Что это означало:

• Чётко расписанный роадмэп.

• Разбиение задач по уровням сложности.

• Диаграмма Ганта с учётом рисков.

• И самое главное — удобная, прозрачная система отслеживания прогресса по проекту.

Результат: за 12 месяцев совместной работы мы отклонились от плана всего на две недели, и то — в середине проекта. Финальная сдача была в срок. Именно тогда я окончательно убедился: аутсорс‑команда с сильным проектным менеджментом — это не дополнительная статья расходов, а ключевой фактор успеха проекта.

Пример ганта подобного проекта:

Основные параметры успешного ИТ проекта и проектного офиса, о которых нужно думать заранее и готовить решения перед запуском проекта

Прозрачный и наглядный прогресс по проекту для всех участников команды — решается через систему построения дашбордов для команды, где прозрачно выполняются эпики и виден прогресс. Задачи синхронизированы по листам отделов, фиксируются и оперативно устраняются возникающие блокеры, которые есть всегда. Поэтому ресурсы в разработку нужно закладывать с запасом в 20–30%. Если вы делаете продукт через аутсорс — это всегда x2+ по цене, и в эту цену входит в том числе наличие экспертизы у исполнителя.

Системность работы с фреймворком и ритмичность действий команды на проекте — план ежемесячного фреймворка должен выполняться.

Необходимо достаточное вовлечение стейкхолдеров и продюсеров на проекте (минимум раз в месяц — общение с проджектом и продактом с детальным разбором текущего состояния).

Ритм команды: кранч → отдых → восстановление → снова кранч → релиз на тестовый контур → хотфиксы и багфиксы → шлифовка → релиз в паблик.

Время готовности проекта у команды и для стейкхолдеров может значительно отличаться из‑за подготовки демо, тестирования, багфиксов и самого процесса релиза. Поэтому нужно учитывать все временные затраты. Перед запуском проекта следует проиграть весь роадмап с командой и проверить его на соответствие SMART‑критериям.

В крупных проектах нужно отслеживать сразу несколько метрик:

• соответствие реализации роадмапу,

• бюджет,

• взгляд на проект управленцев или лидирующих людей на проекте

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

Наличие для проектного офиса Specops (или мы еще назвали такую команду emergency dev team), которая подключается по сигналу от проектного менеджера оп запросу где присутствуют сложности и усиливает основную команду, беря на себя решение задач, сдвигающих роадмап. Она помогает вернуть необходимую скорость разработки, чтобы проект не растянулся (на месяцы или годы?)).

Что делает проект по-настоящему управляемым?

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

• настроенные пайплайны по проектам,

• ленты статусов и фильтры по листам (вдохновляйтесь, как сделано в ClickUp),

• единые дашборды,

• понятные зоны ответственности — за каждый дашборд отвечает конкретный проджект или тимлид и несет ответственность за результат.

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

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

Данная статья является второй частью статьи о проектного менеджменте, а первую часть можно прочитать здесь

Обратная связь

Если у вас есть идеи, наблюдения или личные инсайты, которыми вы хотели бы обменяться в сфере проектного управления — буду рад диалогу. А если вы работаете над проектом, которому требуется экспертиза, структурирование процессов и системный подход — пишите!

Вы можете связаться со мной через Telegram @romwag,

почту romarioromeo@yandex.ru

или LinkedIn — буду рад познакомится, обменяться опытом и обсудить, чем могу быть полезен.