Онлайн книга по продакт‑менеджменту
Глава 7

Составление требований для разработки

Заполните форму и получите ссылку с презентациями, и подробными видео‑лекциями на свою почту!

В этой главе речь пойдет о том, как продуктовый менеджер взаимодействует с разработ­чиками из R&D, зачем нужны требования, как правильно их сформулировать, и какие выводы из требований к разработке должны делать различные спе­циалисты, включая самих разра­ботчиков, менеджеров, QA и так далее. С другой стороны буду­щие и уже состоявшиеся разра­ботчики узнают, что может (и вообще-то должен) предостав­лять вам менеджер продукта.

Иногда кажется, что задача для разработчика просто очевидна! Но не стоит слишком сильно полагаться в вопросах поста­новки задачи на здравый смысл. Для любой, даже самой простой задачи возможны разночтения, потому что людям свойственно жить в мире собственных иллюзий. Например, в Респуб­лике Куба считается, что стены должны быть яркими и пестры­ми, и если даже заказчик попросит покрасить стены в белый, работники могут доба­вить цветных пятен, потому что «так ведь красивее». То же самое касается и разработки.
Такой документ как требования помогает преодолеть «стену непонимания». Наличие требо­ваний позволяет создать оди­наковое представление о том, что нужно сделать в продукте, какая именно должна быть фича.

Как строятся требования

Формируя требования к разработке, нужно понимать, для какого пользователя разраба­тываем продукт. Здесь очень полезны оказываются User Persona (мы уже говорили о них здесь). User Persona — это так называемый Актор (Actor) в системе, и для каждого актора мы определяем набор правил и возможностей.
Например, в приложении веб-форума могут быть определены следующие акторы:

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

Чтобы сформулировать адекват­ное требование, нужно составить документ, который мы называем Feature Description. А для этого нужно ответить на следующие вопросы:
Также нужно предусмотреть наличие словаря терминов предметной области. Особенно это касается специфичных акро­нимов. Например, разработчик может не знать всех названий процессов и специфики стале­литейной промышленности или кулинарии.
Наконец, в документе нужно сделать секцию “Approvals” (сог­ласование), в которой, с одной стороны, заказчики фичи (стейк­холдеры, клиенты, продакт-менеджер) согласятся, что описание соответствует тому, что они хотят получить от продукта. С другой стороны, разработчики (тимлиды, архитекторы) подтвер­дят, что описание задачи в требованиях является понятным и полным. Все участники процесса разработки таким образом должны сказать: “Да, документ нам понятен, теперь это можно сделать».

Вспомогательные метрики

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

Функциональные и нефункциональные требования, сценарии использования

Остановимся немного на функциональных и нефункцио­нальных требованиях.
Функциональные требования объясняют, что должно быть сделано, в них перечислены действия приложения, как реакция на действия Актора. Эти требования реализуются в перечисленных Use Scenarios (сценариях использования).
Нефункциональные требования фиксируют условия, при которых решение должно оставаться эффективным, или качества, которыми решение должно обладать. Самые распростра­ненные примеры нефункцио­нальных требований:
Также для описания требований применяются сценарии исполь­зования. Это основной элемент нашего документа, который мы готовим при формировании запроса на фичу. В Сценариях должен содержаться полный пошаговый алгоритм того, что пользователь может сделать с вашим приложением.
Пользовательские сценарии обычно содержат следующие секции:
Секция: Контекст
Отвечает на вопрос: Какой компонент? Какое состояние?
Пример: Пользователь не авторизован.
Секция: Актор
Отвечает на вопрос: Какая персона?
Пример: Обычный пользователь.
Секция: Предварительные условия
Отвечает на вопрос: Каковы особенности?
Пример: Есть приглашение получить VIP-статус.
Секция: Цель
Отвечает на вопрос: Что пользователь намеревается сделать/получить?
Пример: Войти в систему.
Секция: Основной сценарий
Отвечает на вопрос: Какие действия нужно совершить для достижения результата?
Пример: Ввести логин и пароль, нажать кнопку “войти”.
Секция: Неудачные сценарии
Отвечает на вопрос: Что может пойти не так, список ошибок, включая текст сообщений об ошибках для пользователя.
Пример: Кнопка не нажимается, не меняется язык, не удается установить соединение по протоколу https и так далее…
Секция: Макеты
Отвечает на вопрос: Возможные макеты или прототипы дизайна UI.
Пример: нарисуйте в Figma или Sketch.
В упрощенном виде пользова­тельские сценарии могут выгля­деть следующим образом:
Неавторизованный пользователь хочет попасть в систему. Пользователь вводит логин (в виде e-mail) и пароль (только латинские буквы и цифры). Если они верны и пользователь имеет право на вход, он входит в систему, иначе показываем ошибку: «Неверный пароль» или «Такого пользователя нет. Зарегистрироваться здесь»

Как читают Feature Description?

Каждая категория пользователей может почерпнуть из требова­ний полезную информацию для себя. И поэтому очень важно иметь в виду, что требования будут читать разные люди:
Если вы пишете требования к разработке, обязательно задай­тесь вопросом — кто ваш поль­зователь, что он делает (или может делать), в каких условиях находится. Создайте схему его поведения, она поможет описать все аспекты требований.
При составлении документа нужно быть максимально крат­кими и не оставлять непонятных мест. Requirements в любом случае будут занимать несколько страниц. Его должны прочитать много человек, и нужно, чтобы он был читабельным.
Руководствуйтесь простым пра­вилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрас­тет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Же­лательно сразу определить, что должно делать ваше прило­жение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”

Заключение

В следующей главе мы пого­ворим о бизнес-плане и цено­образовании для нового про­дукта.

Хотите просмотреть подробную видео-лекцию по этой теме? Доступ к платной записи (1,5 часа) предоставляется после оплаты.

Разговариваете со своими разра­ботчиками на разных языках? Сроки все время едут? Качество продукта оставляет желать лучшего? Обращайтесь, обсудим что с этим можно сделать.
СОГЛАСИЕ НА ОБРАБОТКУ ПЕРСОНАЛЬНЫХ ДАННЫХ
Настоящим в соответствии с Федеральным законом № 152-ФЗ «О персональных данных» от 27.07.2006 года свободно, своей волей и в своем интересе выражаю свое безусловное согласие на обработку моих персональных данных, переданных через сайт «https://productdevelopment.tech/», (далее по тексту – Оператор).

Настоящее Согласие выдано мною на обработку следующих персональных данных: фамилии; имени; отчества; телефона; e-mail; а также любой информации, предоставленной мной по собственному желанию.

Согласие дано Оператору для совершения следующих действий с моими персональными данными с использованием средств автоматизации и/или без использования таких средств: сбор, систематизация, накопление, хранение, уточнение (обновление, изменение), использование, обезличивание, а также осуществление любых иных действий, предусмотренных действующим законодательством РФ как неавтоматизированными, так и автоматизированными способами.

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

Настоящее согласие действует до момента его отзыва путем направления соответствующего уведомления на электронный адрес info@rudomanov.ru.

В случае отзыва мною согласия на обработку персональных данных Оператор вправе продолжить обработку персональных данных без моего согласия при наличии оснований, указанных в пунктах 2 – 11 части 1 статьи 6, части 2 статьи 10 и части 2 статьи 11 Федерального закона №152-ФЗ «О персональных данных» от 26.06.2006 г.