Дата последнего изменения: 23.09.2021
Рассмотрим несколько типовых ошибок, которые совершают при проектировании больших проектов.
Частая ошибка начинающих студий.
За разработку берутся в общем профессиональные, но не знакомые с Bitrix Framework студии, в надежде освоить систему "по ходу". Слабое знание системы привело к тому, что написана часть функционала, которая, как потом оказалось, уже имеется в Bitrix Framework. Часть функционала показалась разработчикам "плохо" реализованной и её переписали "лучше чем в Битрикс". В последствии выяснилось, что переписанный функционал завязан на другие опции в системе. Кроме того функционал был переписан с модификацией ядра, прямыми обращениями к БД и другими стратегическими ошибками.
Результат: клиент не может управлять сайтом через стандартную админку, управление осуществляется через код, модифицированное ядро при обновлении затёрто, сайт "сломался". Уходит много времени на исправление, клиент "рвёт и мечет".
Ошибка в постановке задачи. На этапе ТЗ не отмечен факт большого числа инфоблоков и данных в них. В результате при разработке реализована неоптимальная работа с инфоблоками через АПИ. При этом, не подумав, выбрали виртуальных хостинг.
Как следствие, после загрузки данных все стало тормозить. Попытались везде внедрить кэширование – время генерации кэша > 30 секунд. Сроки - сорваны.
Одна из "ошибок роста" для веб-студии. После нескольких удачных проектов возникает ощущение, что "мы можем всё". В результате решили сделать значительно "сложнее", чем нужно по ТЗ. При этом Использовали свои таблицы в БД, а после запуска обнаружили многочисленные уязвимости типа SQL Injection.
В последствии пришел новый программист и не смог распутать решение - начал переписывать. Развивать проект получается дорого.
Ошибка самоуверенности. Возникает после продолжительной и успешной работы студии, когда научились обходить все вышеописанные ошибки.
Сложная предметная область при дефиците времени. Экономим на проектировании, надеясь на свой профессионализм. После 50% времени реализации, оказалось что нельзя добавить новое требование. Дальше возникают новые требования и новые проблемы. Проект переписывали раза 3, "Костыль на костыле" - сложно и дорого развивать.
Обжегшись на предыдущей ошибке некоторые веб-студии начинают перестраховываться.
Опять сложная предметная область, проектировали 3 недели. Получили: 10 диаграмм, 50 Use Cases, прототипы и так далее. Требования «немного» изменились и необходимо менять проекты. На внесение изменений в артефакты проектирования ушло 2 недели. Сроки летят.
Будучи уже опытными разработчиками, отлично знающими систему и успешно научившись обходить ошибки, связанные с собственным ростом, когда-то всё равно встретятся с такими клиентами.
Как правило это клиент из специфической предметной области. Заказчик в ней слабо разбирается, экспертов нет. Времени на проектирование выделили мало. В результате приходится многократно переписывать части проекта и, как следствие взаимные претензии к клиенту и от клиента.
В больших проектах существует риск управленческих ошибок.
Объемное ТЗ - большая нагрузка на менеджера проекта. Он начал терять требования и запутываться, что порождает взаимные претензии с Заказчиком. Разработчики вынуждены переписывать части веб-системы, в результате получился – "костыль на костыле". Проект дорого и сложно развивать