Why software projects fail
Статья о том, почему проваливаются IT-проекты. Автор рассуждает о том, почему проваливаются IT-проекты, и дело как обычно не в одной большой ошибке. Проблемы чаще всего постепенно наслаиваются друг на друга: сначала команде ставят сроки без уточнения их реалистичности, рисками начинают пренебрегать, команда берет на себя слишком много, менеджмент не замечает проблем или предпочитает о них не говорить. В итоге продут или проект даже может выйти в релиз, но вскоре оказаться или никому не нужным или превращается бесконечную череду доработок.
Автор же предупреждает о следующих ошибках, которые могу по итогу привести к катастрофе
- Недооценка сложности разработки - оценки строятся на идеальном сценарии, без учёта ошибок, задержек и непредвиденных обстоятельств.
- Преждевременное усложнение архитектуры - команда создаёт универсальные решения под гипотетические будущие задачи. Когда появляются реальные требования, систему приходится дополнять исключениями и обходными путями.
- Недооценка внешних зависимостей - изменения в сторонних сервисах, библиотеках или API могут потребовать незапланированной работы и повлиять на сроки проекта.
- Постановка задач без контекста - команда получает список задач, но не понимает, какую проблему они решают и почему эти задачи важны.
- Приоритет сроков над требованиями - дедлайн определяют раньше, чем становится понятен объём работ. Затем команда вынуждена укладываться в дату при меняющихся или недостаточно проработанных требованиях.
- Присвоение заслуг команды - результат работы представляет менеджер, а вклад команды остаётся незаметным. Это снижает доверие и мотивацию.
- Задержка решений. - даже небольшие вопросы передаются на согласование руководству. Команда ждёт ответа, а работа замедляется.
- Нежелание останавливать неудачный проект - даже когда продукт перестаёт приносить пользу, его продолжают развивать, поскольку никто не хочет признавать, что потраченные ресурсы не оправдали себя
В общем, важно не только следить за планом и сроками, но и вовремя замечать эти сигналы, открыто обсуждать проблемы и быть готовыми пересмотреть решения, даже если для этого придётся остановить проект.
· 4 ч
Почти всегда они не взлетают из-за просчетов бизнеса. Если разработка и виновата, то только потому, что проще всего свалить на неё.
1
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён