Более половины проектов нашего отдела веб разработок связаны с модернизацией уже существующих сайтов. В целом эффективность процессов модернизации и качество результата зависит в большей степени от квалификации подрядчика, а рекомендации как не ошибиться в выборе мы написали в отдельном материале, и далее уже исходим из того, что подрядчик выбран, описываем ситуации из своего опыта.
Если сайт простой, то и его модернизации обычно не бывают сложными, но для крупных e-commerce проектов, на разработке и модернизации которых мы специализируемся, очень важна правильная постановка задач и планирование процесса. Рассмотрим основные подводные камни и рекомендации как их обойти.
1. Отсутствие установочного этапа аналитики проекта
Казалось бы, если мы разработали сайт, то мы лучше всех его знаем, поэтому можем "с ходу" описать все изменения, в короткий срок и не тратя много ресурсов. На самом деле, нужно учитывать, что поток проектов, который проходит через агентство, достаточно большой, поэтому даже ваш персональный менеджер через 3-4 месяца после запуска вашего сайта уже не помнит в мелочах детали его работы и алгоритмы. Иногда такие детали касаются незначительных функций, но сказываются на работе большой части функционала.
Пример: перевод обмена данными при заказе с асинхронной механики xml файлов (создали заказ -> положили xml файл в специальную папку) на онлайн интеграцию через API: при создании заказа проверяются остатки, и заказ создается, если выполнен ряд условий (в том числе наличие товара). В xml файле заказа передавался id заказа, так как заказ физически создавался до того как генерировался файл. В онлайн интеграции процесс обратный: сперва заказ создается в учетной системе при выполнении условий, а потом он создается в админке сайта (иначе не будет возможности обрабатывать ошибки API и ошибки выполнения условий, сохраняя корзину заказа). Таким образом, id заказа для передачу в учетную систему появляется уже после того как заказ создается в учетой системе, то есть, процесс обмена данными должен быть 2х-ступенчатым. Если не рассмотреть механику обмена данными в сравнении с текущей версией и не рассмотреть все передаваемые данные, то очень легко допустить ошибку, которая приведет к тому, что в учетной системе не будет необходимых данных для обработки заказа (в нашем примере id заказа с сайта).
2. Нечеткие формулировки изменений для существующих модулей сайта
Очень часто постановка задач по модернизации бывает не достаточно четкой и детализированной. Обычно формулируют новый функционал, опуская описание того что работает в данный момент. Это ошибка, так как на этапе постановки задачи вы не заметите подвоха, а на этапе реализации может выясниться, что некоторые новые функции приводят к неработоспособности ранее реализованных, которые менять было не нужно.
Пример: модернизация модуля поиска товаров в Интернет магазине. Поиск выводил разделы каталога, при клике на раздел выводились найденные в конкретном разделе товары; требовалось вывести все найденные товары единым списком без деления на разделы. Результаты выводятся в виде таблицы с сортировками по столбцам. Особенность задачи в том, что при реализации новой версии поиска результатов становится на порядок больше, поэтому нужно учитывать производительность поискового движка. В частности, если реализовать задачу "в лоб", то может получиться неработоспособный сервис, поиск будет зависать, также будут проблемами с перестройкой результатов при смене сортировки. Таким образом, в постановку задачи требуется добавить пояснения и дополнения, учитывающие реализованный механизм работы поиска. В частности, необходимо прописать дополнительный функционал пагинации, а также по возможности отказаться от сортировки по вычисляемым столбцам (остаток на складе, цена со скидкой итд). В этом случае новый поиск будет не только более удобным, но и производительным.
3. Выполнение работ по ТЗ Заказчика
Самой грубой ошибкой мы считаем планирование работ по ТЗ Заказчика, так как это означает одновременные "грабли" вышеописанных пунктов 1 и 2, а также и другие проблемы, связанные с неявными задачами, которые являются очевидными следствиями, подразумеваются, но не всегда озвучиваются. Мы часто видим, что Заказчик старается минимизировать бюджет модернизации, берет на себя часть установочного этапа, но не может выполнить его с нужным качеством, так как не является профессиональным разработчиком. В результате все риски все равно лягут на Исполнителя, который принял в работу такое ТЗ. Не все понимают, что анализ и вычитывание ТЗ, как правило, сложнее для Исполнителя, чем написание его с нуля своими силами.
Пример: Заказчик описывает правки верстки сайта без учета мобильной и планшетной версий. Если Исполнитель не вспомнит, что в адаптивной концепции был реализован какой-то сложный функционал адаптива, то выполнит правки без оглядки на адаптивы, и таким образом, мобильная и планшетная версии сайта могут оказаться неработоспособными.
Выводы
Модернизация сайта - более сложная услуга, чем разработка нового сайта, поэтому она требует более высокой квалификации исполнителя. Чтобы избежать ошибок и сбоев, к постановке задач модернизации сайта нужно относиться максимально серьезно и уделять этому повышенное внимание.