Цифра из заголовка не выдумана: по данным исследований Standish Group (CHAOS Report), около 70–80% IT-проектов превышают первоначальный бюджет или срок, либо не доставляют заявленную ценность.

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

Категория 1: Проблемы с требованиями (4 кейса из 12)

Кейс 1. «Сделайте как у конкурента»

Заказчик: интернет-магазин косметики.
Бриф: «Хотим личный кабинет как у Золотого Яблока».

Никто не проанализировал, какие именно функции нужны. Студия сделала то, что увидела на сайте конкурента. Через месяц после запуска заказчик сказал: «А где система лояльности? Она же у них есть».

Система лояльности была в ТЗ — буквально одна строчка: «система лояльности — как у конкурента». Разработчики сделали простые баллы. Заказчик имел в виду уровни, кешбэк и подарки на день рождения.

Итог: +40% к бюджету, +6 недель к срокам.

Причина: требования описаны через референс без детализации. Каждая строчка ТЗ «как у X» — потенциальный конфликт.

Кейс 2. Движущаяся цель

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

За 4 месяца разработки scope изменился 3 раза. Каждое изменение тянуло за собой переработку уже написанного кода.

Итог: проект стоил в 2,3 раза больше первоначальной оценки, запустился через 9 месяцев вместо 4.

Причина: отсутствие процесса управления изменениями. Любое изменение требований должно идти через официальный change request с оценкой стоимости и сроков.

Кейс 3. Разные ожидания у разных стейкхолдеров

Корпоративный заказчик — производственная компания. У CTO — одно видение системы, у директора по продажам — другое, у финансового директора — третье.

Разработчики ходили на встречи с разными людьми и получали противоречивые требования. Никто из заказчиков не имел полномочий принять окончательное решение.

Итог: проект заморожен через 5 месяцев с 60% реализацией. Внутренние конфликты не дали дойти до финала.

Причина: отсутствие единого владельца продукта (Product Owner) на стороне заказчика.

Кейс 4. «Разберёмся в процессе»

Небольшая студия взяла проект без ТЗ. Договорились на почасовую оплату и «гибкий процесс».

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

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

Итог: клиент остановил проект на 30% реализации, потеряв 700 000 ₽.

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

Категория 2: Технические проблемы (3 кейса из 12)

Кейс 5. Технический долг как бомба замедленного действия

Стартап запустил MVP быстро и дёшево. Код был написан «чтобы работало» — без тестов, без документации, с дублированием логики.

Через год пришёл второй раунд инвестиций. Нужно было масштабировать. Новый разработчик отказался работать с кодом. Второй попросил 3 месяца только на рефакторинг.

Итог: полная переписка за 2,1 млн ₽ — вместо расширения функционала.

Причина: инвестиции в качество кода воспринимались как лишняя трата на этапе MVP. В реальности — это обязательство перед будущим.

Кейс 6. Недооценка интеграций

Корпоративная система с интеграцией в 1С, CRM и телефонию. На бумаге — три интеграции. На практике — 1С у клиента самописная версия, CRM с нестандартным API, телефония через устаревший протокол.

Итог: только интеграции заняли 2 месяца из запланированных 4.

Причина: интеграции с внешними системами всегда стоит оценивать отдельно и с запасом. Правило нашей студии: умножаем первоначальную оценку интеграций на 2,5.

Кейс 7. Масштаб, которого не ждали

SaaS-продукт для HR. Прогноз: 500 пользователей в первые полгода. Реальность: вирусный рост, 15 000 пользователей за месяц после публикации на VC.

Архитектура не была готова к такой нагрузке. Сервис падал ежедневно в пиковые часы. Команда месяц тушила пожары вместо разработки новых фич.

Итог: потеря части пользователей из-за нестабильности, + 800 000 ₽ на экстренный рефакторинг и переезд на новую инфраструктуру.

Причина: архитектурные решения для MVP и для продукта с нагрузкой — разные. Нужно либо сразу закладывать масштабируемость (дороже), либо иметь план "что делаем при взрывном росте".

Категория 3: Процессные и командные проблемы (3 кейса из 12)

Кейс 8. Ключевой разработчик ушёл

Агентство взяло проект под ключ. Один старший разработчик держал всю архитектуру в голове. Через 2 месяца разработки он ушёл к другому заказчику с более высокой ставкой.

Новый разработчик потратил 3 недели на разбор кода. Архитектурные решения были нигде не задокументированы.

Итог: срок вырос на 2 месяца, агентство вышло в минус на проекте.

Причина: bus factor = 1. Критически важно документировать архитектурные решения и не держать знания в одной голове.

Кейс 9. Нет технического лидерства на стороне заказчика

Стартап нанял фрилансера. Основатель — не технарь, не понимал, что происходит в коде. Фрилансер отчитывался: «Всё идёт по плану».

Через 3 месяца обнаружилось, что фрилансер использовал устаревшие библиотеки с известными уязвимостями, не писал тестов, а "готовые" функции не работали в edge cases.

Итог: приглашённый технический консультант на аудит кода сказал: «Это нужно переделать».

Причина: без технического надзора невозможно оценить качество работы. Если у вас нет своего CTO — нужен внешний технический аудит хотя бы раз в месяц.

Кейс 10. Нереалистичные дедлайны

Основатель пообещал инвестору демо через 6 недель. Разработчики сказали, что реально — 12. Основатель настоял на 6.

Команда работала в режиме марш-броска. Через 6 недель был готов демо-прототип, который выглядел как продукт. Инвестиции получили.

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

Причина: дедлайны, установленные без учёта реальной ёмкости команды, не ускоряют работу — они разрушают качество.

Категория 4: Финансовые и контрактные проблемы (2 кейса из 12)

Кейс 11. Time & Materials без верхней границы

Студия работала по почасовой ставке. Договора на фиксированный объём не было.

Первоначальная оценка — 40 часов, 200 000 ₽. Итоговый счёт — 120 часов, 600 000 ₽.

По каждому этапу студия обоснованно объясняла, почему задача заняла больше. Но клиент не был готов к трёхкратному превышению.

Причина: T&M без согласованного бюджетного потолка — это открытый чек.

Кейс 12. Приёмка без критериев

Проект сдан. Клиент подписал акт. Через неделю начал предъявлять претензии: «Это работает не так, как я ожидал».

В договоре не было критериев приёмки. «Работает» и «работает так, как хотел заказчик» — разные понятия.

Итог: 2 месяца судебно-переговорного процесса, в итоге студия доработала часть за свой счёт.

Причина: критерии приёмки — обязательная часть договора. Без них любое разногласие решается по усмотрению суда или переговорами.

Как мы решаем эти проблемы в нашей студии

Риск Наше решение
Размытые требования Обязательная аналитика и детальное ТЗ перед стартом
Движущийся scope Фиксированный scope в договоре, change request через письменный запрос
Нет Product Owner Мы назначаем своего PM как единую точку коммуникации
Техдолг Code review, тесты как стандарт, не опция
Зависимость от одного человека Документация архитектурных решений, парная разработка
Нереалистичные дедлайны Не берём проекты с заведомо нереальными сроками
Финансовая неопределённость Fixed price / fixed scope на каждый проект
Размытая приёмка Критерии приёмки — часть ТЗ и договора

Это и есть суть нашего подхода: fixed scope / fixed price как прямое решение описанных проблем. Вы знаете, что получите, за сколько и когда.

Если ваш проект буксует — напишите в @hexbit_requests_bot, сделаем диагностику бесплатно.

Следующая статья: личный кабинет или Telegram-бот — что выбрать малому бизнесу в 2026 году.