Сервис проектов ОВК для проектной организации: предложение

Это работа без единой строки кода сервиса. Рассказываю, как я читал чужое техническое задание, что вынес в предложение и где оставил оговорки.

Задача

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

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

Что я предложил

Предложение построено как путь клиента и отдельный путь инженера.

Клиент. Указывает город и тип объекта, загружает план в PDF, JPG или PNG. Сервис распознаёт текст и координаты, для сканов включает распознавание изображения и показывает таблицу помещений рядом с листом. Клиент сверяет строки, подтверждает масштаб и отвечает на уточнения: высоты, окна, ограждения. Начать можно с одного плана, без регистрации.

Инженер. Видит все проекты под номерами, утверждает исходные параметры, проверяет расчёт и выпускает комплект. Любой проект хранится с версиями. Ранее выпущенный комплект остаётся отдельной записью и не показывается как актуальный.

Статусы. Их четыре: черновик, требуется уточнение, исходные данные подтверждены, выпущен. Каждый переход записывается со временем, версией и основанием. Любое изменение города, геометрии, материала или схемы помечает затронутые результаты устаревшими, снимает подтверждение и запускает пересчёт.

Расчёты. Климат и градусо-сутки по справочнику, теплопотери по ограждениям, подбор секций радиатора, гидравлика по участкам, баланс притока и вытяжки, составляющие охлаждения. Формулы и контрольные значения я взял из их документа и своих не вводил. В предложении расчёты показаны на условном примере из испытаний задания: десять помещений, 117,51 м².

Обмен с AutoCAD. Сервис формирует пакет задания: версия проекта, масштаб, начало координат, точки подключения, нагрузки. Инженер проектирует сети на подложке в AutoCAD и возвращает чертёж и ведомость. Идентификаторы труб общие в чертеже и в таблице, поэтому смена длины запускает пересчёт.

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

Что учёл и где риски

Самое полезное в предложении, на мой взгляд, список оговорок. Их несколько.

• Роли. В техническом задании обе роли названы одним словом. Я прочитал это как клиент и инженер и написал это в документе, чтобы заказчик мог поправить.
• Хранение плана. Исходный файл обрабатывается в браузере и по сети не уходит. На сервере остаются распознанные данные, расчёт и версии, они нужны для корректировок. Передача плана инженеру для AutoCAD идёт отдельным действием с явным согласием клиента.
• Дефицит данных. Если не хватает размера окна, паспорта радиатора или точки подключения, сервис не округляет и не ставит ноль. Он показывает причину и блокирует итог. Сумму по части комнат нельзя выдавать за нагрузку всего жилья, и в макете это написано прямо.
• Качество распознавания. Оно зависит от исходных файлов. Сомнительные значения подсвечиваются для ручной проверки и автоматически не принимаются.
• Методики. Расчёт пола по грунту без отдельной методики блокирует итог комнаты. Города вне справочника инженер обосновывает вручную. Перед выпуском фиксируются редакции применимых сводов правил и стандартов.
• AutoCAD. Модуль работает только в полной версии, в облегчённой он не запустится. Лицензия на стороне заказчика, версию согласуем до старта.
• Ответственность. Инженерную ответственность за выпущенные документы несёт инженер заказчика, сервис её с него не снимает.
• Границы. Жильё больше площади, заданной в документе, идёт на индивидуальную оценку. Онлайн-оплата комплекта в задании не описана, поэтому в объём я её не включил.

Список того, что нужно от заказчика на старте, тоже в документе: каталог приборов с паспортами, правила трассировки, эталонный проект с расчётом, несколько реальных планов в PDF и сканах, инженер на связи для сверки, сервер и домен на стороне заказчика. Я считаю этот перечень частью предложения, потому что без него срок теряет смысл. По той же причине я делаю разведку перед проектом.

В каком статусе

Предложение ушло заказчику в личные сообщения в тот же день, когда пришло задание. Я спросил, на какой бюджет ориентироваться, и жду ответ. Сервис не написан, договора нет, в проде ничего нет. Макеты экранов собраны на демонстрационных данных. Это материал для разговора, и выдавать его за работающий продукт нельзя.

Три варианта по объёму устроены так:

• Вариант 1, расчётная часть. Проект и файлы, распознавание, сверка помещений, климат, теплопотери, подбор радиаторов, отчёт и список уточнений, статусы, версии, кабинет инженера.
• Вариант 2, сайт и все расчёты. Всё из первого плюс разметка сетей на плане, гидравлика, вентиляция, охлаждение и ведомость материалов.
• Вариант 3, полный объём. Всё из второго плюс локальный модуль для AutoCAD с общими идентификаторами, проверки сети и выпуск чертежей со спецификацией. Этот вариант покрывает все семь испытаний из задания.

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

Что дальше

Жду ответ по бюджету и выбор варианта. Если заказчик выберет первый или второй, модуль AutoCAD остаётся на потом, и сервис можно запускать этапами. До старта нужны материалы с их стороны, особенно каталог приборов и несколько настоящих планов. По ним я проверю распознавание на реальных сканах. Пока оно проверено только на условном примере из задания, и честнее сказать это сейчас, чем после запуска.

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

Частые вопросы

Сервис уже работает?

Нет. Есть предложение с макетами экранов на демонстрационных данных. Код сервиса не написан, договора нет.

Заменит ли сервис инженера?

Нет. Сервис считает то, что можно посчитать по формулам, и показывает, чего не хватает. Инженер утверждает исходные данные, проверяет результат и отвечает за выпуск. Цель сервиса сократить ручной ввод.

Почему в предложении три варианта?

Заказчик не знал, какой объём окупится первым. Расчётную часть можно запустить и проверить на живых планах, а сети и AutoCAD добавить следом. Похожую логику я описывал в статье про программу расчёта заказа и КП.

Коротко о главном

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

Нужен сайт с расчётом, кабинетом и выпуском документов? Посмотрите, как я делаю сайты и сервисы. Напишите в Telegram, MAX или VK.