Когда услуга продаётся вручную, масштаб упирается в людей: менеджер сам выгружает данные, сам выставляет счёт, сам отправляет результат. Хотите обслуживать в десять раз больше клиентов — нанимайте в десять раз больше менеджеров. Либо переводите услугу на самообслуживание. DocMarket задуман как этот второй путь: ручная услуга превращается в отдельный сайт с автоматической оплатой и личным кабинетом.
Сводка
| Отрасль | Сертификация продукции, B2B-логистика |
| Конечный клиент | «Аналитика сертификатов» (новый продукт в линейке) |
| Формат сотрудничества | Прямой ТЗ под отдельностоящий новый продукт |
| Тип проекта | Минимальная версия веб-сервиса самостоятельной продажи выгрузок данных из реестров сертификации |
| Объём минимальной версии | Регистрация, личный кабинет с реквизитами, предварительная фильтрация со скрытыми чувствительными полями, оплата по счёту и картой, промокоды, автоматическая выдача результата, уведомления, интеграция с основной базой платформы на чтение |
| Дата проекта | 19 марта 2026 — на согласовании у заказчика |
| Трудозатраты | не оцифрованы — в ТЗ заложен этап аналитики, после которого выставляются часы |
| Команда | Антон Херсун (руководитель проекта). Исполнитель определяется — рассматриваем разработчика основной платформы и разработчика виджетов/парсеров, выбор зависит от того, как ляжет техническая интеграция |
| Технологический стек | Отдельный веб-сервис (вероятно Laravel, как остальное) · интеграция с основной базой на чтение · собственная БД пользователей и заказов · эквайринг и оплата по счёту · личный кабинет с регистрацией по телефону и почте |
| Состояние | Финальное ТЗ (tz37_docmarket_mvp_final.docx) передано 26.03.2026; заказчик взял на согласование, дальнейшего хода в переписке нет |
Постановка задачи
У клиента уже работает ручная услуга: менеджеры выгружают данные из реестров сертификации для российских логистов. Логисты используют чужие документы сертификации по номеру без доверенности, и это легально по постановлению. Спрос есть и подтверждён на отраслевой выставке логистов. Проблема в другом: у разных менеджеров разные критерии выгрузки и разные цены. Контролировать такое сложно, масштабировать — ещё сложнее.
DocMarket собирается как отдельностоящий веб-сервис, который автоматизирует процесс. Формат заказчик обозначил сразу: не полноценная платформа целиком, а минимальная рабочая версия с возможностью расширения. Ядро минимальной версии:
- Регистрация по телефону или почте с подтверждением.
- Личный кабинет: профиль, реквизиты компании, история покупок с повторным скачиванием.
- Предварительная фильтрация по реестрам с ограниченной видимостью результата, доступная без авторизации, чтобы привлекать клиентов.
- Оплата на сайте: по счёту для юрлиц и ИП, картой для физлиц; промокоды.
- Автоматическая выдача полной выгрузки после подтверждения оплаты, уведомления в кабинете и на почту.
Что в этом сложного. Самое уязвимое место самообслуживания поверх реестровых выгрузок: показать клиенту достаточно, чтобы он понял ценность, и не дать достаточно, чтобы он нашёл данные сам. Покажешь в предпросмотре полные номера и даты, и клиент уйдёт искать в открытый реестр, ничего не купив. Скроешь всё, и он не поймёт, что внутри, и не оплатит. Баланс «показать структуру, скрыть идентификаторы» — центральное продуктовое решение, а не технический патч, и согласовать его с заказчиком надо до начала разработки.
Как мы это сделали (на текущем этапе)
1. Финальное ТЗ как итог созвона с заказчиком 19 марта 2026.
Устные договорённости теряются за неделю, поэтому формат «созвон → концепт → ТЗ» мы держим жёстко. Заказчик сначала прислал концепт-документ (Проект - DocMarket.docx), созвон прошёл в Телемосте, и за неделю после него собрали финальное ТЗ (tz37_docmarket_mvp_final.docx, передано 26.03.2026). Запись встречи — единственный способ через месяц вспомнить, почему в ТЗ вошло именно это, а не другое. Дисциплина простая: концепт фиксируем на бумаге, обсуждаем голосом, сводим в одно ТЗ, а не «давайте начнём кодить».
2. Граница минимальной версии прочерчена сознательно.
В концепте заказчик описал «идеальную» выгрузку: документ должен быть серийным, действующим по дате, по статусу в национальном реестре (КГ, КЗ, Беларусь), по статусу в реестре ЕАЭС (pub.fsa.gov.ru/reaec/conformityDoc) и по законодательству, а последнее вообще живёт только в постановлениях на бумаге и заносится вручную. Пять условий — это пять разных источников и онлайн-проверок. В минимальной версии оставили два автоматических фильтра: только серийные документы и только действующие по дате. Три проверки статусов уехали во вторую очередь. Так минимальная версия получает рабочий продукт без зависимости от живых внешних реестров, а тяжёлая часть переезжает в следующий этап. Это решение про объём, а не про «сделаем всё сразу».
3. Ограничение видимости в предпросмотре: продуктовое решение, заложенное в архитектуру.
В ТЗ зафиксировано прямо: в предпросмотре номер документа скрыт полностью, от дат остаётся только год, остальные критичные поля помечены «скрыто» или размыты. Конкретный перечень скрываемых полей заказчик определяет на этапе проектирования. Принципиально здесь одно: размытие нельзя «добавить потом». Оно влияет на структуру запросов к базе и на шаблоны рендеринга, поэтому закладывается в архитектуру с самого начала.
4. Личный кабинет с реквизитами компании под выставление счетов.
Бухгалтерия покупателей-логистов не проведёт оплату без счёта с реквизитами: для юрлица это условие сделки, а не удобство. Поэтому в кабинете лежит профиль компании и кнопка «скачать счёт» по любой покупке, а сам счёт собирается автоматически из реквизитов кабинета.
5. Не оцениваем часы, пока не пройдёт этап аналитики.
Строка часов в плане работ оставлена пустой, и это намеренно. DocMarket подключается к основной базе платформы, которая четвёртый год в продакшене, и интеграция идёт строго на чтение: отдельный сайт не должен уметь что-то записать или сломать на проде. Как безопасно выдать такой доступ — решит первый этап аналитики. Второй риск честно вынесен в само ТЗ: сроки подключения эквайринга плавают, потому что у банков разные процедуры тестового и боевого доступа. Называть финальную смету до проработки этих развилок было бы гаданием.
Результаты (текущее состояние)
| Метрика | Значение |
|---|---|
| Часы | не оцифрованы — в плане работ заложен этап аналитики, после которого выставляется оценка |
| ТЗ | Финальная версия tz37_docmarket_mvp_final.docx, передана 26.03.2026 |
| Статус | На стороне заказчика на согласовании; сборка не начата |
| Артефакты | Концепт Проект - DocMarket.docx, созвон в Телемосте 19.03.2026, финальное ТЗ |
Что есть на сегодня: концепт прошёл цикл «концепт → созвон → финальное ТЗ» с письменной фиксацией каждого шага, минимальная версия отделена от перспективной части, опасные места интеграции названы заранее. Дальше идёт этап аналитики под интеграцию с основной базой, после него оценка часов и старт сборки. Решение остаётся за заказчиком.
Процесс и хронология
| Этап | Период | Результат |
|---|---|---|
| Концепт от заказчика | 19 марта 2026 | Проект - DocMarket.docx |
| Созвон с заказчиком | 19 марта 2026 | Обсуждение в Телемосте, запись |
| Финальное ТЗ | 19–26 марта 2026 | tz37_docmarket_mvp_final.docx |
| Этап аналитики | не начат | Анализ БД, схема фильтров, перечень скрываемых полей, оценка часов |
| Сборка минимальной версии | не начата | По согласованному плану |
Команда
- Антон Херсун, Xaver Pro: руководитель проекта, формализация ТЗ, разметка границы минимальной версии
- Исполнитель определяется. Рассматриваем двоих: разработчика основной платформы (он знает базу аналитики изнутри, что снижает риск рядом сломать что-то на проде) и разработчика виджетов/парсеров (если DocMarket окажется ближе по архитектуре к Битрикс-интеграциям). Выбор после этапа аналитики и проработки интеграции с основной базой.
Скриншоты и материалы
Пока пусто: минимальная версия не реализована.
Если планируете перевод ручной B2B-услуги в самообслуживание, поделимся методикой работы по этапам: «концепт → встреча → финальное ТЗ» с письменной фиксацией каждого шага. Покажем, какие развилки бывают между «показать ценность» и «отдать всё». Разбор бесплатный.