Спасение проектов

Половина проектов, в которые я вхожу — это проекты, которые кто-то начал, но не смог довести до результата. Типичная картина: компания потратила 8 месяцев и 70% бюджета, а работает только логин и пара справочников. Команда разработки выгорела, заказчик потерял доверие, менеджер проекта пишет отчеты о прогрессе, которого нет.

Один из характерных случаев: крупная компания внедряла CRM-систему через именитого вендора. Через 10 месяцев — ни одного рабочего бизнес-процесса. Причина оказалась не в технологии: требования собирали формально, архитектуру рисовали красиво, но никто не разобрался, как на самом деле работает бизнес. Система проектировалась под идеальный процесс, которого в компании не существовало. Моя диагностика заняла 10 дней. Мы выделили 3 критических процесса из 15, переспроектировали их, и через 6 недель запустили первый модуль в продакшн.

Корень проблемы почти никогда не в технологии. В 80% случаев это одно из трех: нечеткие требования, отсутствие owner’а с полномочиями принимать решения, или разрыв между тем, что хочет бизнес, и тем, что строит команда. Диагностика — это не аудит кода. Это разговор с людьми: заказчиком, командой, пользователями. Именно в этих разговорах становится видно, где и когда проект свернул не туда.

Честность — главный инструмент. Я не скажу “всё починим” — я скажу, что можно спасти, что придется переделать, а что нужно выбросить. Иногда лучший совет — остановить проект и начать заново с правильным фундаментом. Это больно, но дешевле, чем ещё полгода работы в тупике.