Причины
Нет чёткой цели
Нет чётких задач, которые решает проект в процессе работы
Сильное погружение в проработку незначительных деталей
Отказ от поддержки минимально жизнеспособного продукта (тот самый случай, когда проработка функциональности бежит дальше, чем основной скелет продукта)
Выбор неправильных инструментов
Когнитивные искажения
План действий
Для этого понадобится карандаш и бумага
1. Цели
Цель определяет итог, но не определяет способы его достижения. Определите список достигаемых проектом целей. Что в будет в итоге? Собственно зачем мы все здесь собрались?
2. Задачи
Действия, направленные на достижения поставленных целей. Определите список решаемых в процессе задач. Что нужно делать, чтоб добраться до цели?
3. Требования
Свойства, которыми обладает конечный результат. Бизнес-требования, технические требования, пользовательские требования. Обязательно проработайте оценку важности требований.
4. Роли
Определяем список задействованных прямо или косвенно ролей: людей, групп, прав, обязанностей, ответственности.
5. Компоненты и компоновка
Список составных частей исследуемого объекта. Возможно это абстрактные модули и схемы сборки и взаимодействия.
6. Минимально жизнеспособный продукт
Не путать с прототипом. Примеры минимально жизнеспособных продуктов: лом, кувалда. Это продукт с минимальным набором функций, но достаточный для решения основных поставленных задач и достижения главных целей.
7. Инструменты
Если для проекта собрана команда, но при этом нужна как минимум ещё одна команда, которая будет обслуживать платформу, то явно что-то идёт не так.
Не берите инструмент только потому, что его реклама везде, но вы с ним ещё не работали. Если есть специалист по этому инструменту, то попросите его собрать тестовый стенд. Оцените затраченное время, сложность сборки стенда и сложность работы с инструментом.
8. Детали реализации
Основные сущности, архитектура, пользовательские интефейсы, документирование кода, документирование продукта.
Неоправданное применение паттеров проектирования (если у тебя в руках молоток, то все предметы вокруг начинают напоминать гвозди). Слепое следование методологиям может привести к непредсказуемым результатам, хоть и предполагает изначальную управляемость и предсказуемость (да, парадокс, смиритесь, вспомните сколько компаний и процессов загублено через agile, scrum и т.п.).
Неоправданное применение абстракций. Примеры из жизни:
Сквозные разнородные объекты (сквозная нумерация) в одной общей таблице. Логика работы с конкретным объектом зависит от его типа в поле БД. Таким образом выборка списка людей из общего списка всех объектов (люди, статьи, фильмы) превращается в бесконечную фильтрацию и соединения с таблицами свойств, значений. А так же в жёсткое кодирование на основе "волшебных значений". Пример такой таблицы DAP (Active Directory, LDAP).
Иерархия:
монетки в кошелёчке, кошелёчек в шкатулочке, шкатулочка в сумочке, сумочка в корзиночке, корзиночка в сундучке, сундучок в контейнере - и каждый из объектов реализован в виде отдельной таблицы в реляционной БД или в древоподобной структуре (как в MondoDB). Как только иерархия меняется, сразу требуется колоссальное количество человеко-часов для переделки ПО и переноса данных. Если система ещё и под постоянной нагрузкой, то...
переход по большому количеству вложенных объектов (меню, адреса)
Слишком большая проработка функциональности: для изображений попытка создать полноценный графический редактор, для звука создать секвенсор. Ещё нет минимально жизнеспособного продукта, зато есть навороченный редактор. Круто! Молодцы! Но зачем? Потратили время, деньги, силы.
