Кейс: как я зашёл в 5 «мёртвых» T&M-проектов, которые никто не хотел вести, и превратил их в портфель на 1,5 года с ростом выручки в 5–6 раз

Оглавление

1. Ситуация: 5 проектов, от которых все отказались

2. Технологический контекст

3. Что я увидел внутри: боль трёх сторон

4. Что я сделал за первые 2 недели

5. Артефакт №1: Регламент взаимодействия

6. Артефакт №2: Детализация отчётности (как было → как стало)

7. Ключевые правила, которых не было в договоре

8. Результат: цифры, команда, перспектива

9. Главный инсайт

1. Ситуация: 5 проектов, от которых все отказались

У крупного интегратора было 5 проектов внедрения портальных решений и СЭД. Крупные фикс-прайс-контракты на внедрение успешно закрылись. Дальше — стандартный переход на сопровождение и развитие по T&M (Time & Materials).

И тут всё посыпалось.

Продакты и аккаунт-менеджеры получили свои бонусы за внедрение. На маленькие ежемесячные лимиты (до 40 часов в месяц на проект) им стало плевать: «мало денег, много суеты, заказчики не согласовывают часы».

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

Заказчики ждали месяцами. Ресурсы выбить было невозможно. Когда доработки наконец приходили — это было не то, что они хотели. В отчётах о затратах значилось «разработка — 20 часов» без детализации. Заказчики всерьёз рассматривали замену платформы.

Риторический вопрос: кому нужен этот портфель? Никому. Продакты хотели его закрыть, команда — забыть, заказчики — убежать.

Мне сказали: «Ну, попробуй там что-нибудь сделать, но чуда не жди».

2. Технологический контекст

Проекты были построены на следующем стеке:

• Портальные решения / СЭД: SharePoint, заказная разработка

• Аналитика и хранилища данных: Power BI, MySQL

• WMS / складская логистика: заказная разработка на .NET

• Инфраструктура: виртуализация VMware, CI/CD (Azure DevOps / Jenkins), IIS, Windows Server, Active Directory

• Бэкенд: .NET Framework, C#, ASP.NET, MS SQL Server

• Фронтенд: JavaScript, React (в части проектов)

• Управление задачами: Jira (настроенный workflow), Confluence, SharePoint для внутреннего документооборота

• Мониторинг и логирование: Zabbix, ELK-стек

Это не «гаражная разработка», а enterprise-решения для крупных заказчиков с разветвлённой инфраструктурой.

3. Что я увидел внутри: боль трёх сторон

Первым делом я просто пошёл и поговорил со всеми. Честно. Вот что выяснилось.

Со стороны интегратора (продакты/аккаунты)

• Не видят ценности в T&M-сопровождении — привыкли к крупным фикс-прайс-контрактам

• Трудности с согласованием часов: заказчики не подписывают отчёты

• Итог: тратили 2–3 часа в месяц на проект, сводя коммуникацию к минимуму

Со стороны команды

• Загрузка упала, основная занятость ушла на другие проекты

• Сюда привлекали нестабильно, как на факультатив

• Потеря фокуса, экспертизы, мотивации

• Непонятные запросы: делали → переделывали → непонятно, кому это нужно

• Обиднее всего: команда видела реально ценные для бизнеса кейсы, но их никто не слушал

Со стороны заказчика

• Долго ждут реализации (ресурсы выбить невозможно)

• Нет обратной связи

• Получают «не то» (мимо ожиданий)

• Отчёты о затратах — чёрный ящик: непонятно, за что часы

Ключевая проблема системного уровня: никто не видел перспективы. Каждый участник думал, что проект «никакой», хотя по факту он был востребован. Просто все делали вид, что работа идёт.

4. Что я сделал за первые 2 недели

Никакой магии. Три системных действия.

4.1. Вместе с командой нарисовал AS IS

По каждому из 5 проектов мы описали процесс «как сейчас»: от обращения пользователя до согласования затрат.

Что увидели: хаос. Кто-то фиксировал заявки в почте, кто-то в трекере, кто-то в голове. Оценки «на глаз». Приёмка «когда вспомнили». Отчёты — общей строкой.

Что сделали: унифицировали процесс. Появились чёткие этапы:

1. Регистрация заявки (единая форма в Jira)

2. Классификация (багфикс / новая функциональность / консультация)

3. Оценка трудозатрат

4. Согласование с заказчиком (или сразу в план, если < 5 часов)

5. Постановка в план работ

6. Разработка / реализация

7. Приёмка заказчиком (в течение отчётного периода)

8. Детализированный отчёт

9. Согласование затрат

Описал это в нотациях, понятных и технарям, и бизнесу.

4.2. Собрал и классифицировал бэклоги (сначала командой)

Команда сама расставила приоритеты: «это реально нужно бизнесу, а это — невнятная хотелка пользователя».

Результат: я получил честную картину глазами тех, кто делает.

4.3. Пошёл к заказчикам без готовых решений

Я не нёс им «наше видение». Я спросил:

• Какие у вас боли?

• Дайте свой бэклог

• Приоритезируйте каждую заявку по бизнес-критериям (сколько пользователей, как срочно, надо ли обучение)

• Что вам непонятно в наших отчётах?

• Как вам удобно общаться?

Результат: заказчики сами переписали и актуализировали высокоприоритетные заявки. Часть ушла в архив как невостребованная. А главное — я получил матрицу детализации отчётов. Заказчики наконец поняли, зачем вообще нужен PM на проекте.

5. Артефакт №1: Регламент взаимодействия

На основе собранной информации я разработал Регламент взаимодействия Сторон — проектный документ, который формализовал совместные действия. Он не являлся допсоглашением к договору, но был согласован руководителями проектов обеих сторон.

Вот его структура (этапы, которые мы ввели):

Этот регламент стал рабочей конституцией проекта. Он снял 90% вопросов «кто виноват» и «что делать».

6. Артефакт №2: Детализация отчётности (как было → как стало)

Как было (пример агрегированного отчёта)

До внедрения регламента отчёты выглядели как «чёрный ящик»:

Итого: ХХ часов одной строкой по каждому блоку.

Заказчик видел только фамилии и общие часы. Без понимания: что именно делали, сколько занял анализ, сколько — разработка, сколько — тестирование. Отсюда недоверие и задержки согласования.

Как стало (детализированный отчёт)

После внедрения регламента каждый отчёт стал прозрачным — позадачно, с разбивкой по ролям и этапам:

Всего: 65 часов — но теперь заказчик видит:

• Какая заявка сколько заняла

• Кто и сколько делал (аналитик vs разработчик)

• Что было консультацией, а что — реальной доработкой

Результат: прозрачность породила доверие. Доверие — рост лимитов. Заказчик перестал задавать вопрос «за что эти часы?» и начал согласовывать отчёты без задержек.

7. Ключевые правила, которых не было в договоре

Регламент ввёл несколько «фишек», которые не были прописаны в исходном договоре, но перевернули отношение заказчика:

Эти четыре правила сняли основные боли: долгое ожидание, непонятные отчёты, конфликты по срокам.

8. Результат: цифры, команда, перспектива

Цифры, ради которых всё затевалось (по 5 проектам):

Важный нюанс: выручка выросла не в 2–3 раза от изначальных лимитов, а в 5–6 раз от той, что реально получали до меня (потому что раньше заказчики не согласовывали даже заложенные часы).

Команда

• Было: 2 человека с неполной загрузкой, работали по выходным без бонусов

• Стало: 6 человек на фултайм + регулярные бонусы по результатам отчётного периода

Планирование

• Было: горизонт — «когда заказчик согласует»

• Стало: план работ на 9–12 месяцев вперёд

Заказчики

• Перестали думать о замене платформы

• Сами инициировали новые дополнительные соглашения

• Лимиты часов увеличены в 2–3 раза по каждому договору

9. Главный инсайт

На T&M нельзя делать вид, что работа идёт.

Когда все делают вид, что всё нормально:

• продакты делают вид, что проекты слишком мелкие

• команда делает вид, что занята (но не понимает зачем)

• заказчики делают вид, что платят за результат

…система деградирует. Быстро.

В этой истории не было магии. Не было гениального переговорного приёма. Был системный взгляд на 5 разрозненных проектов как на портфель и были простые, но жёсткие процессы:

1. Опиши, как работает хаос (AS IS)

2. Унифицируй процесс (единые правила для всех проектов)

3. Спроси заказчика, что ему нужно, дай ему приоритезировать самому

4. Сделай отчётность прозрачной (позадачно, по ролям)

5. Закрепи всё в простом регламенте на 5 страниц

Проблема мёртвых T&M-проектов почти никогда не в деньгах. Она в том, что никто не видит перспективы и никто не взял ответственность за системность.

Стоит одному человеку сказать «стоп, давайте просто опишем, как мы работаем, и спросим заказчика, что ему на самом деле нужно» — и портфель оживает.

За полгода — с нуля (почти закрытия) до 2,8 млн рублей выручки в месяц на 5 проектах и годового горизонта планирования. И это не предел.

P.S. Полный текст Регламента взаимодействия (на основе которого построена эта статья) выложу отдельным постом, если сообщество заинтересуется. Вопросы, комментарии, спорные моменты — велкам в обсуждение. Кейс реальный, цифры настоящие, имена заказчиков изменены.