Кастомный модуль: когда готового решения под вашу задачу нет

Прозрачные этапы с согласованием на каждом шагу

Общий срок:5–30 дней

1. 1

   Разбор задачи и техническое описание

   1–4 рабочих дня

   Слушаем задачу вашими словами, проверяем, закрывается ли она готовым решением, и раскладываем по точкам вмешательства. На выходе — документ, согласно которому считается смета и принимается работа.

2. 2

   Тестовая площадка и карта вмешательств

   1–2 рабочих дня

   Поднимаем копию боевого сайта с теми же расширениями. Здесь же составляется список мест, куда модуль добавляет свое поведение, и список расширений, которые в этих местах уже работают.

3. 3

   Разработка

   1–15 рабочих дней

   Пишем модуль событиями платформы и модификаторами, кладем в Git. Настройки в админке, обработка ошибок и журнал действий появляются вместе с основной логикой, а не дописываются в конце.

4. 4

   Проверка сценариев и совместимости

   1–6 рабочих дней

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

5. 5

   Установка, документация, передача

   1–3 рабочих дня

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

Полный перечень работ и того, что вы получаете на выходе

• Техническое описание задачи, согласованное до старта: в нем написано и что модуль делает, и чего он намеренно не делает — именно этот документ затем закрывает спор о границах работы
• Реализация событиями платформы и модификаторами, без правок в файлах ядра – чтобы магазин можно было обновлять дальше, а не замораживать на версии без поддержки
• Настройка модуля в админке: поведение меняет ваш менеджер, а не разработчик по отдельному счету
• Проверка совместимости с уже установленными расширениями на копии боевого сайта — конфликты видны до запуска, а не через месяцы, когда их никто уже не свяжет с модулем
• Обработка ошибок и понятные сообщения вместо молчаливого сбоя: покупатель видит, что пошло не так, менеджер видит то же в админке
• Логирование действий модуля в отдельную таблицу или файл — когда что-нибудь случится, разбор начинается с журнала, а не с гадания
• Код в Git с понятной структурой и комментариями: история перемен остается у вас и дает возможность откатиться
• Документация: что делает, как настраивается, куда смотреть при проблемах – чтобы модуль мог подхватить другой разработчик
• Установка на боевой сайт с возможностью отключить модуль без последствий для магазина
• Передача выходников вам – модуль ваш, а не наш, и лицензии на него мы не продаем
• Условия: оплата по этапам, гарантийный срок 30 календарных дней на выполненные работы

Ситуации, в которых эта услуга даёт результат

Бесплатный разбор задачи под модуль

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

Что мы измеряем

• Есть ли готовое решениеМы проверяем, закрывается ли задача штатными средствами платформы или расширением. Если да — мы это скажем, даже если это означает, что заказывать у нас нечего.
• Точки вмешательстваВ скольких местах платформы модуль должен что-то изменить: карточка, каталог, корзина, чекаут, админка, обмен данными. Это главная составляющая сметы.
• Конфликты с имеющимися модулямиНе пересекается ли задача с тем, что уже стоит. Два расширения, которые правят одно и то же место — источник ошибок, выявляемых за месяцы.
• Состояние кода вокругСколько поправок в ядре уже сделано. Для ориентира: в измеренном нами оптовом магазине карту сайта генерировал сторонний модуль, который по стандартным адресам отдавал либо пустое тело, либо строку о собственном отключении — рабочая карта лежала на нестандартном адресе и держалась только записью в robots.txt.
• Кто это будет сопровождатьНужна ли возможность передать модуль другому разработчику. Это влияет на требования к документации и способу реализации.
• Срок жизни задачиТо ли это разовая потребность, то ли функция, которая будет жить годами. Разовые задачи часто дешевле решить иначе, чем модулем.

Почему две одинаковые на вид задачи считаются по-разному

• Количество точек вмешательстваГлавная составляющая сметы. Добавить поле в карту – одно место. Считать доставку по собственной формуле – карточка, корзина, чекаут, админка, печатные формы и обмен с перевозчиком. Трудоемкость разнится на порядок.
• Касается ли модуль денегРасширение, изменяющее цену, скидку или сумму заказа, требует проверки сценариев: гость и зарегистрированный, купон поверх скидки, возврат, частичная оплата. Большая часть времени идет на проверку, а не на написание кода.
• Обмен с внешней системойЕсли модуль ходит в чужой API, к работе прилагается все, что делается на случай молчания другой стороны: очередь, повторы, журнал, поведение магазина, когда ответа нет вообще. Документация внешней системы нужна на старте – без нее оценка будет выдумкой.
• Состояние кода вокругМагазин, в котором ядро ​​уже правили руками, дороже: каждую точку вмешательства сначала проверяем на то, что там уже изменено. Это видно на разборе и попадает в смету отдельной строкой, а не всплывает посреди работ.
• Сколько вынести в админкуКаждая настройка, которую вы сможете менять сами, – это форма, валидация и проверка. Дороже на старте, дешевле в эксплуатации. Выносить все подряд – тоже ошибка.
• Версия платформыВ четверке OpenCart переписали систему событий и код под 3.x туда не переезжает дословно. Планируете обновление версии – учесть это нужно до разработки, а не после.

Без этого не начнём — лучше подготовить заранее

1. 1Описание задачи своими словами, с примерами того, как оно должно работать и что вы будете считать правильным результатом.
2. 2Доступы: админка, файлы, база, тестовая площадка или разрешение поднять его нам.
3. 3Перечень уже установленных расширений, включая те, которые когда-то поставили и забыли выключить.
4. 4Документацию внешних систем, с которыми модуль будет обмениваться данными, и ключи к тестовому контуру.
5. 5Одного человека с вашей стороны с правом согласовать техническое описание и принять работу.

Если чего-то из этого нет — скажите, подскажем, как собрать или сделаем сами отдельной задачей.

Что обычно берут вместе с этой задачей

• Доработка чужого магазина: беремся за код, который писали другие — сроки и условия
• Обновление версии OpenCart
• Импорт прайсов: каталог, который наполняется сам — сроки и условия
• Личный кабинет: чтобы постоянный клиент не писал менеджеру
• Фильтр и поиск: чтобы покупатель дошел до товара в каталоге на тысячи позиций