Провал начинается не в коде
Когда проект заходит в тупик - бюджет исчерпан, сроки сорваны, продукт не работает так, как от него ждали, - первый рефлекс: винить разработчиков. В реальности причина почти всегда лежит выше по цепочке, и замена исполнителей не решает организационную проблему.
Главных причин срыва проектов три, и ни одна из них не техническая:
- Цели проекта сформулированы как список функций, а не как измеримый бизнес-результат.
- На стороне заказчика нет владельца продукта (Product Owner) - человека, который принимает решения по продукту в режиме реального времени.
- Подрядчик выбран по минимальной цене, без проверки того, понимает ли он задачу.
Каждый из этих факторов в одиночку способен увести проект в тупик. Вместе они гарантируют это.
Подробное техническое задание не заменяет понимания цели. Система может буквально соответствовать каждой строке ТЗ - и при этом не решать ни одной реальной задачи бизнеса. Это происходит, когда ТЗ пишется как список пожеланий, а не как описание желаемого результата.
Карта типичных точек разрыва
Ниже систематизированный список причин сбоев, которые мы наблюдали в собственных проектах и при работе с проектами после неудачной попытки внедрения у других подрядчиков. Таблица нужна для быстрой сверки: где в вашем проекте прямо сейчас риск выше.
| Причина сбоя | Ответственность | Когда проявляется | Влияние |
|---|---|---|---|
| Размытые требования | Заказчик | До старта | Высокое |
| Нет владельца продукта | Заказчик | Весь проект | Высокое |
| Недооценка инфраструктуры | Подрядчик | После запуска | Среднее |
| Отсутствие плана проверки | Подрядчик | Тестирование | Среднее |
| Игнорирование внедрения | Оба | После запуска | Критическое |
| Нет плана поддержки | Оба | После запуска | Высокое |
| Смена приоритетов | Заказчик | Разработка | Среднее |
Влияние оценивается по совокупности: стоимость исправления, потери от простоя и репутационный ущерб. «Критическое» означает, что последствия переживают сам проект и сохраняются за его пределами.
Разбор каждой причины
Ниже - по каждой из корневых причин. Формулировка проблемы, как она проявляется в реальности и что с этим делать до того, как будет подписан договор.
Размытые требования
Самая распространённая и самая дорогая проблема. Заказчик знает, что хочет получить, но описывает это на языке интерфейса («сделайте кнопку»), а не на языке бизнеса («нам нужно сократить время обработки заявки с 3 дней до 4 часов»).
Разработчик реализует буквально то, что написано. В итоге кнопка есть - процесс не ускорился. А переделка стоит в разы дороже, чем правильная постановка задачи на старте.
Решение простое по формулировке и сложное в практике: до написания ТЗ проводится бизнес-анализ. Не «что должна делать система», а «какой результат бизнеса мы измерим через 6 месяцев после запуска».
Отдельная ошибка - ожидать, что подрядчик сам восстановит логику компании по разрозненным данным и интервью. Почему автоматизация бизнес-процессов начинается не с разработчика , мы разбираем на примере проекта, где бизнес-анализ обнаружил зависимость от личных договорённостей сотрудников.
Нет владельца продукта на стороне клиента
Владелец продукта (Product Owner) - человек, который принимает решения по продукту в режиме реального времени. Не согласовывает - решает. В большинстве корпоративных проектов такого человека нет: есть комитет, занятый руководитель и несколько отделов с конфликтующими интересами.
Результат предсказуем: разработчики ждут решений неделями, приоритеты меняются на каждой итерации, команда работает вхолостую. Сроки смещаются не из-за технических проблем, а из-за организационного паралича на стороне заказчика.
Подрядчик выбран по минимальной цене
В тендере побеждает тот, кто дал минимальную цену. В проектах по созданию информационных систем минимальная цена часто означает одно из двух: команда либо не поняла реального объёма работ, либо заранее планирует компенсировать заниженную оценку дополнительными соглашениями в процессе.
Оба сценария заканчиваются одинаково. Первый - срывом сроков и качества. Второй - финальной стоимостью, которая превышает рыночную в полтора-два раза, причём отношения с подрядчиком к этому моменту уже испорчены.
Игнорирование этапа внедрения
Система запущена. Технически работает. Через три месяца выясняется, что 60 % сотрудников продолжают работать по-старому: ведут учёт в Excel, обходят новые процессы, жалуются на неудобство.
Это не саботаж. Это следствие того, что внедрение не было спроектировано как отдельный этап: не было миграции данных, не было обучения, не было адаптации интерфейса под реальные рабочие сценарии. Продукт есть - изменения в работе нет.
Возврат инвестиций (ROI) от информационной системы считается не от даты запуска, а от даты реального перехода команды на новый процесс. Разрыв между этими датами стоит денег, и обычно его никто не закладывает в бюджет.
О том, как именно меняется повседневная работа команды, когда новая система действительно используется, а не обходится, мы разбираем в материале «Операционная эффективность с современными информационными системами» .
Как выглядит проект, который не проваливается
Ниже - не идеальная методология, а практическая карта того, что должно происходить на каждом этапе, чтобы проект дошёл до результата. Мы опирались на ту же выборку проектов, на которой построен раздел о разрывах, - это обратная сторона той же монеты.
| Этап | Что делается правильно | Результат |
|---|---|---|
| Предпроектный анализ | Фиксация бизнес-целей, а не функций. Карта стейкхолдеров. | Контракт подписан на основе понятых целей |
| Проектирование | Архитектура под нагрузку и развитие. Прототип ключевых сценариев. | Нет архитектурных тупиков в середине разработки |
| Разработка | Итерации с демонстрацией промежуточного результата. Владелец продукта на стороне клиента. | Отклонения видны рано, а не на сдаче |
| Тестирование | Нагрузочное, регрессионное, пользовательское. | Ошибки в рабочей версии - исключение, а не норма |
| Запуск | Поэтапный ввод в эксплуатацию. Мониторинг с первого дня. | Не бывает «всё упало в первый день» |
| Внедрение | Обучение, миграция данных, параллельная эксплуатация старой и новой систем. | Система реально используется, а не саботируется |
| Поддержка | Договор об уровне обслуживания, приоритизация задач, план развития продукта. | Развитие продукта управляемо |
Главное, что объединяет эти строки: на каждом этапе ответственность явная, результат измерим, а переход на следующий этап имеет чёткий критерий. Проект перестаёт быть «чёрным ящиком», в который стороны кидают надежды и счета.