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

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

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

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

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

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

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

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