У нас был отчет, функциональное требование к которому звучало предельно кратко: "Сделайте как было в исторической системе". Всё. Логику формирования мы описывали - если не сказать изобретали - с нуля.

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

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

Оглядываясь назад, я понимаю: после того трёхчасового совещания нужно было обязательно согласовать изменения и доработки с заказчиком. Проговорить примерно следующее: - В исторической системе логика формирования отчета была такой. - Анализ бизнес-процессов и этой логики показывает, что не учитываются следующие важные сценарии. - Необходимо доработать логику формирования отчета. А затем письменно зафиксировать все расхождения и согласования.

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

Получается, что иногда за формулировкой "сделайте как было" стоит не готовое решение, а набор неявных договорённостей и упрощений, которые жили в головах пользователей. И лучше вытащить их на свет и согласовать до начала разработки, чем потом объяснять, почему "как было" - не то же самое, что "как надо"