Расшифровка черного ящика

За 20 лет мы в «Сибирикс» разработали больше десятка сайтов для транспортных компаний. Заказчики всегда приходили с желанием сделать на сайте расчет стоимости и сроков доставки. Но в большинстве случаев в итоге получался корпоративный сайт с формой запроса стоимости и (иногда) с личным кабинетом.

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

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

Еще бывает, что расчет реализован на стороне ERP. В этом случае задачу можно решить гораздо проще. Мы просим у пользователя набор данных, передаем их в систему заказчика, а в ответ выводим полученные из системы расчеты. Или форму обратной связи, если система вернула ответ, что по введенным данным ничего расчитать нельзя. Расшифровка не нужна. Черный ящик уже работает без нашего участия.

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

Для начала надо получить от заказчика все артефакты, которые у него есть для расчета. Список данных, которые подаются на вход. Список данных, которые надо получить на выходе. Скрипт или файлики, которые используются им сейчас. Формулы (если они есть). Возможно, придется пробрифовать Иван-Ивановича. Все это надо аккуратно зафиксировать.

Хотя руки уже чешутся начать писать техзадание — делать это пока не стоит. Сначала разбираем процесс на шаги — что и в каком порядке должен вводить пользователь, и что и в каком порядке должно выводиться в расчетах. Можно нарисовать блок-схему. Подсказка: на каждую «развилку», где один из вариантов — завершение расчета, нужен отдельный шаг калькулятора.

Теперь рисуем прототипы или сразу макеты для всех шагов. Их надо согласовать с заказчиком. Только после этого переходим к ТЗ.

Проще всего сначала описать все интерфейсы и отметить места, где надо откуда-то выводить данные. Дальше — идем по порядку и отвечаем на вопрос: «Откуда это берется». Вариантов не так много:

Указать источник важно для всех данных на страницах калькулятора. Если что-то кажется очевидным — тем более. Практика показывает, что для разных людей очевидным кажется разное. Для данных, которые придется заполнять в админке, не ленитесь расписать поля для каждой таблицы. Места, где выполняется расчет по формулам пока пропускаем.

Итак, у нас остался список данных, для получения которых нужна формула. Готовим список вариантов входных данных: для каждого варианта пишем что-то типа тест-кейсов — набор значений, которые попадают в данный вариант.

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

Итак, вы получили документ на 10−15−20 страниц мелким шрифтом. С формулами и описанием поведения элементов интерфейса в стиле «если-то». Возникает вопрос — как сдать его заказчику. Причем не формально, а заставить клиента разобраться, прочитать и подтвердить, что черный ящик расшифрован верно. Ведь программировать вы будете по ТЗ.

Более того, если просто отдать техническое задание заказчику — можно получить резко негативную реакцию.

С годами в таких системах накапливается все больше костылей, которые можно выкинуть и оптимизировать процесс. На этапе написания техзадания так обычно и делается. Но заказчик свои костыли помнит и любит. Как результат, если ему показать ТЗ «в лоб» — у него возникнет чувство «все не так!», а не желание разобраться. Вероятно, он начнет требовать, чтобы ТЗ переделали, как он понимает. Скорее всего, так запрограммировать тоже можно, но объем кода вырастет раза в три. Оно вам надо?

Какие есть варианты:

Говорим заказчику, что так, как у него в файлах, сделать можно только с бюджетом хN / нельзя в принципе. Так что мы будем делать как описали, а если расчеты в итоге не сойдутся — он сам виноват. Правки все будут за отдельные деньги с оплатой по часам. Может сработать, но скорее всего заказчик после такого не захочет дальше делать проект с вами.

Просим заказчика прочитать ТЗ. Рассказываем, что так, как мы описали — разработка обойдется дешевле. Предлагаем по всем непонятным вопросам созвониться и объяснить. Может сработать, если заказчик сам замотивирован.

Делим ТЗ на небольшие части. Показываем поблочно. Каждую часть обсуждаем отдельно. Так процесс скорее всего сильно затянется. Заказчик может согласовать каждую часть, но в итоге не согласиться с итоговым результатом расчета. Но может и сработать, если сам алгоритм безболезненно делится на независимые части и если нет пожара по срокам.

Зовем заказчика на звонок. Рассказываем про черный ящик. Показываем тест-кейсы. Предлагаем прямо на звонке просчитать каждый из кейсов по нашему ТЗ и по алгоритму заказчика. Показываем, что результат сходится. Отдаем ТЗ и просим заказчика проверить самостоятельно, то все так. Самый быстрый и безболезненный вариант, при котором реакция «Все не так!» не возникает.