Сбор требований в 1С: как аналитик превращает пожелания в предсказуемый проект автоматизации

Что такое требование: от потребности бизнеса к техническому заданию

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

Например, руководитель отдела продаж говорит: «Я хочу, чтобы менеджеры по продажам вовремя вносили планы». Это бизнес-требование. Если вовремя не ввести планы по продажам, может затормозиться, в том числе, производственная деятельность компании, планирование которой напрямую зависит от плана продаж.

На данном этапе важно разделять потребность и требование:

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

• Требование — это сформулированное желание владельца процесса с прогнозируемым результатом.

Как аналитики мы работаем только с теми бизнес-требованиями, которые можно переложить на программу и автоматизировать. Программа не может заставить сотрудников вовремя вводить необходимые данные в систему, но может, например, на базе конфигурации 1С:ERP выполнять следующие алгоритмы:

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

С такими требованиями мы работать можем и будем.

Методы сбора требований

Выбор метода базово зависит от масштаба проекта, количества участников и степени зрелости бизнес-процессов Заказчика.

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

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

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

4.Пользовательские истории. Частный случай интервью. Разговариваем с пользователем с точки зрения программы: что он вносит в систему, что ожидает на выходе. Однако если система уже глубоко автоматизирована, пользователь может не знать, как она работает «под капотом», следовательно, помогаем с этим разобраться.

Важные правила при сборе требований

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

2.Выяснить суть процесса. За любым требованием могут скрываться «подводные камни». Всегда задавайте вопросы: «Зачем это нужно?», «Какая конечная цель у данного процесса, что хотим получить на выходе?».

3.Фиксировать информацию. Опираться на память — риск потерять важные нюансы требований. Договоренности, озвученные при сборе требований, необходимо документировать. Используйте аудиозапись, заметки — главное, чтобы к следующему шагу у вас была полная и достоверная картина, а не интерпретация «на основе впечатлений».

При сборе требований можно опираться на следующие вопросы:

• Опишите регламент вашей работы по ключевым операциям.
• Какие операции являются наиболее ресурсоемкими?
• Какие отчетные формы вы формируете и в какие сроки?
• Каковы основные сложности в текущей системе работы?

Квалификация и ранжирование требований

После сбора требований их нужно квалифицировать и ранжировать.

Квалификация

Разделяем требования на:

• Функциональные — что должна делать система (например, «Система должна автоматически создавать документ "Заказ поставщику" на основании потребностей»);
• Нефункциональные — как быстро или удобно должна работать система (например, «Система должна автоматически создавать документ "Заказ поставщику" на основании потребностей каждые 15 минут»).

В первую очередь отрабатываются функциональные требования.

Ранжирование

Определяем приоритеты, чтобы в первую очередь создать минимально работающую систему (MVP):

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

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

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

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

Уточнение требований

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

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

Техническое проектирование и передача разработчикам

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

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

Как понять, что требования выполнены

В конце крупных проектов проводится комплексная проверка системы:

Функциональное тестирование — проверка всех шагов: от ввода нормативно-справочной информации до выполнения сквозных бизнес-процессов (закупка, продажи, производство, планирование);

Интеграционное тестирование — проверка взаимодействия с внешними системами: сайтами, смежными конфигурациями на базе 1С, банковскими сервисами.

Вместо заключения

Качество формализации бизнес-требований — один из ключевых факторов, определяющий успех проектов автоматизации на платформе 1С.

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

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

Готовы обсудить ваш проект? Оставьте заявку в форме на нашем сайте, и мы поможем внедрить «1С» так, чтобы система работала на вас, а не вы на нее.