Why software projects fail

Статья о том, почему проваливаются IT-проекты. Автор рассуждает о том, почему проваливаются IT-проекты, и дело как обычно не в одной большой ошибке. Проблемы чаще всего постепенно наслаиваются друг на друга: сначала команде ставят сроки без уточнения их реалистичности, рисками начинают пренебрегать, команда берет на себя слишком много, менеджмент не замечает проблем или предпочитает о них не говорить. В итоге продут или проект даже может выйти в релиз, но вскоре оказаться или никому не нужным или превращается бесконечную череду доработок.

Автор же предупреждает о следующих ошибках, которые могу по итогу привести к катастрофе

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

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

- Недооценка внешних зависимостей - изменения в сторонних сервисах, библиотеках или API могут потребовать незапланированной работы и повлиять на сроки проекта.

- Постановка задач без контекста - команда получает список задач, но не понимает, какую проблему они решают и почему эти задачи важны.

- Приоритет сроков над требованиями - дедлайн определяют раньше, чем становится понятен объём работ. Затем команда вынуждена укладываться в дату при меняющихся или недостаточно проработанных требованиях.

- Присвоение заслуг команды - результат работы представляет менеджер, а вклад команды остаётся незаметным. Это снижает доверие и мотивацию.

- Задержка решений. - даже небольшие вопросы передаются на согласование руководству. Команда ждёт ответа, а работа замедляется.

- Нежелание останавливать неудачный проект - даже когда продукт перестаёт приносить пользу, его продолжают развивать, поскольку никто не хочет признавать, что потраченные ресурсы не оправдали себя

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