Вступление и пример плохого анализа

-- Вступление --

Всем привет. Мне показалось не очень удобным писать здесь тексты (особенно редактировать) и времени мало на них. Основная работа все таки не блоги вести (и опыт первый). Поэтому буду писать кратко, возможно кому-то будет непонятно - комменты пишите, заинтересованным в раскрытии темы. Если развернуть тему мне еще не "по знаниям" - так и отвечу.

Большая только просьба (жаль заскролится со временем) - не устраивать "холиварные войны", в них нет смысла. Все задачи можно решить множеством путей и укаждого разработчика он свой. Результат оценки заказчиком - критерий правильно выбранного пути - этот критерий нам здесь не увидеть. Поэтому мнение сказать отлично, но устраивать "войну" смысла нет.

Какие-либо большие, сложные тексты, мысли, схемы - скорее всего будут оформляться в других сервиса, а здесь краткая инфа и ссылка. Но, как видите, редко, мало времени. В этом "обществе" нет запрета на публикацию участниками - но, только по теме.

--- Первый краткий пример плохого анализа ---

Весь проект строится крайне срочно (даже срачно, по качеству). Экономить стараются конечно же - на анализе. После такого анализа все задачи надо сделать "еще вчера", ведь уже "все написано". Наверно многим знакомая ситуация, наверно с обеих сторон да? ;)

Структура БД - необоснованные нарушения нормализации с отмазкой - так быстрее, мы так решили, нам так лучше. И ничего конкретного с точки зрения литературы и здравого смысла, практического обоснования.

Поверх проблем нормализации поленились определить необходимость уникальных индексов. Т.е. анализ потока данных и самих данных - необходимость защитить их актуальность, избыточность и т.п. - не проведен.

В итоге спустя 2 года проекта при решении простой задачи которую надо решить за 1 час. Получаем наличие дублей, невозможность решить проблему быстро. Появляется задача на устранение дублей, с условиями не нарушения логики, зависимостей с другими системами (данные уходят туда, как оказалось). Над этой задачей уже подумали 3дн, и то из-за большого количества проблем. И то, потому что разработка устала от таких задач и вернула в анализ с требования описать "что надо сделать".

Разработка заняла еще 6 дней дополнительно.

Итого на исправление проблемы ушло - 9дн (3 анализ + 6 разработка).

В самом начале пути когда продумывали архитектуру таблиц, даже не смотря на нормализацию, если бы потратили 30 минут на продумывание возможных кортежей записей в таблице - пришли бы к выводу о необходимости уникального индекса. И вся проблема была бы решена за 30 минут.

-- Итог -- Не экономьте на анализе, не экономьте на хороших аналитиках с аналитическим складом ума. Не экономьте на описании задач и документировании системы. Хорошо решенные задачи чаще - 80% времени надо думать и 20% писать код (закон Парето, правило 80/20). Думают над проектом впервую очередь проектный офис, затем аналитики. Потом задача уходит в разработку. Поэтому когда вы в компании видите что на задачу тратится 5 часов, а на разработку 14 дней - пора бы задуматься почему так происходит и как это равезрнуть в обратную сторону (ну или влучшую сторону). Но возможно все вопрядке, такая задача попалась. Если такая судьба постигает большую долю задач - однозначно стоит пересмотреть детально процесс.