Рассмотрим несколько типовых ошибок, которые совершают при проектировании больших проектов.

Ошибка "Вроде работает"

Частая ошибка начинающих студий.

За разработку берутся в общем профессиональные, но не знакомые с Bitrix Framework студии, в надежде освоить систему "по ходу". Слабое знание системы привело к тому, что написана часть функционала, которая, как потом оказалось, уже имеется в Bitrix Framework. Часть функционала показалась разработчикам "плохо" реализованной и её переписали "лучше чем в Битрикс". В последствии выяснилось, что переписанный функционал завязан на другие опции в системе. Кроме того функционал был переписан с модификацией ядра, прямыми обращениями к БД и другими стратегическими ошибками.

Результат: клиент не может управлять сайтом через стандартную админку, управление осуществляется через код, модифицированное ядро при обновлении затёрто, сайт "сломался". Уходит много времени на исправление, клиент "рвёт и мечет".

Ошибка "Информационный сайт. Много данных в каталогах"

Ошибка в постановке задачи. На этапе ТЗ не отмечен факт большого числа инфоблоков и данных в них. В результате при разработке реализована неоптимальная работа с инфоблоками через АПИ. При этом, не подумав, выбрали виртуальных хостинг.

Как следствие, после загрузки данных все стало тормозить. Попытались везде внедрить кэширование – время генерации кэша > 30 секунд. Сроки - сорваны.

Ошибка "Зачем делать просто, если можно сложно? Или горе от ума."

Одна из "ошибок роста" для веб-студии. После нескольких удачных проектов возникает ощущение, что "мы можем всё". В результате решили сделать значительно "сложнее", чем нужно по ТЗ. При этом Использовали свои таблицы в БД, а после запуска обнаружили многочисленные уязвимости типа SQL Injection.

В последствии пришел новый программист и не смог распутать решение - начал переписывать. Развивать проект получается дорого.

Ошибка "Не проектировали"

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

Сложная предметная область при дефиците времени. Экономим на проектировании, надеясь на свой профессионализм. После 50% времени реализации, оказалось что нельзя добавить новое требование. Дальше возникают новые требования и новые проблемы. Проект переписывали раза 3, "Костыль на костыле" - сложно и дорого развивать.

Ошибка "Гипер-формализация"

Обжегшись на предыдущей ошибке некоторые веб-студии начинают перестраховываться.

Опять сложная предметная область, проектировали 3 недели. Получили: 10 диаграмм, 50 Use Cases, прототипы и так далее. Требования «немного» изменились и необходимо менять проекты. На внесение изменений в артефакты проектирования ушло 2 недели. Сроки летят.

Ошибка в работе с заказчиком: "Заказчик сам не знает чего хочет"

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

Как правило это клиент из специфической предметной области. Заказчик в ней слабо разбирается, экспертов нет. Времени на проектирование выделили мало. В результате приходится многократно переписывать части проекта и, как следствие взаимные претензии к клиенту и от клиента.

Ошибка "Запутались"

В больших проектах существует риск управленческих ошибок.

Объемное ТЗ - большая нагрузка на менеджера проекта. Он начал терять требования и запутываться, что порождает взаимные претензии с Заказчиком. Разработчики вынуждены переписывать части веб-системы, в результате получился – "костыль на костыле". Проект дорого и сложно развивать