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

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

User story — ожидание от разработчика; Use cases — сценарии использования фичи; Wireframes — средство визуализации идей.

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

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

Как избежать всего этого хаоса?

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

Функциональные требования — это постановка задачи разработчику. Причем не просто название задачи, а полное содержание всех возможных ответов на вопросы, которые могут возникнуть в процессе разработки. Часто продакт–менеджеры не углубляются в процесс постановки задачи, рассчитывая на то, что взгляды разработчика полностью сходятся с его. Но, отнюдь, так бывает не всегда. И рано или поздно встает вопрос о доработках, так как результат оказался не таким, как хотелось бы.

Из чего состоят функциональные требования?

Существует три кита, на которых стоят функциональные требования:

• User story — ожидание от разработчика;

• Use cases — сценарии использования фичи;

• Wireframes — средство визуализации идей.

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

Шаблон выглядит таким образом:

Для удобства постановки задачи можно использовать различные программы — Trello, Google Docs (таблицы) и т.д. Благодаря такой системе можно легко наладить структуру коммуникации и вовремя оставлять комментарии на ту или иную задачу. Пример перед вами:

Наглядно видно, как процесс постановки задачи плавно перетекает в её выполнение.

После User story переходим к Use cases.

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

Например: у нас две задачи — загрузить изображения на платформу и затем удалить. Для первой нам необходимо прописать весь процесс — зайти в личный кабинет, открыть раздел «Галерея», загрузить, увидеть уведомление об успешной загрузке. Далее — прописываем ряд задач по удалению изображения: кликнуть по картинке, нажать на иконку «три точки», увидеть контекстное меню, удалить файл (примерный вариант).

Wireframes - иначе говоря, образ дизайна низкой точности. Как правило, он четко показывает три составляющих:

• основную группу контента;

• структуру информации;

• описание и базовую визуализацию взаимодействия между интерфейсом и пользователем.

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

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

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

• Не стоит сильно углубляться в мелкие детали требований;

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

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

Отличия функциональных требований от бизнес–требований

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

А как вы подходите к постановке задач разработчикам? Опираетесь только на интуицию или же применяете четкую структуру? Конечно же, мы понимаем, что невозможно довести постановку задач до идеала. Но приблизить её к совершенству вполне в силах каждый продакт–менеджер, если будет применять подход, о котором мы говорили выше.