Расшифровка черного ящика: как оцифровать расчеты, которые заказчик годами вел в Excel
За 20 лет мы в «Сибирикс» разработали больше десятка сайтов для транспортных компаний. Заказчики всегда приходили с желанием сделать на сайте расчет стоимости и сроков доставки. Но в большинстве случаев в итоге получался корпоративный сайт с формой запроса стоимости и (иногда) с личным кабинетом.
Причины две. Первая, как обычно, – стоимость. Вторая – сложность перевода процесса, который использует заказчик для расчета, в формат, который можно использовать как постановку для программистов. Так называемая расшифровка черного ящика. Сложность этой работы зачастую сопоставима с разработкой самого калькулятора.
Про решение одной из задач расчета маршрута для логистического проекта мы писали в статье про микросервисную архитектуру.
Когда компания приходит за разработкой онлайн-калькулятора, она уже как-то считает стоимость. Тут может быть масса вариантов. От условного Иван-Ивановича, который один знает, как правильно все рассчитать, чертит маршруты на бумажной карте и считает в тетрадочке. До набора форм в экселе, которые сделаны много лет назад и никто не помнит, что там внутри.
Еще бывает, что расчет реализован на стороне ERP. В этом случае задачу можно решить гораздо проще. Мы просим у пользователя набор данных, передаем их в систему заказчика, а в ответ выводим полученные из системы расчеты. Или форму обратной связи, если система вернула ответ, что по введенным данным ничего расчитать нельзя. Расшифровка не нужна. Черный ящик уже работает без нашего участия.
В остальных случаях надо разобрать процесс на элементы и собрать у себя новый черный ящик, который будет выдавать правильный ответ на сайте.
С чего начать и как продолжить
Для начала надо получить от заказчика все артефакты, которые у него есть для расчета. Список данных, которые подаются на вход. Список данных, которые надо получить на выходе. Скрипт или файлики, которые используются им сейчас. Формулы (если они есть). Возможно, придется пробрифовать Иван-Ивановича. Все это надо аккуратно зафиксировать.
В логистических компаниях методика расчета часто является ценным ноу-хау, так что не удивляйтесь, что предварительно заказчик попросит подписать NDA.
Хотя руки уже чешутся начать писать техзадание – делать это пока не стоит. Сначала разбираем процесс на шаги – что и в каком порядке должен вводить пользователь, и что и в каком порядке должно выводиться в расчетах. Можно нарисовать блок-схему. Подсказка: на каждую “развилку”, где один из вариантов – завершение расчета, нужен отдельный шаг калькулятора.
Теперь рисуем прототипы или сразу макеты для всех шагов. Их надо согласовать с заказчиком. Только после этого переходим к ТЗ.
Проще всего сначала описать все интерфейсы и отметить места, где надо откуда-то выводить данные. Дальше – идем по порядку и отвечаем на вопрос: “Откуда это берется”. Вариантов не так много:
- вводит пользователь на странице. Поля калькулятора. Для них обычно нужны разные ограничения. Например, выбрать город назначения можно только из определенного списка, груз больше 10 тонн и длиннее 4 метров в машину не войдет, часть товаров под санкциями и через границу их не пропустят и т.д. Эти ограничения также надо описать.
- задается как хардкод. То, что задается программистом и может быть отредактировано только в коде. Подходит для данных, которые в обозримом будущем не изменятся. Типа текста подсказки у полей “куда” и “откуда”. Если данные не изменятся, но их много (например, расстояния между складами и т.д.) – лучше выносить в админку – там их проще заполнить и исправить в случае ошибки.
- из базы данных сайта. То, что надо будет заполнять в административной панели или откуда-то импортировать. Города и страны, в которые компания возит грузы, базовые цены для направлений, типы транспорта и т д.
- рассчитывается по формуле. Сюда попадает большая часть черного ящика клиента.
Указать источник важно для всех данных на страницах калькулятора. Если что-то кажется очевидным – тем более. Практика показывает, что для разных людей очевидным кажется разное. Для данных, которые придется заполнять в админке, не ленитесь расписать поля для каждой таблицы. Места, где выполняется расчет по формулам пока пропускаем.
Итак, у нас остался список данных, для получения которых нужна формула. Готовим список вариантов входных данных: для каждого варианта пишем что-то типа тест-кейсов – набор значений, которые попадают в данный вариант.
Берем файлы заказчика, по которым он сейчас считает. Вносим туда по очереди данные каждого тест-кейса и разбираем, каким образом получается итоговый результат. Если сначала рассчитываются какие-то промежуточные ячейки – обозначаем их промежуточными коэффициентами. В итоге получаем набор формул, которые переносим в ТЗ.
Как сдать новый черный ящик заказчику
Итак, вы получили документ на 10-15-20 страниц мелким шрифтом. С формулами и описанием поведения элементов интерфейса в стиле “если-то”. Возникает вопрос – как сдать его заказчику. Причем не формально, а заставить клиента разобраться, прочитать и подтвердить, что черный ящик расшифрован верно. Ведь программировать вы будете по ТЗ.
Более того, если просто отдать техническое задание заказчику – можно получить резко негативную реакцию.
Заказчик за годы сжился со своей методикой расчета. Он знает, что в эксель-таблице “города” надо посмотреть, к какой группе относится город, в таблице “регионы” – найти пересечение группы со страной, чтобы определить регион. Вычислить для груза коэффициент объема. Рассчитать коэффициент веса. Найти пропорцию одного относительно другого. В таблице “цены” – найти пересечение региона и коэффициента объема или веса (зависит от значения пропорции) и т.д.
С годами в таких системах накапливается все больше костылей, которые можно выкинуть и оптимизировать процесс. На этапе написания техзадания так обычно и делается. Но заказчик свои костыли помнит и любит. Как результат, если ему показать ТЗ “в лоб” – у него возникнет чувство “все не так!”, а не желание разобраться. Вероятно, он начнет требовать, чтобы ТЗ переделали, как он понимает. Скорее всего, так запрограммировать тоже можно, но объем кода вырастет раза в три. Оно вам надо?
При приемке ТЗ есть две крайности: «приемка не читая» и «формализм». Вариант «приемка не читая» (а такое встречается, мало кто любит технические документы) сразу отметаем. Обе стороны не защищены.
Вариант «формализм»: «заказчик по договору должен принять — вот пусть и читает. Иначе дальше не сдвинемся. Без ТЗ — результат ХЗ» чуть лучше, но не намного. Могут уйти недели + это как-то… Км… Неклиентоориентированно.
Какие есть варианты:
Терроризм
Говорим заказчику, что так, как у него в файлах, сделать можно только с бюджетом хN / нельзя в принципе. Так что мы будем делать как описали, а если расчеты в итоге не сойдутся – он сам виноват. Правки все будут за отдельные деньги с оплатой по часам. Может сработать, но скорее всего заказчик после такого не захочет дальше делать проект с вами.
Уговоры
Просим заказчика прочитать ТЗ. рассказываем, что как мы описали – разработка обойдется дешевле. Предлагаем по всем непонятным вопросам созвониться и объяснить. Может сработать, если заказчик сам замотивирован.
Уменьшение сложности задачи для заказчика
Делим ТЗ на небольшие части. Показываем поблочно. Каждую часть обсуждаем отдельно. Так процесс скорее всего сильно затянется. Заказчик может согласовать каждую часть, но в итоге не согласиться с итоговым результатом расчета. Но может и сработать, если сам алгоритм безболезненно делится на независимые части и если нет пожара по срокам.
Наглядная демонстрация
Зовем заказчика на звонок. Рассказываем про черный ящик. Показываем тест-кейсы. Предлагаем прямо на звонке просчитать каждый из кейсов по нашему ТЗ и по алгоритму заказчика. Показываем, что результат сходится. Отдаем ТЗ и просим заказчика проверить самостоятельно, то все так. Самый быстрый и безболезненный вариант, при котором реакция “Все не так!” не возникает.
Гарантирует ли это на 100% покрытие всех кейсов «черного ящика»? Увы, нет. Такую гарантию дать невозможно. Однако позволяет определить границы типовых сценариев. И запустить на них систему, решающую большинство задач.
Кстати, на этом этапе в игру с удовольствием может включиться заказчик, и поподкидывать дополнительных тестовых сценариев. На моей практике был случай, когда после такой процедуры заказчик обнаруживал баги в «черном ящике». То есть ошибка в расчетах у него жила годами.
Хитрые же кейсы придется выявлять и докручивать в ходе эксплуатации. Без работы по T&M, затрат на пусконаладку не обойтись
Подводим итоги
- Если есть возможность интеграции с уже работающим черным ящиком на стороне ERP – это идеальный вариант.
- В давно существующих системах может быть много артефактов, которые на самом деле не нужны для расчетов.
- Заказчики привязаны к своим методикам расчета, предложение что-то поменять могут воспринимать в штыки.
- Расшифровывать черный ящик надо поэтапно. Начинать с интерфейсов. Формулы – в последнюю очередь.
- Просто отдать ТЗ и дополнительно заняться терроризмом – надежный способ прекратить работу с клиентом. Иногда это может быть не самым плохим вариантом.
- Чтобы согласовать новый черный ящик используйте наглядную демонстрацию.