Вопросы заказчику, которые экономят месяцы в 1С-проектах

Вопросы заказчику, которые экономят месяцы в 1С-проектах

В 1С-проектах много времени теряется не на самой разработке. Часто доработка занимает условные два дня, а обсуждение, переделки, уточнения, повторное тестирование и споры после запуска растягиваются на недели или месяцы.

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

На входе задача может звучать просто:

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

Если сразу взять такую формулировку в работу, можно быстро сделать видимый результат. Но потом выясняется, что поле должно попадать в печатную форму, отчет нужен не только руководителю, маршрут зависит от суммы, права нельзя давать всем, а “как в старой базе” никто уже точно не помнит.

И начинается привычное: “мы думали, что будет иначе”, “а почему это не учли?”, “нам теперь неудобно работать”, “давайте еще немного поправим”.

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

Почему вопросы на старте важнее красивого документа с требованиями

Спецификация требований может быть красиво оформлена: цель, описание, сценарий, реквизиты, формы, проверки, роли, тестовые сценарии. Но если на входе неверно поняли задачу, хорошее оформление не спасет.

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

В 1С это особенно заметно, потому что почти любая доработка редко живет сама по себе. Новое поле может повлиять на печатную форму, обмен, отчет, права, регламентное задание, историю старых документов, маршрут согласования или закрытие периода.

Например, пользователь просит добавить реквизит “Ответственный менеджер” в документ. На первый взгляд — простая задача. Но нормальные вопросы быстро показывают, что нужно уточнить:

• кто заполняет это поле;
• может ли оно меняться после проведения документа;
• что делать со старыми документами;
• нужно ли выводить поле в список;
• нужно ли печатать его в форме;
• нужно ли использовать его в отчете;
• должно ли поле участвовать в правах или отборе;
• нужно ли передавать его в обмен.

Без этих вопросов задача выглядит маленькой. После вопросов становится понятно, что это уже не “просто поле”, а изменение данных, интерфейса, отчетности и, возможно, интеграции.

Вопрос 1. Зачем это нужно бизнесу?

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

Какую проблему мы решаем этой доработкой?

Не “что нужно сделать в 1С”, а именно “какую проблему нужно решить”. Это разные вещи.

Заказчик может сказать: “Нам нужен новый отчет”. Но реальная проблема может быть в том, что руководитель не видит просроченные заявки. Или пользователь не умеет пользоваться существующим отчетом. Или в базе не заполняется нужный реквизит. Или данные есть, но разбросаны по разным документам.

Если сразу делать новый отчет, можно потратить время и не решить проблему. Иногда достаточно настроить вариант существующего отчета, добавить отбор, обучить пользователей или поправить заполнение данных.

Вопросы, которые помогают понять цель:

• какое решение вы хотите принимать по этим данным;
• что сейчас приходится делать вручную;
• какая ошибка или потеря времени возникает сейчас;
• что изменится в работе после доработки;
• кто будет пользоваться результатом;
• как вы поймете, что задача решена.

Если заказчик не может объяснить, зачем нужна доработка, это не значит, что она не нужна. Но это сигнал: сначала нужно разобраться в проблеме, а не сразу готовить спецификацию требований для разработчика.

На сопровождении это часто выглядит так: сделали отчет, а через месяц им почти никто не пользуется. Начинаешь разбираться — отчет построен правильно, но исходная проблема была не в отчете, а в том, что пользователи не заполняли нужные данные в документах.

Вопрос 2. Как процесс работает сейчас?

Перед изменением процесса в 1С нужно понять, как он работает сейчас. Не как он должен работать по регламенту, а как он реально происходит.

Это важное различие. В регламенте может быть написано, что заявка проходит согласование у руководителя подразделения, потом у финансового отдела, потом у директора. А в жизни пользователь сначала пишет в чат, потом отправляет Excel, потом кто-то вручную создает документ, а согласование в 1С запускается уже “для порядка”.

Если автоматизировать только регламент, не увидев реальный процесс, система получится формально правильной, но неудобной.

Я задаю такие вопросы в процессе обследования:

• кто запускает процесс;
• с какого события он начинается;
• какие документы или данные появляются на входе;
• кто участвует в процессе;
• какие решения принимаются по ходу;
• где сейчас ручная работа;
• где чаще всего возникают ошибки;
• какие действия выполняются вне 1С;
• что считается завершением процесса.

Лучше всего просить заказчика показать 2–3 реальных примера. Не “расскажите в общем”, а “покажите последнюю заявку, последний договор, последний акт, последнюю служебную записку”.

Реальный пример быстро вскрывает детали, о которых никто не вспоминает на общей встрече: нестандартный согласующий, ручной файл, обходной сценарий, комментарий в почте, документ, который заводят задним числом.

Вопрос 3. Какие есть исключения?

Почти любой процесс в 1С на словах выглядит просто, пока не начинаешь спрашивать про исключения.

“Все договоры согласуются по одному маршруту”. Потом выясняется:

• договоры выше определенной суммы идут через финансового директора;
• договоры с нерезидентами дополнительно проверяет валютный контроль;
• договоры по отдельным проектам согласует руководитель проекта;
• типовые договоры проходят быстрее;
• срочные договоры иногда согласуют вне очереди;
• по филиалам есть отдельные правила;
• для некоторых контрагентов нужен дополнительный контроль.

Если эти исключения не собрать на старте, они появятся после запуска. И тогда придется переделывать маршрут, перепроверять сценарии, объяснять пользователям новые правила и исправлять уже созданные документы.

Вопросы по исключениям:

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

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

Вопрос 4. Кто будет работать с результатом?

Заказчик часто формулирует задачу от лица отдела или руководителя: “нам нужно”, “мы хотим”, “пользователям неудобно”. Но для качественного сбора требований этого мало.

Нужно понять, кто именно будет работать с результатом:

• инициатор;
• исполнитель;
• согласующий;
• руководитель;
• администратор;
• бухгалтер;
• кадровик;
• юрист;
• сотрудник поддержки;
• внешний участник процесса.

У каждого участника свой интерес. Инициатору важно быстро создать документ. Согласующему — понять, что именно он должен проверить. Руководителю — видеть статус. Бухгалтеру — получить корректные данные для учета. Администратору — понимать, как сопровождать настройку.

Если спросить только одного человека, можно сделать удобно ему, но неудобно всем остальным.

Например, руководитель просит добавить в отчет много колонок, чтобы “видеть всё”. Но пользователь, который работает с отчетом каждый день, потом тонет в широкой таблице и выгружает ее в Excel, чтобы вручную оставить нужные поля. Формально отчет сделали по просьбе руководителя. Практически — добавили ручную работу исполнителю.

Полезные вопросы:

• кто будет создавать документ или задачу;
• кто будет проверять результат;
• кто будет смотреть отчет каждый день;
• кто будет исправлять ошибки;
• кому нужны права на просмотр;
• кому нужны права на изменение;
• кто будет сопровождать это после запуска.

Если участников несколько, лучше сразу разделить сценарии. Один экран или отчет редко одинаково удобен для всех.

Вопрос 5. Какие данные нужны и откуда они берутся?

В 1С многие задачи ломаются не на форме и не на кнопке, а на данных.

Заказчик говорит: “Нужно вывести в отчет дату подписания”. Вопрос: где эта дата хранится? Кто ее заполняет? Она уже есть в базе или ее нужно добавить? Для старых документов она заполнена? Можно ли ей доверять? Что делать, если дата пустая?

Если эти вопросы не задать, отчет можно сделать технически правильно, но он будет показывать неполную или спорную картину.

В таких случаях я спрашиваю:

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

Отдельный важный вопрос — качество данных. В базе может быть реквизит, но если пользователи заполняют его как попало, строить на нем логику опасно.

Например, маршрут согласования хотят строить по полю “Категория договора”. Но это поле годами было необязательным, пользователи выбирали значения произвольно, а часть документов вообще пустая. Если сразу завязать маршрут на это поле, система начнет работать непредсказуемо.

На тестовых новых документах всё может выглядеть красиво: поле заполнено, маршрут идет правильно, отчет строится. А потом руководитель открывает отчет за прошлый год — и половина строк пустая. Не потому что отчет плохой, а потому что исторические данные никто не готовил под новую логику.

Вопрос 6. Что делать со старыми данными?

Этот вопрос часто забывают. Особенно когда доработка выглядит простой.

Добавили новый реквизит. Для новых документов все понятно. А что делать со старыми?

Добавили новый статус. Что делать с документами, которые уже находятся в процессе?

Изменили маршрут. Что делать с уже запущенными согласованиями?

Изменили правила заполнения. Нужно ли пересчитать старые документы?

Если старые данные не обсудить, после запуска почти всегда появляются вопросы:

• почему в старых документах пустое поле;
• почему отчет показывает не все данные;
• почему старые документы идут по старому маршруту;
• почему по новым правилам работают только новые документы;
• нужно ли делать обработку заполнения;
• кто будет проверять результат переноса.

Полезно сразу договориться:

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

Это не техническая мелочь. Это часть требований. Без нее доработка может быть принята в тестовой базе, но вызвать проблемы на реальных данных.

Вопрос 7. Какие права доступа нужны?

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

Отдельная классика — тестировать под пользователем с широкими правами, а потом удивляться, почему обычный согласующий не видит вложение, не может выполнить задачу или не видит документ в списке. Под администратором всё “работало”, а в реальной роли процесс остановился.

Поэтому по любой задаче стоит спрашивать:

• кто должен видеть объект;
• кто может создавать;
• кто может изменять;
• кто может удалять или помечать на удаление;
• кто может согласовывать;
• кто может видеть вложенные файлы;
• кто может видеть отчет;
• нужны ли ограничения по подразделению, организации, проекту, контрагенту;
• есть ли конфиденциальные данные.

В 1С:Документообороте это особенно важно: документ может быть виден по рабочей группе, грифу доступа, участию в процессе, подразделению, роли или другим настройкам. В БП и ЗУП свои нюансы: организации, подразделения, кадровые данные, зарплатная информация, регламентированный учет.

Если не обсудить права заранее, можно получить неприятную ситуацию: функционал разработан, но использовать его нельзя, потому что модель доступа не согласована.

Вопрос 8. Какие отчеты, отборы и поиск понадобятся?

Пользователи часто думают о создании документа, но забывают о том, как потом будут искать и анализировать данные.

Например, добавили новый вид заявки. На форме все удобно. Маршрут работает. Но через месяц руководитель спрашивает: “А где посмотреть все заявки по подразделениям и статусам?” И выясняется, что в отчете это не предусмотрели.

Поэтому до разработки стоит уточнить:

• как пользователи будут искать эти данные;
• нужны ли отборы в списках;
• нужны ли новые колонки;
• нужно ли выводить данные в существующие отчеты;
• нужен ли отдельный отчет;
• кто будет пользоваться отчетом;
• какие решения будут принимать по отчету;
• нужно ли выгружать данные в Excel;
• нужна ли история изменений.

Хороший вопрос заказчику:

Когда доработка начнет работать, как вы будете контролировать результат?

Этот вопрос часто выводит на отчеты, статусы, контрольные списки, уведомления и задачи, о которых на старте не говорили.

Вопрос 9. Есть ли интеграции и обмены?

В 1С редко что-то живет полностью отдельно. Документы могут уходить в другую базу, данные могут приходить из внешней системы, статусы могут передаваться в ЭДО, заявки могут быть связаны с сайтом, CRM, СЭД, складской системой или отчетностью.

Поэтому при изменении данных, документов или статусов нужно спрашивать про обмены.

Полезные вопросы:

• передаются ли эти данные в другие системы;
• приходят ли они из другой системы;
• есть ли обмен между базами 1С;
• есть ли интеграция с ЭДО, сайтом, CRM, СБИС, Диадок или другой системой;
• нужно ли менять формат обмена;
• что будет, если во внешней системе нет нового поля;
• кто отвечает за вторую сторону интеграции;
• как проверять обмен после доработки.

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

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

Вопрос 10. Что должно происходить при ошибках?

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

Нужно заранее уточнять:

• что делать, если обязательные данные не заполнены;
• какое сообщение должен увидеть пользователь;
• можно ли сохранить черновик;
• можно ли провести документ с предупреждением;
• кто должен получить уведомление об ошибке;
• нужно ли писать ошибку в журнал или регистр;
• можно ли повторить операцию;
• что делать, если внешняя система недоступна.

Например, если обмен с внешней системой не прошел, пользователю мало сообщения “ошибка обмена”. Ему нужно понять, что делать дальше: повторить отправку, обратиться в поддержку, проверить данные или ждать регламентного задания.

Хорошо заданный вопрос про ошибки экономит много времени поддержке. Вместо заявок “ничего не работает” пользователь получает понятное сообщение и следующий шаг.

Вопрос 11. Как будем принимать результат?

Один из самых важных вопросов:

По каким признакам заказчик поймет, что задача выполнена?

Если критериев приемки нет, задача может бесконечно дорабатываться. Разработчик сделал по спецификации требований, аналитик проверила свой сценарий, заказчик посмотрел и сказал: “Да, но мы имели в виду еще вот это”.

Критерии приемки лучше обсуждать до разработки.

Минимально нужно понять:

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

Особенно полезно заранее проговорить границы. Например: “В этой задаче мы добавляем реквизит, выводим его в форму и отчет. Автоматическое заполнение старых документов и изменение обмена — отдельные задачи”.

Такая фраза может сэкономить недели споров после тестирования.

Вопрос 12. Что точно не входит в задачу?

Этот вопрос звучит странно, но он очень полезен.

Когда обсуждается доработка, все говорят о том, что нужно сделать. Но почти никто не фиксирует, что делать не нужно.

В итоге после разработки появляются расширения:

• “а давайте еще в отчет добавим”;
• “а почему в печатной форме этого нет?”;
• “а можно сразу и старые документы заполнить?”;
• “а давайте еще уведомление руководителю”;
• “а это же должно уходить в обмен”.

Часть таких пожеланий может быть логичной. Но это не значит, что они автоматически входят в исходную задачу.

Поэтому полезно прямо фиксировать:

• что входит в текущий объем;
• что не входит;
• что можно сделать отдельным этапом;
• что требует отдельной оценки;
• что пока не делаем сознательно.

Это не защита от заказчика. Это нормальное управление ожиданиями. Заказчику тоже полезно понимать, что именно он получит в результате.

Вопрос 13. Какие сроки действительно критичны?

Фраза “нужно срочно” в 1С-проектах звучит часто. Но срочность бывает разной.

Иногда действительно остановился процесс: документы не проводятся, обмен не работает, зарплату нельзя рассчитать, отчетность под угрозой. А иногда “срочно” означает “хотелось бы быстрее”.

Поэтому стоит уточнять:

• что произойдет, если сделать позже;
• какая дата действительно критична;
• с чем связан срок;
• есть ли внешний дедлайн;
• можно ли сделать MVP;
• какую часть можно отложить;
• какие задачи можно снять с плана ради этой срочности.

Последний вопрос особенно важен. Если срочная задача добавляется в работу, что-то другое должно сдвинуться. Иначе команда просто получает перегруз и потом отвечает за все сроки одновременно.

Хороший вопрос заказчику:

Если мы берем это в работу сейчас, какую задачу можно отложить?

Этот вопрос быстро показывает реальный приоритет.

Вопрос 14. Кто владелец решения?

В 1С-задачах часто участвует несколько людей: инициатор, руководитель подразделения, ключевой пользователь, бухгалтерия, юристы, IT, разработчики, поддержка. Если не понять, кто принимает решение, задача может долго ходить по кругу.

Один пользователь просит одно, другой — другое, руководитель появляется только на приемке и говорит, что нужно было иначе.

Поэтому стоит уточнить:

• кто владелец процесса;
• кто принимает финальное решение;
• кто согласует требования;
• кто принимает результат;
• кто может менять приоритет;
• кто будет отвечать за правила после запуска.

Если владельца нет, аналитик фактически становится арбитром между разными мнениями. Это плохая позиция. Аналитик может помочь описать варианты, последствия и риски, но бизнес-решение должен принимать владелец процесса.

Вопрос 15. Как это будет сопровождаться после запуска?

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

Поэтому стоит заранее спросить:

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

Особенно это важно для нестандартных доработок. Если логика понятна только одному аналитику и одному разработчику, через полгода поддержка будет разбираться с ней заново.

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

Как задавать вопросы, чтобы заказчик не воспринимал это как бюрократию

Есть риск превратить все эти вопросы в длинную анкету и раздражать заказчика. Так делать не нужно.

Задача аналитика — не завалить заказчика вопросами, а помочь ему сформулировать решение.

Лучше объяснять, зачем задается вопрос:

• “Спрашиваю про старые документы, чтобы потом отчет не показал пустые значения”;
• “Уточняю права, чтобы после запуска лишние пользователи не увидели закрытую информацию”;
• “Хочу понять исключения, чтобы маршрут не пришлось переделывать через неделю”;
• “Фиксирую границы задачи, чтобы мы одинаково понимали результат”.

Когда заказчик понимает причину вопроса, он обычно воспринимает обсуждение спокойнее. Это уже не формальность, а защита от будущих переделок.

Мини-чек-лист вопросов перед подготовкой спецификации требований

Перед тем как отдавать задачу в разработку или настройку, полезно пройтись по короткому чек-листу.

Этот чек-лист не нужно использовать механически для каждой мелкой задачи. Но если задача затрагивает процесс, отчет, права, обмен или данные, лучше потратить время на вопросы до разработки.

Пример: “просто добавьте поле”

Возьмем простую заявку: “Добавьте поле ‘Тип договора’ в карточку договора”.

Если сделать без вопросов, задача кажется короткой: добавить реквизит, вывести на форму, проверить сохранение.

Но нормальный разбор быстро расширяет картину:

• какие значения бывают у типа договора;
• кто выбирает тип;
• можно ли менять тип после согласования;
• тип влияет на маршрут;
• тип нужен в отчете;
• тип нужен в печатной форме;
• что делать со старыми договорами;
• нужны ли права на просмотр или изменение;
• передается ли договор в другую систему;
• кто принимает результат.

После такого разбора может оказаться, что задача не “добавить поле”, а изменить классификацию договоров, маршрут согласования, отчетность и правила заполнения.

Это не значит, что задачу нельзя делать. Это значит, что ее нужно правильно оценить и согласовать объем.

Пример: “сделайте отчет как в Excel”

Еще одна частая заявка: “Сделайте в 1С отчет как в Excel”.

Здесь тоже нельзя сразу копировать таблицу. Нужно понять, зачем этот Excel используется.

Вопросы:

• кто заполняет Excel сейчас;
• из каких источников берутся данные;
• какие колонки считаются вручную;
• какие строки исключаются;
• какие ошибки чаще всего бывают;
• кто смотрит итог;
• какое решение принимается по отчету;
• нужна ли расшифровка до документов;
• нужно ли сохранять вариант отчета;
• нужна ли выгрузка обратно в Excel.

Иногда после такого разбора становится понятно, что нужен не один большой отчет, а несколько простых вариантов для разных ролей. Или что часть данных в 1С сейчас не заполняется, поэтому отчет не сможет быть достоверным без изменения процесса.

Итог

Вопросы заказчику на старте — это не бюрократия и не попытка усложнить работу. Это способ не потратить недели и месяцы на переделки.

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

Хороший вопрос экономит время не потому, что сразу дает идеальный ответ. Он помогает раньше увидеть риски: неполные данные, спорные роли, исключения, старые документы, неучтенные отчеты, интеграции, права доступа и размытые критерии приемки.

Для меня главный признак нормального обсуждения с заказчиком простой: после встречи понятно не только “что сделать в 1С”, но и зачем это нужно, кто будет пользоваться, как проверить результат и что точно не входит в задачу.

Несколько правильно заданных вопросов до разработки могут сэкономить месяцы переделок после запуска.

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