Что такое требование: от потребности бизнеса к техническому заданию
В рамках любой автоматизации у бизнеса есть требования, и называются они бизнес-требованиями. Как правило, это не просто пожелания, а условия, без выполнения которых бизнес, с наибольшей вероятностью, не может функционировать, или его работа будет существенно затруднена.
Например, руководитель отдела продаж говорит: «Я хочу, чтобы менеджеры по продажам вовремя вносили планы». Это бизнес-требование. Если вовремя не ввести планы по продажам, может затормозиться, в том числе, производственная деятельность компании, планирование которой напрямую зависит от плана продаж.
На данном этапе важно разделять потребность и требование:
Как аналитики мы работаем только с теми бизнес-требованиями, которые можно переложить на программу и автоматизировать. Программа не может заставить сотрудников вовремя вводить необходимые данные в систему, но может, например, на базе конфигурации 1С:ERP выполнять следующие алгоритмы:
С такими требованиями мы работать можем и будем.
Методы сбора требований
Выбор метода базово зависит от масштаба проекта, количества участников и степени зрелости бизнес-процессов Заказчика.
1.Анкетирование. Используется, когда нужно опросить большое количество людей. Вместо длительных личных бесед разрабатывается анкета, а затем обрабатываются полученные ответы.
2.Прототипирование. Эффективно, когда нужно оттолкнуться от визуального образа. Показываем Заказчику прототип интерфейса и собираем обратную связь: что удобно, что нет, чего не хватает.
3.Интервьюирование. Самый глубокий метод. Общаемся напрямую с пользователем, узнаем, как он работает в текущей системе, что его не устраивает, какие операции занимают больше всего времени.
4.Пользовательские истории. Частный случай интервью. Разговариваем с пользователем с точки зрения программы: что он вносит в систему, что ожидает на выходе. Однако если система уже глубоко автоматизирована, пользователь может не знать, как она работает «под капотом», следовательно, помогаем с этим разобраться.
Важные правила при сборе требований
1.Определить ключевого специалиста. Если вам выделяют оператора, который только вносит документы и не знает, куда они идут дальше, — требуйте более компетентного сотрудника.
2.Выяснить суть процесса. За любым требованием могут скрываться «подводные камни». Всегда задавайте вопросы: «Зачем это нужно?», «Какая конечная цель у данного процесса, что хотим получить на выходе?».
3.Фиксировать информацию. Опираться на память — риск потерять важные нюансы требований. Договоренности, озвученные при сборе требований, необходимо документировать. Используйте аудиозапись, заметки — главное, чтобы к следующему шагу у вас была полная и достоверная картина, а не интерпретация «на основе впечатлений».
При сборе требований можно опираться на следующие вопросы:
Квалификация и ранжирование требований
После сбора требований их нужно квалифицировать и ранжировать.
Квалификация
Разделяем требования на:
В первую очередь отрабатываются функциональные требования.
Ранжирование
Определяем приоритеты, чтобы в первую очередь создать минимально работающую систему (MVP):
1.Первый приоритет — критические требования, без которых система не сможет функционировать.
2.Второй приоритет — важные для запуска, но не критические. Система будет работать, но с неудобствами.
3.Третий приоритет — некритичные требования, которые являются улучшениями функционала после выполнения требований первого и второго приоритетов. Фиксируем, но можем не реализовывать, если они выходят за рамки проекта.
Также учитываем очередность разработки: сначала справочники, ввод первоначальных и исторических данных, затем документы, потом отчеты.
Уточнение требований
После первичного сбора неизбежно возникают вопросы. Назначаем дополнительную встречу. Что важно на ней:
Техническое проектирование и передача разработчикам
Мы придерживаемся простого, но эффективного принципа: каждую задачу нужно дробить на несколько мелких. Это позволяет:
Как понять, что требования выполнены
В конце крупных проектов проводится комплексная проверка системы:
Функциональное тестирование — проверка всех шагов: от ввода нормативно-справочной информации до выполнения сквозных бизнес-процессов (закупка, продажи, производство, планирование);
Интеграционное тестирование — проверка взаимодействия с внешними системами: сайтами, смежными конфигурациями на базе 1С, банковскими сервисами.
Вместо заключения
Качество формализации бизнес-требований — один из ключевых факторов, определяющий успех проектов автоматизации на платформе 1С.
Строгое следование методологии, основанной на активном участии бизнес-экспертов, структурированном интервьюировании, четкой фиксации требований, готовности к оптимизации процессов, позволяет сделать проект предсказуемым, уложиться в сроки и бюджет, а главное — получить систему, которая действительно решает задачи бизнеса.
Автоматизация неэффективного процесса лишь умножает его недостатки. Наша задача — не просто записать пожелания, а предложить лучшее отраслевое решение, опираясь на возможности платформы 1С и накопленный опыт.
В рамках любой автоматизации у бизнеса есть требования, и называются они бизнес-требованиями. Как правило, это не просто пожелания, а условия, без выполнения которых бизнес, с наибольшей вероятностью, не может функционировать, или его работа будет существенно затруднена.
Например, руководитель отдела продаж говорит: «Я хочу, чтобы менеджеры по продажам вовремя вносили планы». Это бизнес-требование. Если вовремя не ввести планы по продажам, может затормозиться, в том числе, производственная деятельность компании, планирование которой напрямую зависит от плана продаж.
На данном этапе важно разделять потребность и требование:
- Потребность бизнеса — это цель или идея. В примере выше потребность заключается в стабильном вводе планов продаж со стороны менеджеров для обеспечения бесперебойной работы предприятия и, как результат, получения максимальной прибыли.
- Требование — это сформулированное желание владельца процесса с прогнозируемым результатом.
Как аналитики мы работаем только с теми бизнес-требованиями, которые можно переложить на программу и автоматизировать. Программа не может заставить сотрудников вовремя вводить необходимые данные в систему, но может, например, на базе конфигурации 1С:ERP выполнять следующие алгоритмы:
- настроить обязательное заполнение планов до определенной даты с блокировкой дальнейших действий (например, невозможностью выставить счет) при нарушении срока;
- вести историю своевременности внесения планов для использования в расчете мотивации;
- отправлять автоматические уведомления руководителю о сотрудниках, не выполнивших регламент.
С такими требованиями мы работать можем и будем.
Методы сбора требований
Выбор метода базово зависит от масштаба проекта, количества участников и степени зрелости бизнес-процессов Заказчика.
1.Анкетирование. Используется, когда нужно опросить большое количество людей. Вместо длительных личных бесед разрабатывается анкета, а затем обрабатываются полученные ответы.
2.Прототипирование. Эффективно, когда нужно оттолкнуться от визуального образа. Показываем Заказчику прототип интерфейса и собираем обратную связь: что удобно, что нет, чего не хватает.
3.Интервьюирование. Самый глубокий метод. Общаемся напрямую с пользователем, узнаем, как он работает в текущей системе, что его не устраивает, какие операции занимают больше всего времени.
4.Пользовательские истории. Частный случай интервью. Разговариваем с пользователем с точки зрения программы: что он вносит в систему, что ожидает на выходе. Однако если система уже глубоко автоматизирована, пользователь может не знать, как она работает «под капотом», следовательно, помогаем с этим разобраться.
Важные правила при сборе требований
1.Определить ключевого специалиста. Если вам выделяют оператора, который только вносит документы и не знает, куда они идут дальше, — требуйте более компетентного сотрудника.
2.Выяснить суть процесса. За любым требованием могут скрываться «подводные камни». Всегда задавайте вопросы: «Зачем это нужно?», «Какая конечная цель у данного процесса, что хотим получить на выходе?».
3.Фиксировать информацию. Опираться на память — риск потерять важные нюансы требований. Договоренности, озвученные при сборе требований, необходимо документировать. Используйте аудиозапись, заметки — главное, чтобы к следующему шагу у вас была полная и достоверная картина, а не интерпретация «на основе впечатлений».
При сборе требований можно опираться на следующие вопросы:
- Опишите регламент вашей работы по ключевым операциям.
- Какие операции являются наиболее ресурсоемкими?
- Какие отчетные формы вы формируете и в какие сроки?
- Каковы основные сложности в текущей системе работы?
Квалификация и ранжирование требований
После сбора требований их нужно квалифицировать и ранжировать.
Квалификация
Разделяем требования на:
- Функциональные — что должна делать система (например, «Система должна автоматически создавать документ "Заказ поставщику" на основании потребностей»);
- Нефункциональные — как быстро или удобно должна работать система (например, «Система должна автоматически создавать документ "Заказ поставщику" на основании потребностей каждые 15 минут»).
В первую очередь отрабатываются функциональные требования.
Ранжирование
Определяем приоритеты, чтобы в первую очередь создать минимально работающую систему (MVP):
1.Первый приоритет — критические требования, без которых система не сможет функционировать.
2.Второй приоритет — важные для запуска, но не критические. Система будет работать, но с неудобствами.
3.Третий приоритет — некритичные требования, которые являются улучшениями функционала после выполнения требований первого и второго приоритетов. Фиксируем, но можем не реализовывать, если они выходят за рамки проекта.
Также учитываем очередность разработки: сначала справочники, ввод первоначальных и исторических данных, затем документы, потом отчеты.
Уточнение требований
После первичного сбора неизбежно возникают вопросы. Назначаем дополнительную встречу. Что важно на ней:
- Повестка. Участники должны знать, что и зачем обсуждается.
- Модерация. Не давайте участникам встречи уходить в сторону от основного контекста. Управляйте беседой.
- Протокол. Фиксируйте договоренности.
Техническое проектирование и передача разработчикам
Мы придерживаемся простого, но эффективного принципа: каждую задачу нужно дробить на несколько мелких. Это позволяет:
- распараллеливать работу между разработчиками;
- упрощать контроль;
- быстрее получать обратную связь.
Как понять, что требования выполнены
В конце крупных проектов проводится комплексная проверка системы:
Функциональное тестирование — проверка всех шагов: от ввода нормативно-справочной информации до выполнения сквозных бизнес-процессов (закупка, продажи, производство, планирование);
Интеграционное тестирование — проверка взаимодействия с внешними системами: сайтами, смежными конфигурациями на базе 1С, банковскими сервисами.
Вместо заключения
Качество формализации бизнес-требований — один из ключевых факторов, определяющий успех проектов автоматизации на платформе 1С.
Строгое следование методологии, основанной на активном участии бизнес-экспертов, структурированном интервьюировании, четкой фиксации требований, готовности к оптимизации процессов, позволяет сделать проект предсказуемым, уложиться в сроки и бюджет, а главное — получить систему, которая действительно решает задачи бизнеса.
Автоматизация неэффективного процесса лишь умножает его недостатки. Наша задача — не просто записать пожелания, а предложить лучшее отраслевое решение, опираясь на возможности платформы 1С и накопленный опыт.
Готовы обсудить ваш проект? Оставьте заявку в форме на нашем сайте, и мы поможем внедрить «1С» так, чтобы система работала на вас, а не вы на нее.