Причины

• Нет чёткой цели

• Нет чётких задач, которые решает проект в процессе работы

• Сильное погружение в проработку незначительных деталей

• Отказ от поддержки минимально жизнеспособного продукта (тот самый случай, когда проработка функциональности бежит дальше, чем основной скелет продукта)

• Выбор неправильных инструментов

• Когнитивные искажения

План действий

Для этого понадобится карандаш и бумага

1. Цели

Цель определяет итог, но не определяет способы его достижения. Определите список достигаемых проектом целей. Что в будет в итоге? Собственно зачем мы все здесь собрались?

2. Задачи

Действия, направленные на достижения поставленных целей. Определите список решаемых в процессе задач. Что нужно делать, чтоб добраться до цели?

3. Требования

Свойства, которыми обладает конечный результат. Бизнес-требования, технические требования, пользовательские требования. Обязательно проработайте оценку важности требований.

4. Роли

Определяем список задействованных прямо или косвенно ролей: людей, групп, прав, обязанностей, ответственности.

5. Компоненты и компоновка

Список составных частей исследуемого объекта. Возможно это абстрактные модули и схемы сборки и взаимодействия.

6. Минимально жизнеспособный продукт

Не путать с прототипом. Примеры минимально жизнеспособных продуктов: лом, кувалда. Это продукт с минимальным набором функций, но достаточный для решения основных поставленных задач и достижения главных целей.

7. Инструменты

Если для проекта собрана команда, но при этом нужна как минимум ещё одна команда, которая будет обслуживать платформу, то явно что-то идёт не так.

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

8. Детали реализации

Основные сущности, архитектура, пользовательские интефейсы, документирование кода, документирование продукта.

Неоправданное применение паттеров проектирования (если у тебя в руках молоток, то все предметы вокруг начинают напоминать гвозди). Слепое следование методологиям может привести к непредсказуемым результатам, хоть и предполагает изначальную управляемость и предсказуемость (да, парадокс, смиритесь, вспомните сколько компаний и процессов загублено через agile, scrum и т.п.).

Неоправданное применение абстракций. Примеры из жизни:

• Сквозные разнородные объекты (сквозная нумерация) в одной общей таблице. Логика работы с конкретным объектом зависит от его типа в поле БД. Таким образом выборка списка людей из общего списка всех объектов (люди, статьи, фильмы) превращается в бесконечную фильтрацию и соединения с таблицами свойств, значений. А так же в жёсткое кодирование на основе "волшебных значений". Пример такой таблицы DAP (Active Directory, LDAP).

• Иерархия:

  • монетки в кошелёчке, кошелёчек в шкатулочке, шкатулочка в сумочке, сумочка в корзиночке, корзиночка в сундучке, сундучок в контейнере - и каждый из объектов реализован в виде отдельной таблицы в реляционной БД или в древоподобной структуре (как в MondoDB). Как только иерархия меняется, сразу требуется колоссальное количество человеко-часов для переделки ПО и переноса данных. Если система ещё и под постоянной нагрузкой, то...

  • переход по большому количеству вложенных объектов (меню, адреса)

Слишком большая проработка функциональности: для изображений попытка создать полноценный графический редактор, для звука создать секвенсор. Ещё нет минимально жизнеспособного продукта, зато есть навороченный редактор. Круто! Молодцы! Но зачем? Потратили время, деньги, силы.