Бывает так: сидим на встрече, киваем друг другу, вроде всё понятно. А через неделю заказчик смотрит на результат и говорит: «Вообще не то». И дело не в том, что кто-то плохо работал. Просто каждый запомнил своё.

Я как бизнес-аналитик не надеюсь на память - ни на свою, ни на чужую. Сразу после разговора всё фиксирую. Особенно в 1С: тут одна нечёткая фраза может потом стоить кучи переделок.

Почему «и так понятно» - это риск

Каждый слышит по-своему. Для одного «все заказы» - это за месяц, для другого - только незакрытые, а разработчик вообще возьмёт всё, что есть в базе за 10 лет. Через пару недель детали забываются. Никто уже не вспомнит, почему мы решили не показывать НДС. Люди меняются. Уходит ключевой заказчик - и новому приходится объяснять всё заново. Без чётких критериев «готово» растягивается до бесконечности. Все хотят чуть-чуть подкрутить, и это нормально, но лучше делать это осознанно.

Что я делаю сразу, чтобы не было сюрпризов

1)Коротко фиксирую итоги встречи. Пишу 2-3 абзаца: о чём договорились, какие решения приняли, что осталось открытым. И отправляю всем в течение суток. Это не бумажная волокита, а способ убедиться, что мы на одной волне. 2)Прописываю, как поймём, что задача готова. Не «чтобы работало», а чётко: «Отчёт показывает статусы A, B, C, не показывает D. Сортировка - по дате, от новых к старым. Если период не задан - появляется сообщение “Период не задан”». По этим пунктам я сама потом всё проверяю. 3)Собираю словарь терминов. Если все говорят «заказ», «заявка», «реализация» про одно и то же - я сразу пишу: «В этом проекте “заказ” - это документ “Заказ клиента” в 1С». Это сильно экономит время и нервы. 4)Рисую простые схемы. Хоть в экселе) Иногда одной картинки хватает, чтобы все увидели процесс одинаково: откуда данные берутся, куда попадают, где могут быть проблемы. 5) Веду матрицу требований. В таблице видно: что нужно, откуда это пришло, какой статус, как будем проверять, кто отвечает. Так ничего не теряется, и легко показать, что уже проверено.

Простой пример из 1С

Задача: «Сделать отчёт по продажам с разбивкой по складам». Без фиксации тут сразу начинается путаница: кому-то хочется по юрлицам, кому-то по подразделениям, а кто-то ждёт только текущие остатки. Что я делаю на практике: Пишу чётко: отчёт строится по документам «Реализация товаров и услуг», период - по дате документа, склады - из табличной части. Добавляю правило: если склад не указан - строку не показываем. Рисую схему в три шага: документ → выборка → вывод. Готовлю три простых теста: один склад, без склада, несколько складов. Прикладываю пример: скрин макета или таблицу с тем, как это должно выглядеть. И самое главное - я не сдаю документ и забываю про него. ТЗ для меня - рабочий инструмент. Если на приёмке говорят «я хотел иначе», я спокойно открываю нужный пункт и тест-кейс: «Вот как мы договорились. Если теперь нужно по-другому - давайте оформим изменение и сразу прикинем, сколько времени это займёт». Это не чтобы доказать «я был прав». Это чтобы работать спокойно: без сюрпризов, лишних переделок и нервов. Для заказчика это значит понятные сроки и предсказуемый результат.