Кейс: как я зашёл в 5 «мёртвых» T&M-проектов, которые никто не хотел вести, и превратил их в портфель на 1,5 года с ростом выручки в 5–6 раз
Оглавление
Ситуация: 5 проектов, от которых все отказались
Технологический контекст
Что я увидел внутри: боль трёх сторон
Что я сделал за первые 2 недели
Артефакт №1: Регламент взаимодействия
Артефакт №2: Детализация отчётности (как было → как стало)
Ключевые правила, которых не было в договоре
Результат: цифры, команда, перспектива
Главный инсайт
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 проектов мы описали процесс «как сейчас»: от обращения пользователя до согласования затрат.
Что увидели: хаос. Кто-то фиксировал заявки в почте, кто-то в трекере, кто-то в голове. Оценки «на глаз». Приёмка «когда вспомнили». Отчёты — общей строкой.
Что сделали: унифицировали процесс. Появились чёткие этапы:
Регистрация заявки (единая форма в Jira)
Классификация (багфикс / новая функциональность / консультация)
Оценка трудозатрат
Согласование с заказчиком (или сразу в план, если < 5 часов)
Постановка в план работ
Разработка / реализация
Приёмка заказчиком (в течение отчётного периода)
Детализированный отчёт
Согласование затрат
Описал это в нотациях, понятных и технарям, и бизнесу.
4.2. Собрал и классифицировал бэклоги (сначала командой)
Команда сама расставила приоритеты: «это реально нужно бизнесу, а это — невнятная хотелка пользователя».
Результат: я получил честную картину глазами тех, кто делает.
4.3. Пошёл к заказчикам без готовых решений
Я не нёс им «наше видение». Я спросил:
Какие у вас боли?
Дайте свой бэклог
Приоритезируйте каждую заявку по бизнес-критериям (сколько пользователей, как срочно, надо ли обучение)
Что вам непонятно в наших отчётах?
Как вам удобно общаться?
Результат: заказчики сами переписали и актуализировали высокоприоритетные заявки. Часть ушла в архив как невостребованная. А главное — я получил матрицу детализации отчётов. Заказчики наконец поняли, зачем вообще нужен PM на проекте.
5. Артефакт №1: Регламент взаимодействия
На основе собранной информации я разработал Регламент взаимодействия Сторон — проектный документ, который формализовал совместные действия. Он не являлся допсоглашением к договору, но был согласован руководителями проектов обеих сторон.
Вот его структура (этапы, которые мы ввели):
№ | Этап | Что регламентирует |
|---|---|---|
1 | Общие условия | Цель документа, доступность ресурсов, время реакции/решения, анализ запросов, проектирование, отчётный период, развёртывание релиза |
2 | Обработка заявок | Создание, описание, классификация, первичный анализ, исследование, оценка, принятие решения заказчиком |
3 | Планирование работ | Перспективный план, план работ, релизное планирование |
4 | Реализация | Запросы до 5 часов (без доп. согласования), запросы после оценки, реализация в рамках релиза |
5 | Приёмка результатов | Что считать результатом, закрытие заявок, подтверждение трудозатрат и оплата |
Этот регламент стал рабочей конституцией проекта. Он снял 90% вопросов «кто виноват» и «что делать».
6. Артефакт №2: Детализация отчётности (как было → как стало)
Как было (пример агрегированного отчёта)
До внедрения регламента отчёты выглядели как «чёрный ящик»:
Сроки | Описание услуги | ФИО специалиста | Трудозатраты, часы |
|---|---|---|---|
Отчётный мес | Управление командой сопровождения и регламентных работ, коммуникации, документооборот | ||
Отчётный мес | Консультации, анализ, оценка заявок | ||
Отчётный мес | Релиз |
Итого: ХХ часов одной строкой по каждому блоку.
Заказчик видел только фамилии и общие часы. Без понимания: что именно делали, сколько занял анализ, сколько — разработка, сколько — тестирование. Отсюда недоверие и задержки согласования.
Как стало (детализированный отчёт)
После внедрения регламента каждый отчёт стал прозрачным — позадачно, с разбивкой по ролям и этапам:
№ заявки | Название заявки | Детальное описание | Тип | Оценка/консультация | Реализация |
|---|---|---|---|---|---|
49198 | Перенастроить пакеты на другого пользователя | FW: перенастройка | Консультация | Аналитик — 2 ч | Разработчик — 1 ч |
49250 | Не сформирован реестр на оплату | Реестр за 09.06 | Консультация | Аналитик — 1 ч | — |
49246 | Продублировано уведомление | Уведомление президента | Консультация | Аналитик — 1 ч | — |
49251 | Расширение функциональности | Колонка «Дата согласования» | Консультация | Аналитик — 5 ч | Разработчик — 1 ч |
46084 | Увольнение сотрудников | Как выстроить процесс в K5 | Консультация | Аналитик — 2 ч | — |
… | … | … | … | … | … |
Итого | 35 часов (аналитика) | 30 часов (разработка) |
Всего: 65 часов — но теперь заказчик видит:
Какая заявка сколько заняла
Кто и сколько делал (аналитик vs разработчик)
Что было консультацией, а что — реальной доработкой
Результат: прозрачность породила доверие. Доверие — рост лимитов. Заказчик перестал задавать вопрос «за что эти часы?» и начал согласовывать отчёты без задержек.
7. Ключевые правила, которых не было в договоре
Регламент ввёл несколько «фишек», которые не были прописаны в исходном договоре, но перевернули отношение заказчика:
Правило | Суть |
|---|---|
Задачи до 5 часов | Не ждут отдельной «отмашки» заказчика — ставятся в план сразу. Результат принимается постфактум |
Долгие задачи (> месяца) | Декомпозируем так, чтобы заказчик получал промежуточный осязаемый результат каждый отчётный период |
Приёмка в период | Заказчик обязан организовать приёмочные испытания в течение одного отчётного периода — иначе его же приоритет теряет смысл |
Крупные доработки | Выносим в отдельные соглашения с отдельным бюджетом и ресурсами — позволяют работать параллельно с основной очередью |
Эти четыре правила сняли основные боли: долгое ожидание, непонятные отчёты, конфликты по срокам.
8. Результат: цифры, команда, перспектива
Цифры, ради которых всё затевалось (по 5 проектам):
Показатель | ДО (среднее на проект в месяц) | ПОСЛЕ (через 6 месяцев) | Рост |
|---|---|---|---|
Часовая ставка (средняя) | 4 200 руб. | 4 680 руб. | +11% |
Лимит часов в месяц | 40 | 120 | в 3 раза |
Выручка в месяц с проекта | ~840 000 руб. | ~2 808 000 руб. | +234% |
Важный нюанс: выручка выросла не в 2–3 раза от изначальных лимитов, а в 5–6 раз от той, что реально получали до меня (потому что раньше заказчики не согласовывали даже заложенные часы).
Команда
Было: 2 человека с неполной загрузкой, работали по выходным без бонусов
Стало: 6 человек на фултайм + регулярные бонусы по результатам отчётного периода
Планирование
Было: горизонт — «когда заказчик согласует»
Стало: план работ на 9–12 месяцев вперёд
Заказчики
Перестали думать о замене платформы
Сами инициировали новые дополнительные соглашения
Лимиты часов увеличены в 2–3 раза по каждому договору
9. Главный инсайт
На T&M нельзя делать вид, что работа идёт.
Когда все делают вид, что всё нормально:
продакты делают вид, что проекты слишком мелкие
команда делает вид, что занята (но не понимает зачем)
заказчики делают вид, что платят за результат
…система деградирует. Быстро.
В этой истории не было магии. Не было гениального переговорного приёма. Был системный взгляд на 5 разрозненных проектов как на портфель и были простые, но жёсткие процессы:
Опиши, как работает хаос (AS IS)
Унифицируй процесс (единые правила для всех проектов)
Спроси заказчика, что ему нужно, дай ему приоритезировать самому
Сделай отчётность прозрачной (позадачно, по ролям)
Закрепи всё в простом регламенте на 5 страниц
Проблема мёртвых T&M-проектов почти никогда не в деньгах. Она в том, что никто не видит перспективы и никто не взял ответственность за системность.
Стоит одному человеку сказать «стоп, давайте просто опишем, как мы работаем, и спросим заказчика, что ему на самом деле нужно» — и портфель оживает.
За полгода — с нуля (почти закрытия) до 2,8 млн рублей выручки в месяц на 5 проектах и годового горизонта планирования. И это не предел.
P.S. Полный текст Регламента взаимодействия (на основе которого построена эта статья) выложу отдельным постом, если сообщество заинтересуется. Вопросы, комментарии, спорные моменты — велкам в обсуждение. Кейс реальный, цифры настоящие, имена заказчиков изменены.
