Кейсы
Реальные кейсы, анонимизированные согласно NDA. Каждый кейс показывает контекст, в который я заходил, проблему, что я менял, что становилось видимо клиенту, и бизнес-эффект.
Стабилизация проблемного проекта
Delivery-перезапуск для стабилизации проекта мобильной разработки.
Контекст
Команда из 14 человек — PM, BA, дизайнер, DevOps, 2 QA, 4 mobile- и 4 backend-разработчика — строила потребительское мобильное приложение 4–5 месяцев. Клиент — стратегический стейкхолдер с личной заинтересованностью в продукте и текущими отношениями по другим проектам компании.
Проблема
Команда работала 2-недельными спринтами против раннего delivery-плана, зафиксированного до того, как реальная сложность продукта проявилась. Цели спринтов стали нереальными, работа переходила из спринта в спринт, давление наверстать давало некачественные поставки, проблемы с качеством и падение морали. Клиент видел, как проект уходит из-под контроля. Доверие — и будущая работа — были под риском к моменту, когда я зашёл как Delivery Manager.
Что я менял
После внутреннего аудита провёл с клиентом открытый разговор о том, почему первоначальный план больше не отражает реальность. Перешли с 2-недельных спринтов на Kanban, чтобы убрать искусственное давление дедлайнов, обновили базовые планы проекта под новую техническую сложность, коучил PM по статус отчетам и коммуникации с клиентом и лично оставался в governance до стабилизации delivery. Kanban и обновление планов работали вместе — ни одно по отдельности не было бы достаточным.
Что стало видимо
Более ясные статус-отчеты впервые дали клиенту реальную видимость прогресса, рисков и следующих шагов. Ощущение «уходит из-под контроля» ушло, потому что клиент видел, где проект реально находится неделя за неделей и что мы с этим делаем.
Бизнес-эффект
~60% меньше новых багов от спринта к спринту. Релизы — с раз в 4 недели до примерно раз в 10 дней. Переход стабилизировался за 2–3 недели. Проект доставлен с хорошим качеством к удовлетворению клиента — позже изначального плана, но стратегические отношения сохранены и работа с клиентом продолжилась дальше.
Видимость портфеля
От разрозненной отчётности PM к контролю портфеля на данных.
Контекст
Компания пор разработке на 300 человек, около 25 активных проектов на 15 PM. Каждый проект жил по своему процессу — разные форматы отчётности, несогласованные цвета здоровья проекта, нет общей библиотеки метрик, нет матрицы навыков PM, минимальный набор шаблонов проектной документации.
Проблема
У руководства был поверхностный взгляд на состояние портфеля. Прибыльность видна, но статус нельзя сравнить от проекта к проекту. Риски всплывали поздно, эскалации клиентов слишком часто были сюрпризом, оценка PM субъективная. На 25 проектах и 15 PM портфельный контроль не мог опираться каждый раз на ручной детальный опрос или ревью в случае проблем.
Что я менял
Как Delivery Manager уровня портфеля построил единую delivery-операционную модель: SDLC компании, стандартные правила Jira-проектов, RACI-матрицу, регулярные аудиты проектов, общие шаблоны проектных документов (charter, статус-репорт, риск-матрица, структура Confluence), библиотеку метрик, матрицу навыков PM и портфельный дашборд с RAG-репортингом на данных по бюджету, объему работ, срокам, команде, клиенту и прибыльности.
Что стало видимо
Впервые руководство могло сравнивать состояние delivery по портфелю на одних и тех же показателях. RAG-статус должен был подкрепляться доказательной базой данных метрик на проекте, а не просто мнением. Изменение настроения клиентов и маржи всплывали раньше. Слабые места в навыках PM появлялись в матрице навыков, а не в результате эскалаций клиентов.
Бизнес-эффект
Время на сбор и проверку статуса портфеля проектов снизилось с 10–12 часов до 1–2 часов. Эскалации клиентов — с 1–2 в месяц до примерно 1 в 3–4 месяца. Первые видимые результаты в 1-м месяце; большая часть операционной модели — к концу 3-го месяца.
Передача из пресейл в производство
От передачи документов к передаче delivery-контекста.
Контекст
Компания заказной разработки с системным разрывом между пресейл и delivery. Как Head of Presales я отвечал за то, как новые проекты переходят из коммерческих обсуждений в производство. Стандартный пакет информации передавал финальные документы, но часто не передавал обсуждения, договорённости и клиентский контекст, которые стояли за сделкой.
Проблема
Терялся контекст, не документы. Команды delivery задавали клиентам те же вопросы повторно, оспаривали предварительные оценки после старта проекта, потому что не знали, как цифры собирались, упирались в споры по объему работ из-за ожиданий, которые не были чётко переданы, начинали с неправильных приоритетов и пропускали договоренности и данные на этапе продаж. Трение между пресейл, производством и клиентом начиналось с первого дня.
Что я менял
Пересобрал процесс передачи на уровне компании. Определил обязательный пакет передачи (записи звонков, пресейл-таймлайн, контекст клиента, договорённости, допущения оценок, приоритеты, стейкхолдеры, начальные риски, технические обоснования), добавил чеклист для проверки полноты пакета, ввёл внутренний формальный старт с участием пресейл и производства до старта с клиентом, ввел требование проводить ранний анализ стейкхолдеров и идентификацию рисков, ревью допущений и технических решений вместе и подключал ПМ ближе к концу пресейл — до подписания контрактов. Первая версия — за 2–3 недели; полный rollout — за 1–2 месяца.
Что стало видимо
Риски, допущения, ожидания стейкхолдеров и скрытые обещания стали видимы до старта delivery, а не после. Продакшн-команды видели, как собирались оценки и какие приоритеты клиента должны определять старт проекта. Внутренний кикофф вскрывал дыры, пока ещё было время их закрыть.
Бизнес-эффект
Более гладкие старты новых проектов. Меньше повторных вопросов клиентам. Меньше споров по оценкам и объему работ. Меньше переделок на старте, потому что производство перестало восстанавливать контекст, который клиент уже передавал. Трение и обвинения между пресейл и производством снизились. NPS клиентов вырос.
Достаточно увидели? Начните с диагностики.
Запишитесь на 20-30 минутный звонок. Посмотрим ваш delivery-сетап и совпадает ли ваш случай с тем, что вы прочитали.