С чего началось
Запрос звучал так:
«Мне нужен дубликатор Честного Знака. Навожу камеру на код, система его считывает, и я печатаю несколько таких кодов на принтере.»
Ни личных кабинетов, ни базы данных, ни командной работы. Нужен был прикладной инструмент под одну ежедневную операцию: считать код маркировки и напечатать нужное количество дубликатов.
Задача понятная и узкая. Ровно из таких чаще всего и вырастают системы — просто об этом никто не догадывается в момент постановки.
Почему мы не стали писать ТЗ
По такому описанию можно написать техническое задание на сто страниц и промахнуться целиком. Пока человек не увидел работающий сценарий, он не знает, что ему действительно нужно, — и это не его вина, а свойство задачи. Требования живут не в голове заказчика, а в его руках: они появляются, когда есть что потрогать.
Отсюда и подход к деньгам. По сырому описанию нельзя назвать честную фиксированную цену — можно только угадать, а потом добирать допами за всё, что «не входило». Поэтому мы сначала проверили сценарий технически, а смету назвали тогда, когда стал понятен объём.
Прототип за один день
Мы не стали начинать с проектирования. Взяли самый узкий вопрос — получится ли вообще надёжно считать код с фотографии и подготовить его к печати — и ответили на него кодом.
Сервис на JavaScript: принимает снимок кода Честного Знака, распознаёт его, преобразует в формат, пригодный для печати. Упаковали в Docker, добавили минимальный интерфейс, настроили вывод на принтер.
- 1Пользователь фотографирует или загружает код маркировки
- 2Система распознаёт код
- 3Пользователь указывает количество копий
- 4Сервис готовит этикетки
- 5Коды уходят на принтер
На это ушёл один день. Не потому, что мы быстро пишем код, а потому что проверяли одну гипотезу, а не строили продукт. Прототип не умел ничего, кроме главного сценария, — и именно поэтому появился на следующий день, а не через месяц.
Что показал прототип
Заказчик увидел, как это работает вживую, — и требования посыпались.
Ни один из этих пунктов не появился бы в ТЗ, написанном заранее. Они появились, потому что человек подержал в руках работающий сценарий и понял, чего ему не хватает.
Итоговое техническое задание
Только после этого мы сели за ТЗ — и оно опиралось на увиденное, а не на предположения. В нём зафиксировали: пользовательские сценарии · способы считывания кодов · логику создания дубликатов · требования к печати · веб-интерфейс · мобильный сценарий · приложение для Windows · редактор этикеток · командную работу · хранение в базе данных · серверное развёртывание · структуру взаимодействия компонентов.
Вместо отдельного скрипта была спроектирована архитектура полноценного продукта.
Архитектура — и самое дорогое решение в ней
Контейнерная архитектура позволила разделить функции, упростить развёртывание и обновлять компоненты независимо друг от друга.
Самым дорогим решением оказалась авторизация и личный кабинет
Дубликатору авторизация не нужна вообще: открыл, считал, напечатал. Как только появляются несколько устройств и несколько сотрудников, всё переворачивается. Нужно понимать, кому принадлежат коды и шаблоны, разделять данные между аккаунтами, разграничивать доступ внутри команды — и делать это одинаково в четырёх местах сразу: в вебе, на станции у принтера, в мобильном приложении и на лендинге.
Именно здесь проект перестал быть инструментом и стал системой. Отсюда единый бэкенд для всех клиентов вместо четырёх самостоятельных приложений: разделять данные по аккаунтам и вести общую историю печати можно только там, где идентификация одна на всех. При раздельных хранилищах эта логика не работает в принципе.
Что получилось
Итоговый состав: распознавание кодов · печать дубликатов · работа с телефона · веб-интерфейс · приложение для Windows · редактор этикеток · командная работа · хранение данных · история операций · серверная инфраструктура · публичный лендинг.
Сроки и стоимость
Прототип был готов за один день — до всяких договорённостей о цене.
После согласования ТЗ заключили договор. Первая версия вышла примерно через неделю: значительная часть логики уже была проверена на прототипе, поэтому неделя ушла на доводку согласованного объёма, а не на разработку с нуля.
- серверная часть (бэкенд)
- веб-сервис и сайт
- система работы с кодами маркировки и хранение данных
- подготовка этикеток к печати
- MVP мобильного приложения
- MVP приложения для Windows
- развёртывание и запуск
Систему развернули на наших серверах и передали заказчику доступ к готовому сервису.
Продукт не остался в состоянии сдачи
После запуска заключён договор на техническое обслуживание и доработки — система продолжает развиваться. Появились тарифные планы, командный режим, серийный учёт партий и агрегация.
Разница между «сдали проект» и «ведём продукт» именно в этом: первое заканчивается актом приёмки, второе живёт и меняется вместе с задачами бизнеса.
Итог
Проект начинался с одной узкой функции: считать код камерой и напечатать копии. Вырос в сервис с редактором этикеток, серийным учётом, историей печати и работой на четырёх устройствах.
Но главный результат — не приложение, а порядок работы. Сначала прототип, потом требования, потом смета. В этой последовательности заказчик платит за то, что видел, а не за то, что описал словами.