Мифы о легкой смене подрядчика

Миф первый.

Часто от коллег, делающих решения для сайтов на основе готовых систем управления контентом, можно услышать фразы вида:

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

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

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

Миф второй.

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

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

Не помогут.

Объясняю. Никем еще не было выработано стандартов приложений для веб. Нет стандартов API(хотя у всех есть сам API), нет стандартов на тему того, какие компоненты и как должны работать на корпоративном сайте некой абстрактной компании. Открытые CMS вовсю грешат этим. Нет документов, регламентирущих архитектуру проекта, нет проектной стандартизации, нет рекомендаций, как писать модули к системе так, чтобы они были портируемы под следующие версии CMS наиболее простым способом. Как правило документ по портированию модулей появляется с выходом новой мажорной ветки(что впрочем верно и для коммерческих продуктов тоже).

Соответственно, и договоренностей как вести разработку в рамках одной CMS среди разных независимых разработчиков - НЕТ. Соответственно, если Вы не озаботились вопросом, кто будет поддерживать купленное и настроенное решение в нормальном рабочем виде – не надейтесь, что в случае возникновения проблем вы сможете решить их быстро и своевременно.

Выводы

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