Одна из частых причин неудачных доработок — не сложность самой задачи, а ее расплывчатое описание. Когда пользователи говорят общими формулировками, а техническая команда додумывает детали сама, результат почти всегда расходится с ожиданиями.
Когда задача формулируется слишком общо, техническая команда неизбежно начинает достраивать ее смысл сама. Пользователь говорит, что ему нужно «быстрее», «удобнее» или «чтобы считалось правильно», а исполнители пытаются превратить эти слова в конкретные изменения. В результате стороны вроде бы обсуждают одну и ту же проблему, но представляют ее по-разному.
В 1С это особенно заметно, потому что одна и та же доработка почти всегда затрагивает не только форму или отчет, но и порядок работы людей, последовательность действий, документы-основания, права и ограничения. Поэтому сбор требований здесь важен не как формальность, а как способ заранее увидеть реальную задачу до того, как она превратится в код.
Полезно спрашивать не «что нужно улучшить», а где именно пользователь теряет время, что делает вручную и какой результат хочет получить после изменения. Чем ближе описание к реальному действию в системе, тем меньше риск двусмысленности.
Если не описаны исходные данные и ожидаемый итог, доработка рискует остаться «почти правильной», но неудобной для реальной работы. Важно понимать, с какими документами и условиями начинается сценарий и чем он должен завершиться.
Один живой пример операции часто снимает больше вопросов, чем длинное согласование на абстрактном уровне. Пример позволяет быстро увидеть скрытые ограничения, которые пользователь не формулирует отдельно.
Для большинства небольших задач достаточно короткой схемы из пяти пунктов: кто выполняет действие, в каком разделе или документе он работает, что мешает сейчас, какого результата он ждет и какие ограничения нельзя нарушить. Уже этого объема достаточно, чтобы отделить реальные требования от общих пожеланий.
Если задача затрагивает несколько ролей, полезно отдельно обозначить, кто именно будет работать с результатом. То, что удобно бухгалтеру, не всегда удобно менеджеру, а то, что подходит для редкого ручного сценария, может оказаться тяжелым для ежедневной массовой работы.
Иногда, пытаясь навести порядок, команды уходят в противоположную крайность и превращают любую небольшую доработку в длинный формальный процесс. Для крупного проекта это может быть оправдано, но для обычных задач сопровождения избыточная документация часто только замедляет работу и раздражает пользователей. Люди начинают отвечать формально, теряют интерес к деталям и перестают приносить полезные примеры.
Поэтому лучше стремиться не к максимальному объему описания, а к достаточной точности. Хорошие требования короткие, конкретные и проверяемые. После их чтения должно быть понятно, как выглядит проблемный сценарий сейчас и как он должен работать после изменения.
Достаточно короткой структуры: кто выполняет действие, в каком документе или разделе, что мешает сейчас, как выглядит желаемый результат и какие ограничения нельзя нарушить. Такой формат сохраняет смысл, но не превращает небольшую задачу в формальный проект на десятки страниц.
Если к описанию добавить один-два реальных примера и краткий критерий приемки, качество постановки задачи обычно растет заметно сильнее, чем от любого дополнительного шаблона.