РИСКИ РАЗРАБОТКИ / АНТИКРИЗИСНЫЙ МЕНЕДЖМЕНТ
Почему ИТ-проекты буксуют на отметке 90% готовности: как остановить «вечный ремонт» и начать получать результат.
В современном бизнесе ИТ-трансформация часто сталкивается с деструктивной патологией — «синдромом вечной стройки». Это явление противоречит базовой логике капитала: инвестиции должны создавать актив, генерирующий возврат, а не превращаться в бесконечную статью расходов. По данным BCG (Boston Consulting Group) 70% цифровых трансформаций не укладываются в сроки или бюджет, а многие так и не пересекают черту реальной эксплуатации.
В этой статье мы разберем, почему ИТ-проекты часто буксуют на месте, и дадим 6 конкретных советов. Они помогут вам довести разработку до конца и превратить её в инструмент, который приносит реальную пользу и деньги бизнесу.
Феноменология «вечных 90%» и метрики результата
1. Асимптота завершения: Почему автоматизация склада останавливается за шаг до запуска.
Наиболее деструктивная характеристика проблемного ИТ-проекта — его бесконечное приближение к результату. В индустрии это известно как «правило 90-90»: первые 90% работы занимают 10% времени, а оставшиеся 10% — еще 90% времени.
Для собственника бизнеса, привыкшего к физическим активам (строительство завода или закупка тягачей), это звучит как абсурд. Однако в разработке это жесткая экономическая стратегия. Первые этапы — как решение будет работать, исследования, отрисовка интерфейсов, настройка серверов — это «легкая выручка» для подрядчика. Вы видите прогресс: экраны переключаются, отчеты быстро формируются на тестовых данных.
Кризис наступает на «последней миле» — при интеграции с реальной учетной системой (ERP), настройке безопасности и отработке исключительных ситуаций. Здесь подрядчик делает выбор:
Для собственника бизнеса, привыкшего к физическим активам (строительство завода или закупка тягачей), это звучит как абсурд. Однако в разработке это жесткая экономическая стратегия. Первые этапы — как решение будет работать, исследования, отрисовка интерфейсов, настройка серверов — это «легкая выручка» для подрядчика. Вы видите прогресс: экраны переключаются, отчеты быстро формируются на тестовых данных.
Кризис наступает на «последней миле» — при интеграции с реальной учетной системой (ERP), настройке безопасности и отработке исключительных ситуаций. Здесь подрядчик делает выбор:
- Завершить проект: это требует привлечения самых дорогих специалистов для выполнения самой скучной и трудоемкой работы (интеграции, отладка, документация и тд). Завершение означает прекращение потока платежей от клиента.
- Поддерживать процесс: удерживать проект в состоянии 90% готовности, что позволяет бесконечно выставлять счета за стабилизацию, рефакторинг и оптимизацию. Это также позволяет ротировать на проекте младший персонал, обучая их за счет клиента.
2. «Арбузная отчетность» и переход к бизнес-метрикам.
Подрядчики часто используют метод «арбузных отчетов»: зеленые снаружи (в презентациях для заказчика), но ярко-красные внутри (в реальности технического долга и недоделок). Управляющий проектом со стороны подрядчика стерилизует данные поступающие на уровень заказчика:
Зеленая оболочка: Система управления производством готова на 90%.
Красная мякоть: В реальности модули работают изолированно, а их попытка обменяться данными об остатках сырья приводит к краху всей базы данных.
Проект может месяцами оставаться «зеленым», потребляя бюджет, вплоть до недели перед запуском. В этот момент статус мгновенно переключается на «красный», и сроки сдвигаются на полгода. Это не внезапная авария; проект был «красным» месяцами, но система отчетности скрывала это, пока сокрытие не стало невозможным.
Зеленая оболочка: Система управления производством готова на 90%.
Красная мякоть: В реальности модули работают изолированно, а их попытка обменяться данными об остатках сырья приводит к краху всей базы данных.
Проект может месяцами оставаться «зеленым», потребляя бюджет, вплоть до недели перед запуском. В этот момент статус мгновенно переключается на «красный», и сроки сдвигаются на полгода. Это не внезапная авария; проект был «красным» месяцами, но система отчетности скрывала это, пока сокрытие не стало невозможным.
3. Психологическая ловушка невозвратных затрат.
«Вечная стройка» держится на том, что собственник бизнеса психологически скомпрометирован. Ошибка невозвратных затрат заставляет продолжать финансирование провального проекта только потому, что в него уже вложены значительные средства.
В ИТ-проектах этот механизм используется как оружие. К моменту, когда стагнация на отметке 90% становится очевидной, владелец мог уже инвестировать €500k или €1M. Подрядчик знает это. Он использует страх «переписывания с нуля» для получения дополнительных траншей, часто звучит это так:
В ИТ-проектах этот механизм используется как оружие. К моменту, когда стагнация на отметке 90% становится очевидной, владелец мог уже инвестировать €500k или €1M. Подрядчик знает это. Он использует страх «переписывания с нуля» для получения дополнительных траншей, часто звучит это так:
«Нам нужно всего лишь два спринта, чтобы переписать базу данных под новые нагрузки».
«Мы не можем бросить сейчас, иначе весь код устареет».
«Вечный ремонт» продается как серия маленьких, логичных продлений. Каждое из них в отдельности кажется разумным. В совокупности они представляют собой проект, потерявший управление. Заказчик платит не за результат, а за процесс разработки — своего рода «подписку на надежду».
4. Разрыв в определении «Готовности».
Фундаментальным инструментом манипуляции является отсутствие жесткого, контрактно закрепленного определения «Готовности». В ментальной модели подрядчика «Сделано» означает «Код написан и отправлен в репозиторий». В ментальной модели собственника бизнеса «Сделано» означает «Система работает, приносит прибыль и не требует ежедневного вмешательства».
Этот семантический разрыв — пространство, где исчезает бюджет. Подрядчики без внешнего технического надзора будут считать задачи выполненными на этапе кодинга. Последующее исправление ошибок, которое должно быть гарантийным обязательством, часто оформляют как новые задачи по ставке, фактически заставляя клиента платить дважды за одну и ту же работу.
Этот семантический разрыв — пространство, где исчезает бюджет. Подрядчики без внешнего технического надзора будут считать задачи выполненными на этапе кодинга. Последующее исправление ошибок, которое должно быть гарантийным обязательством, часто оформляют как новые задачи по ставке, фактически заставляя клиента платить дважды за одну и ту же работу.
Чек-лист: показывали ли Вам «арбузный» отчёт?
- Статус проекта «зеленый» более 3 месяцев, но нет доступа к работающему прототипу;
- Сроки сдвигаются только за неделю до дедлайна;
- Бюджет расходуется на стабилизацию проделанной работы, а не на новые функции.
Что делать: вводить жёсткий мониторинг прогресса по метрикам результата для бизнеса/заказчика. Вместо отчета «готовность модуля 90%», используйте KPI, понятные вам как бизнесу: «Система успешно обработала 100 реальных заказов без участия разработчика».
Почему ваш подрядчик финансово заинтересован в том, чтобы проект никогда не закончился?
1. Особенности модели «Время и Материалы» (T&M - Time & Materials).
Большинство бесконечных проектов работают на трудозатратной модели. В теории это дает гибкость для проектов с неопределенным объёмом работ. На практике, для нетехнического владельца, это создает классическую проблему:
В этой модели подрядчик финансово наказывается за эффективность. Если эксперт настроит интеграцию с датчиками на производстве за 4 часа, подрядчик получит €800 при себестоимости €650. Если ту же задачу будет делать стажер 40 часов, вендор получит €3 000, при себестоимости €800. Экономика контракта толкает исполнителя к неэффективности.
Это приводит к явлению «Набивки» счета, которое включает:
- Заказчик: Хочет работающую систему за минимальный бюджет.
- Подрядчик: Хочет максимизировать количество оплаченных часов и занять персонал.
В этой модели подрядчик финансово наказывается за эффективность. Если эксперт настроит интеграцию с датчиками на производстве за 4 часа, подрядчик получит €800 при себестоимости €650. Если ту же задачу будет делать стажер 40 часов, вендор получит €3 000, при себестоимости €800. Экономика контракта толкает исполнителя к неэффективности.
Это приводит к явлению «Набивки» счета, которое включает:
- Административное управление: оплата бесконечных встреч, исследований и настройки среды, не создающих добавленной стоимости.
- Обучение за счет заказчика: часы, пока разработчик читает документацию по новой технологии, которую он впервые видит.
- Рефакторинг ради процесса: бесконечные циклы переписывания кода для «улучшения», которые не меняют функционал для конечного пользователя.
2. Разрастание объема проекта как стратегия.
В строительстве перенос несущей стены требует доп.соглашения и сметы. В ИТ под лозунгом гибкости «Agile» вам предлагают добавлять функции «по ходу дела». Гениальные идеи вроде: «Раз мы автоматизируем закупки, давайте добавим туда модуль прогнозирования спроса на базе нейросетей».
Звучит как забота о продукте? В реальности это стратегия размывания сроков. Расширяя фронт работ, подрядчик увеличивает площадь атаки для багов (ошибок в коде или логике) и вносит хаос в архитектуру.
Для подрядчика это страховка от ответственности. Постоянно меняя требования, они делают невозможным соблюдение первоначальных сроков. Если проект опаздывает, они легитимно указывают на Ваши новые «хотелки» как на причину. «Вечный ремонт» становится сотворчеством: вендор предлагает, а заказчик, стремясь к идеалу, соглашается, не осознавая, что покупает очередную задержку.
Звучит как забота о продукте? В реальности это стратегия размывания сроков. Расширяя фронт работ, подрядчик увеличивает площадь атаки для багов (ошибок в коде или логике) и вносит хаос в архитектуру.
Для подрядчика это страховка от ответственности. Постоянно меняя требования, они делают невозможным соблюдение первоначальных сроков. Если проект опаздывает, они легитимно указывают на Ваши новые «хотелки» как на причину. «Вечный ремонт» становится сотворчеством: вендор предлагает, а заказчик, стремясь к идеалу, соглашается, не осознавая, что покупает очередную задержку.
Что делать: Чтобы избежать «набивки» счетов и бесконечного рефакторинга, на ключевых ролях трансформации должны стоять таланты высокого калибра. Это касается как стороны заказчика, так и подрядчика. Профессионалы фокусируются на кратчайшем пути к цели, а не на процессе ради процесса.
Agile — гибкая методология разработки, это подход к работе, где команда делает продукт маленькими шагами, часто показывает результат, собирает обратную связь и быстро меняет план, чтобы быстрее прийти к реальной ценности для пользователя и бизнеса. Это не оправдание отсутствия сроков. В правильных руках это инструмент быстрого снятия блокеров и адаптации. Это означает, что руководство вовлечено в процесс еженедельно, быстро принимая решения по изменению приоритетов, чтобы проект не превращался в «сотворчество ради задержек».
Agile — гибкая методология разработки, это подход к работе, где команда делает продукт маленькими шагами, часто показывает результат, собирает обратную связь и быстро меняет план, чтобы быстрее прийти к реальной ценности для пользователя и бизнеса. Это не оправдание отсутствия сроков. В правильных руках это инструмент быстрого снятия блокеров и адаптации. Это означает, что руководство вовлечено в процесс еженедельно, быстро принимая решения по изменению приоритетов, чтобы проект не превращался в «сотворчество ради задержек».
Архитектура проекта: от зависимости к гибкости
1. Использование моделей McKinsey как алиби.
Классическая модель «Три горизонта роста McKinsey» — это инструмент стратегии, разделяющий бизнес на текущее ядро (Горизонт 1), растущие возможности (Горизонт 2) и будущие трансформации (Горизонт 3), который часто используется для оправдания провалов. Когда дедлайн по внедрению системы управления цепочками поставок сорван, провал переупаковывается в стратегическую инициативу «Горизонта 2».
На этом этапе часто говорят:
На этом этапе часто говорят:
«Мы не просто пишем код, мы строим фундамент для будущего масштабирования бизнеса».
Это риторический щит. Построение абстрактных «возможностей» подменяет собой поставку работающего продукта.
2. Театр инноваций и разработка «ради резюме».
Вместо того чтобы внедрить надежную, «скучную» систему учета, ИТ-команда часто выбирает самые модные и сложные технологии. Это называется разработка «ради резюме»: программисты учатся за ваш счет, внедряя инструменты, которые избыточны для ваших задач (например, использование блокчейна там, где достаточно обычной базы данных). В итоге вы платите за сложность, которая замедляет проект и делает его поддержку в разы дороже.
3. Архитектура зависимости.
Самый циничный аспект «Вечного ремонта» — это преднамеренное создание зависимости. Это не просто использование закрытого программного обеспечения; это создание кодовой базы настолько запутанной, недокументированной и хрупкой, что никакая другая команда не сможет её перехватить без полного переписывания.
Тактики включают:
Что делать: внедрять гибкую ИТ-систему, которую вы можете легко менять и развивать по частям вслед за ростом вашего бизнеса. Архитектура должна быть масштабируемой и базироваться на индустриальных стандартах, а не на самописных библиотеках подрядчика.
Тактики включают:
- Спагетти-код: написание неструктурированного кода, логику которого понимает только автор.
- Собственные решения: использование самописных библиотек вместо индустриальных стандартов. Это гарантирует, что ни один фрилансер или другой подрядчик не сможет работать с кодом без месяцев обучения.
- Отсутствие документации: отказ документировать API (Application Programming Interface - «мост» или посредник, который позволяет двум разным программам «общаться» друг другом и обмениваться данными), схемы баз данных или процедуры переноса готового и протестированного программного кода на рабочие серверы, где он становится доступным для конечных пользователей. Часто под предлогом «мы работаем по Agile, код сам себя документирует».
- Заложничество доступов: контроль над облачными аккаунтами, репозиториями кода и доменами. Заказчик платит за актив, но ключи от него находятся в кармане подрядчика.
Что делать: внедрять гибкую ИТ-систему, которую вы можете легко менять и развивать по частям вслед за ростом вашего бизнеса. Архитектура должна быть масштабируемой и базироваться на индустриальных стандартах, а не на самописных библиотеках подрядчика.
Финансовая дисциплина и Единая стратегия
1. Трансформация Актива (CapEx - Capital Expenditure ) в Расход (OpEx - Operating Expenditure).
Финансовая трагедия «вечного ремонта» — в уничтожении балансовой стоимости компании.
- Капитальные затраты (CapEx): деньги на создание актива. Они увеличивают стоимость компании.
- Операционные расходы (OpEx): деньги, которые просто уменьшают вашу прибыль.
Чтобы капитализировать разработку ПО (поставить на баланс), вы должны доказать критерии капитализации затрат на стадию разработки (в т.ч. техническую осуществимость завершения, намерение завершить, наличие ресурсов, вероятные будущие выгоды и т.д.).
Если проект застрял в состоянии «90% готовности» и по факту перестал быть технически осуществимым / экономически оправданным / у компании нет ресурсов или намерения завершать, тогда:
«Вечный ремонт» уничтожает капитализацию компании. Если проект не завершен, затраты, которые должны были увеличить стоимость актива, превращаются в операционные расходы, уменьшающие прибыль здесь и сейчас.
Если проект застрял в состоянии «90% готовности» и по факту перестал быть технически осуществимым / экономически оправданным / у компании нет ресурсов или намерения завершать, тогда:
- новые затраты с этого момента, как правило, нельзя капитализировать (идут в расходы периода), потому что критерии не выполняются;
- уже капитализированное ранее нужно проверять на обесценение и при необходимости списать (частично или полностью) через убытки, если возмещаемая стоимость упала (вплоть до нуля).
«Вечный ремонт» уничтожает капитализацию компании. Если проект не завершен, затраты, которые должны были увеличить стоимость актива, превращаются в операционные расходы, уменьшающие прибыль здесь и сейчас.
2. Удар по EBITDA и оценке бизнеса.
Для собственника, планирующего продажу бизнеса, разница фатальна. Компании часто оцениваются через мультипликатор к прибыли (EBITDA).
Каждый евро, потраченный на «вечный ремонт» (OpEx), уменьшает вашу прибыль на этот же евро. Если компания тратит €700 тыс. в год на буксующее ИТ и оценивается с мультипликатором 10x, это уничтожает €7 млн. стоимости всего предприятия.
Каждый евро, потраченный на «вечный ремонт» (OpEx), уменьшает вашу прибыль на этот же евро. Если компания тратит €700 тыс. в год на буксующее ИТ и оценивается с мультипликатором 10x, это уничтожает €7 млн. стоимости всего предприятия.
3. Стоимость задержки поставки.
Помимо прямого сжигания денег, существует Стоимость задержки. Потерянная выручка: Новая платформа, которая должна была запуститься в первом квартале, все еще «в тестировании» в четвертом квартале. Это три квартала упущенных продаж или снижения операционных расходов. Пока проект не готов, конкуренты становятся эффективнее, быстрее, устойчивее. Система, спроектированная два года назад как передовая, запускается сейчас уже морально устаревшей.
Альтернативные издержки: капитал, запертый в провальном ИТ-проекте, мог быть направлен на маркетинг, закупку сырья, реновации или открытие филиалов.
Что делать: ИТ-проект не должен быть «вещью в себе». Только наличие единой стратегии и ясных целей трансформации (связка с P&L, дорожная карта) позволяет вовремя остановить инвестиции в неэффективные направления. Каждое внедрение должно отвечать на вопрос: «Как это приближает нас к стратегической цели?»
Альтернативные издержки: капитал, запертый в провальном ИТ-проекте, мог быть направлен на маркетинг, закупку сырья, реновации или открытие филиалов.
Что делать: ИТ-проект не должен быть «вещью в себе». Только наличие единой стратегии и ясных целей трансформации (связка с P&L, дорожная карта) позволяет вовремя остановить инвестиции в неэффективные направления. Каждое внедрение должно отвечать на вопрос: «Как это приближает нас к стратегической цели?»
Лидерство и Технадзор
Проект обречен, если им занимается только отдел ИТ. Требуется реальная готовность к переменам на всех уровнях: от первого лица компании до начальников отделов. Именно среднее звено часто тормозит процесс, опасаясь открытости, которую дает автоматизация.
Многие владельцы бизнеса полагают, что наличие в штате технического директора или сильного проектного менеджера на стороне подрядчика автоматически закрывает вопрос контроля. Это опасное заблуждение. Проблема не в некомпетентности кадров, а в фундаментальном конфликте интересов.
Многие владельцы бизнеса полагают, что наличие в штате технического директора или сильного проектного менеджера на стороне подрядчика автоматически закрывает вопрос контроля. Это опасное заблуждение. Проблема не в некомпетентности кадров, а в фундаментальном конфликте интересов.
1. Почему менеджер проекта вендора — это не ваш союзник.
Лояльность проектного менеджера принадлежит тому, кто платит ему зарплату. Его KPI (ключевые показатели эффективности) — утилизация ресурсов агентства и сохранение «зеленого» статуса в отчетах. Его задача — управлять процессом, а не защищать ваш капитал.
2. Парадокс внутреннего СТО: Конфликт интересов и самоаудит.
Технический директор компании — это строитель, отвечает за созидание и технологический стек. Поручать CTO функции контроля над собственными решениями — это классическая системная ошибка «самоаудита». Это равносильно просьбе к главному бухгалтеру провести независимый внешний аудит своей же отчетности.
Попытка объединить эти роли в одном человеке неизменно приводит к тому, что функция контроля приносится в жертву процессу строительства.
Лояльность проектного менеджера принадлежит тому, кто платит ему зарплату. Его KPI (ключевые показатели эффективности) — утилизация ресурсов агентства и сохранение «зеленого» статуса в отчетах. Его задача — управлять процессом, а не защищать ваш капитал.
2. Парадокс внутреннего СТО: Конфликт интересов и самоаудит.
Технический директор компании — это строитель, отвечает за созидание и технологический стек. Поручать CTO функции контроля над собственными решениями — это классическая системная ошибка «самоаудита». Это равносильно просьбе к главному бухгалтеру провести независимый внешний аудит своей же отчетности.
Попытка объединить эти роли в одном человеке неизменно приводит к тому, что функция контроля приносится в жертву процессу строительства.
Заключение: Как выйти из «вечного ремонта» и пересечь горизонт.
Синдром «вечной стройки в ИТ» — это не закон природы в разработке ПО. Это искусственное состояние, созданное конвергенцией порочных стимулов, психологических манипуляций и отсутствия экспертного надзора. Оно существует, потому что состоятельные, нетехнические владельцы бизнеса относятся к ИТ как к «черному ящику», требующему веры, а не как к капитальному проекту, требующему инженерной дисциплины.
Чтобы выйти из цикла «вечного ремонта», необходимо выполнение всех этих 6 условий:
Практическая рекомендация: При заключении контракта закрепите жесткое определение готовности (Definition of Ready & Done). Нужно потратить несколько часов своего времени на старте, чтобы сохранить сотни тысяч евро и месяцы напрасной работы в будущем.
Всё проще, чем кажется: не пытайтесь сразу говорить на языке программистов. Просто возьмите свою бизнес-цель и зафиксируйте её как критерий готовности.
Пример: Вместо абстрактного «разработать модуль логистики чтобы все работало», зафиксируйте решение вашей прикладной задачи: «Система считается готовой, когда кладовщик может собрать заказ по штрих-коду без бумажной накладной и данные об этом отражаются в системе в реальном времени».
Какая ваша бизнес-цель — то и пишите в определение готовности.
Если цель достигнута — работа сделана на 100%.
Чтобы выйти из цикла «вечного ремонта», необходимо выполнение всех этих 6 условий:
- Единая стратегия: четкое видение и измеримые результаты.
- Лидерство: реальное вовлечение руководства всех уровней.
- Таланты: привлечение экспертов, нацеленных на результат.
- Гибкое управление: быстрое принятие решений и фокус на целях.
- Мониторинг: контроль по бизнес-метрикам.
- Модульность: технологии, которые принадлежат вам, а не подрядчику.
Практическая рекомендация: При заключении контракта закрепите жесткое определение готовности (Definition of Ready & Done). Нужно потратить несколько часов своего времени на старте, чтобы сохранить сотни тысяч евро и месяцы напрасной работы в будущем.
Всё проще, чем кажется: не пытайтесь сразу говорить на языке программистов. Просто возьмите свою бизнес-цель и зафиксируйте её как критерий готовности.
Пример: Вместо абстрактного «разработать модуль логистики чтобы все работало», зафиксируйте решение вашей прикладной задачи: «Система считается готовой, когда кладовщик может собрать заказ по штрих-коду без бумажной накладной и данные об этом отражаются в системе в реальном времени».
Какая ваша бизнес-цель — то и пишите в определение готовности.
Если цель достигнута — работа сделана на 100%.