Когда IT-проект проваливается, удобно искать причину в разработке: выбрали не тот стек, неправильно оценили сроки, команда была слабой.
Но очень многие проблемы возникают раньше — в момент, когда проект ещё существует только в презентациях, бюджетах и ожиданиях.
Начали с решения, а не с проблемы
«Нам нужна новая CRM», «нужно внедрить AI», «давайте сделаем мобильное приложение» — это уже варианты решения.
Если никто не договорился, какую проблему бизнеса мы пытаемся решить и как поймём, что стало лучше, команда будет оптимизировать то, что удалось сформулировать технически.
У проекта нет настоящего владельца
Спонсор, который выделил бюджет, и владелец результата — не всегда один человек.
Проекту нужен тот, кто готов регулярно принимать решения, расставлять приоритеты и отвечать за изменения со стороны бизнеса. Без такого человека спорные вопросы либо зависают, либо тихо решаются IT-командой.
Все хотят разного
Продажи хотят скорость. Финансы — контроль. Безопасность — ограничения. Операции — минимум изменений. Руководство — красивую дату запуска.
Если эти противоречия не разрешены до начала проекта, разработка не устранит их. Она просто превратит организационный конфликт в backlog.
Первая версия уже слишком большая
Желание «сразу сделать нормально» часто создаёт проект, который слишком долго не даёт работающего результата.
Чем больше первая версия, тем дольше компания живёт на предположениях. Ошибки в понимании пользователей и процессов обнаруживаются поздно, когда изменить направление уже дорого.
Система должна исправить плохой процесс
Автоматизация не всегда делает процесс лучше. Иногда она просто делает плохой процесс быстрее и жёстче.
Если подразделения не договорились, кто за что отвечает, какие данные правильные и где принимается решение, новая система зафиксирует этот конфликт в интерфейсах и интеграциях.
Срок придумали до понимания объёма
Дата может быть реальным бизнес-ограничением. Но тогда объём должен быть переменной.
Если заранее фиксируются и дата, и полный набор функций, и бюджет, а неизвестность проекта при этом игнорируется, команда получает не план, а набор несовместимых обещаний.
Слишком рано выбрали технологию или поставщика
Иногда решение фактически определяется ещё до того, как команда поняла требования. После этого проект начинает подгонять проблему под выбранный продукт.
Хорошая технология не спасает от неверно поставленной задачи.
Что стоит сделать до старта разработки
- Одним предложением сформулировать бизнес-проблему.
- Определить владельца результата со стороны бизнеса.
- Зафиксировать, что сознательно не входит в первую версию.
- Проверить самые рискованные предположения до большого бюджета.
- Договориться, какие показатели покажут, что проект действительно полезен.
Разработка может плохо реализовать хороший проект. Но она не может сделать хорошим проект, который был плохо задуман.