commerce

Как написать техническое задание на разработку

Во сколько клиенту может обойтись плохо составленное ТЗ

Клиент

Наша веб-студия получила заказ на разработку b2b-платформы для вендоров и покупателей холодильного оборудования и кондиционеров. Поставщики могут наполнять её контентом в рамках бесплатного пакета: добавлять в каталог свою продукцию, публиковать статьи, рассказывать об услугах и искать клиентов и исполнителей. Мы разработали сайт и внедрили в его работу фреймворк Drupal Commerce. Как итог, фреймворк оказался лишним. 

разработка b2b-платформы

Как так получилось?

Клиент попросил помимо прочего настроить на сайте функциональность для подписки. Подписка расширяет бесплатный пакет и даёт пользователям дополнительные возможности: публиковать больше статей, прикреплять больше файлов, выставлять объявления о работе.

В техзадании было указано, что информация о запросе на подписку должна собираться на стороннем сервисе Lexoffice. Однако клиент не уточнил, с помощью какого инструмента функциональность должна быть реализована на стороне самого сайта. Основываясь на опыте прошлых проектов, мы решили использовать для этой цели Drupal Commerce. После установки последовали вопросы от клиента: зачем на сайте появился checkout и так далее.

Роль Drupal Commerce

По ходу работы начали выясняться подробности, которых как раз не хватало в ТЗ. Оказалось, что оплата подписки у клиента проводится через сторонний сервис. Вот как выглядит процесс: юзер выбирает план, нажимает Submit, данные собираются из формы регистрации или из профиля, отправляются в стороннее API для проверки налоговой информации и уже потом в Lexoffice. Владелец сайта видит в админке Lexoffice заказ и направляет клиенту инвойс, который он оплачивает через банк.

реализация подписки на сайте

Однако подписки в Commerce могут оплачиваться только непосредственно на Drupal-сайте, то есть модуль не может обработать такой кейс. По умолчанию в нём нет даже возможности оформить подписку. Получается, что Drupal Commerce используется только для того, чтобы хранить условия планов, заводить заказы и отправлять их в Lexoffice. Оплата же проходит через другой сервис. Как результат, эквайринговая функциональность Commerce здесь не нужна, достаточно простого Drupal.

Что можно было сделать лучше

Подписку можно было бы организовать на сайте быстрее, не прибегая к дополнительным Drupal-модулям. Мы потратили много времени на интеграцию с Lexoffice (около 80 часов) из-за непроработанной документации площадки. Еще 40 часов ушло на изменение сущностей Orders в Drupal Commerce. Без модуля мы бы за 20 часов написали какой-нибудь кастомный сервис, который отправлял бы заказ в платёжный сервис.

Но Drupal Commerce может еще пригодится на этом сайте! Клиент рассматривает расширение его функциональных возможностей, например, опцию публикации 10 объявлений за дополнительную плату. В таком случае модуль будет использоваться по прямому назначению.

olga rogaleva
Ольга Рогалева

Редактор, SEO-специалист, контент-райтер

Напишите нам!

Мы регулярно просматриваем не только почту, но и спам. Ваша заявка от нас не ускользнёт.

Напишите нам!

Но сначала правильно заполните обязательные поля.