Привет, Хабр! Продолжая серию публикаций по продуктовому менеджменту, сегодня мы обсуждаем требования к разработке. В этом посте речь пойдет о том, как продуктовый менеджер взаимодействует с разработчиками из R&D, зачем нужны требования, как правильно их сформулировать, и какие выводы из требований к разработке должны делать различные специалисты, включая самих разработчиков, менеджеров, QA и так далее. С другой стороны будущие и уже состоявшиеся разработчики узнают, что может (и вообще-то должен) предоставлять вам менеджер продукта. Все подробности — под катом.
1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки < — Вы здесь
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта
Иногда кажется, что задача для разработчика просто очевидна! Но не стоит слишком сильно полагаться в вопросах постановки задачи на здравый смысл. Для любой, даже самой простой задачи возможны разночтения, потому что людям свойственно жить в мире собственных иллюзий. Например, в Республике Куба считается, что стены должны быть яркими и пестрыми, и если даже заказчик попросит покрасить стены в белый, работники могут добавить цветных пятен, потому что «так ведь красивее». То же самое касается и разработки.
Такой документ как требования помогает преодолеть «стену непонимания». Наличие требований позволяет создать одинаковое представление о том, что нужно сделать в продукте, какая именно должна быть фича.
Формируя требования к разработке, нужно понимать, для какого пользователя разрабатываем продукт. Здесь очень полезны оказываются User Persona (мы уже говорили о них здесь). User Persona — это так называемый Актор (Actor) в системе, и для каждого актора мы определяем набор правил и возможностей.
Например, в приложении веб-форума могут быть определены следующие акторы:
В случае с приложением для вызова такси, о котором мы периодически вспоминаем во время нашего курса, персонами могут быть пассажир, таксист и оператор.
Чтобы сформулировать адекватное требование, нужно составить документ, который мы называем Feature Description. А для этого нужно ответить на следующие вопросы:
Также нужно предусмотреть наличие словаря терминов предметной области. Особенно это касается специфичных акронимов. Например, разработчик может не знать всех названий процессов и специфики сталелитейной промышленности или кулинарии.
Наконец, в документе нужно сделать секцию “Approvals” (согласование), в которой, с одной стороны, заказчики фичи (стейкхолдеры, клиенты, продакт-менеджер) согласятся, что описание соответствует тому, что они хотят получить от продукта. С другой стороны, разработчики (тимлиды, архитекторы) подтвердят, что описание задачи в требованиях является понятным и полным. Все участники процесса разработки таким образом должны сказать: “Да, документ нам понятен, теперь это можно сделать».
При работе с требованиями помогают вспомогательные метрики, которые помогают добиться точного исполнения задачи, а также сократить временные затраты на проверку соответствия.
Остановимся немного на функциональных и нефункциональных требованиях.
Функциональные требования объясняют, что должно быть сделано, в них перечислены действия приложения, как реакция на действия Актора. Эти требования реализуются в перечисленных Use Scenarios (сценариях использования).
Нефункциональные требования фиксируют условия, при которых решение должно оставаться эффективным, или качества, которыми решение должно обладать. Самые распространенные примеры нефункциональных требований:
Также для описания требований применяются сценарии использования. Это основной элемент нашего документа, который мы готовим при формировании запроса на фичу. В Сценариях должен содержаться полный пошаговый алгоритм того, что пользователь может сделать с вашим приложением.
Пользовательские сценарии обычно содержат следующие секции:
Секция: Контекст
Отвечает на вопрос: Какой компонент? Какое состояние?
Пример: Пользователь не авторизован.
Секция: Актор
Отвечает на вопрос: Какая персона?
Пример: Обычный пользователь.
Секция: Предварительные условия
Отвечает на вопрос: Каковы особенности?
Пример: Есть приглашение получить VIP-статус.
Секция: Цель
Отвечает на вопрос: Что пользователь намеревается сделать/получить?
Пример: Войти в систему.
Секция: Основной сценарий
Отвечает на вопрос: Какие действия нужно совершить для достижения результата?
Пример: Ввести логин и пароль, нажать кнопку “войти”.
Секция: Неудачные сценарии
Отвечает на вопрос: Что может пойти не так, список ошибок, включая текст сообщений об ошибках для пользователя.
Пример: Кнопка не нажимается, не меняется язык, не удается установить соединение по протоколу https и так далее…
Секция: Макеты
Отвечает на вопрос: Возможные макеты или прототипы дизайна UI.
Пример: нарисуйте в Figma или Sketch.
В упрощенном виде пользовательские сценарии могут выглядеть следующим образом:
Каждая категория пользователей может почерпнуть из требований полезную информацию для себя. И поэтому очень важно иметь в виду, что требования будут читать разные люди:
Если вы пишете требования к разработке, обязательно задайтесь вопросом — кто ваш пользователь, что он делает (или может делать), в каких условиях находится. Создайте схему его поведения, она поможет описать все аспекты требований.
При составлении документа нужно быть максимально краткими и не оставлять непонятных мест. Requirements в любом случае будут занимать несколько страниц. Его должны прочитать много человек, и нужно, чтобы он был читабельным.
Руководствуйтесь простым правилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
→ Видео-запись всех лекций курса доступна на YouTube
Лекция про дорожную карту и требования для разработки:
Разговариваете со своими разработчиками на разном языке? Сроки все время едут? Качество продукта оставляет желать лучшего? Пишите в личку, обсудим что с этим можно сделать.
Оглавление курса
1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки < — Вы здесь
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта
Иногда кажется, что задача для разработчика просто очевидна! Но не стоит слишком сильно полагаться в вопросах постановки задачи на здравый смысл. Для любой, даже самой простой задачи возможны разночтения, потому что людям свойственно жить в мире собственных иллюзий. Например, в Республике Куба считается, что стены должны быть яркими и пестрыми, и если даже заказчик попросит покрасить стены в белый, работники могут добавить цветных пятен, потому что «так ведь красивее». То же самое касается и разработки.
Такой документ как требования помогает преодолеть «стену непонимания». Наличие требований позволяет создать одинаковое представление о том, что нужно сделать в продукте, какая именно должна быть фича.
Как строятся требования
Формируя требования к разработке, нужно понимать, для какого пользователя разрабатываем продукт. Здесь очень полезны оказываются User Persona (мы уже говорили о них здесь). User Persona — это так называемый Актор (Actor) в системе, и для каждого актора мы определяем набор правил и возможностей.
Например, в приложении веб-форума могут быть определены следующие акторы:
- Администратор может всё, буквально всё — в том числе назначать роли (персоны) другим пользователям.
- Обычный пользователь может только оставлять сообщения.
- Модератор может оставлять сообщения, удалять чужие сообщения, банить обычных пользователей.
В случае с приложением для вызова такси, о котором мы периодически вспоминаем во время нашего курса, персонами могут быть пассажир, таксист и оператор.
Чтобы сформулировать адекватное требование, нужно составить документ, который мы называем Feature Description. А для этого нужно ответить на следующие вопросы:
- Зачем? Какова цель? В чем польза для бизнеса?
- Почему? Каковы риски? Что мы потеряем, если не сделаем? Что случится, если сделаем?
- Что? Какую проблему мы хотим решить? Для кого?
- Как? Функциональные требования и сценарий использования (последовательность действий).
Также нужно предусмотреть наличие словаря терминов предметной области. Особенно это касается специфичных акронимов. Например, разработчик может не знать всех названий процессов и специфики сталелитейной промышленности или кулинарии.
Наконец, в документе нужно сделать секцию “Approvals” (согласование), в которой, с одной стороны, заказчики фичи (стейкхолдеры, клиенты, продакт-менеджер) согласятся, что описание соответствует тому, что они хотят получить от продукта. С другой стороны, разработчики (тимлиды, архитекторы) подтвердят, что описание задачи в требованиях является понятным и полным. Все участники процесса разработки таким образом должны сказать: “Да, документ нам понятен, теперь это можно сделать».
Вспомогательные метрики
При работе с требованиями помогают вспомогательные метрики, которые помогают добиться точного исполнения задачи, а также сократить временные затраты на проверку соответствия.
- Definition of Done — краткое описание того, как понять, что фича работает.
- Нефункциональные требования — требования к технических параметрам такие как: скорость реакции UI, загрузка бэкэнда, ограничения CPU и оперативной памяти. Это очень важный пункт, ведь если не озвучить требования, можно получить монстра — встроенный фотошоп вместо простого выбора цвета автомобиля.
- Требования к безопасности — шифрование, хранение персональных данных и т.д.
- Corner Case — тестирование граничных случаев. Что будет, если цена товара 0? Сколько машин такси может заказать человек одновременно?
- Частотность сценариев — определение, какие сценарии встречаются чаще. Например, при добавлении платежей хорошо указать, какой платежной системой, скорее всего, будут пользоваться клиенты — Visa, MasterCard, МИР, приложив ссылку на статистику.
- Требования к мониторингу и сбору метрик. Если есть фича, то нужно собирать данные, отслеживать, кто ее вызывает, как часто использует и так далее. Сбор данных можно вести анонимно, но нужно это делать, чтобы развивать продукт в дальнейшем. Ведь если мы ничего не измеряем, то ничего не знаем о реальной работе приложения.
- Зависимости фичей помогают правильнее распределять ресурсы. Например, нельзя реализовать “возможность оплаты картой Мир”, пока мы не сделали фичу “выбор метода оплаты”.
Функциональные и нефункциональные требования, сценарии использования
Остановимся немного на функциональных и нефункциональных требованиях.
Функциональные требования объясняют, что должно быть сделано, в них перечислены действия приложения, как реакция на действия Актора. Эти требования реализуются в перечисленных Use Scenarios (сценариях использования).
Нефункциональные требования фиксируют условия, при которых решение должно оставаться эффективным, или качества, которыми решение должно обладать. Самые распространенные примеры нефункциональных требований:
- масштабируемость,
- надёжность, минимальное время простоя,
- методы поддержки.
Также для описания требований применяются сценарии использования. Это основной элемент нашего документа, который мы готовим при формировании запроса на фичу. В Сценариях должен содержаться полный пошаговый алгоритм того, что пользователь может сделать с вашим приложением.
Пользовательские сценарии обычно содержат следующие секции:
Секция: Контекст
Отвечает на вопрос: Какой компонент? Какое состояние?
Пример: Пользователь не авторизован.
Секция: Актор
Отвечает на вопрос: Какая персона?
Пример: Обычный пользователь.
Секция: Предварительные условия
Отвечает на вопрос: Каковы особенности?
Пример: Есть приглашение получить VIP-статус.
Секция: Цель
Отвечает на вопрос: Что пользователь намеревается сделать/получить?
Пример: Войти в систему.
Секция: Основной сценарий
Отвечает на вопрос: Какие действия нужно совершить для достижения результата?
Пример: Ввести логин и пароль, нажать кнопку “войти”.
Секция: Неудачные сценарии
Отвечает на вопрос: Что может пойти не так, список ошибок, включая текст сообщений об ошибках для пользователя.
Пример: Кнопка не нажимается, не меняется язык, не удается установить соединение по протоколу https и так далее…
Секция: Макеты
Отвечает на вопрос: Возможные макеты или прототипы дизайна UI.
Пример: нарисуйте в Figma или Sketch.
В упрощенном виде пользовательские сценарии могут выглядеть следующим образом:
Раскрыть
Неавторизованный пользователь хочет попасть в систему. Пользователь вводит логин (в виде e-mail) и пароль (только латинские буквы и цифры). Если они верны и пользователь имеет право на вход, он входит в систему, иначе показываем ошибку: «Неверный пароль» или «Такого пользователя нет. Зарегистрироваться здесь»
Как читают Feature Description?
Каждая категория пользователей может почерпнуть из требований полезную информацию для себя. И поэтому очень важно иметь в виду, что требования будут читать разные люди:
- Разработчики — Им важно знать, зачем нужна фича, какой вопрос она решает. Для того, чтобы не тратить потом время на исправления, разработчикам нужно предоставить полный список всех сценариев, а также обратить внимание на Corner cases. Если вовремя сообщить разработчику о том, что мы потом добавим, например, платежи картой МИР, он сможет предусмотреть эту возможность на уровне архитектуры. Таким образом, можно значительно сократить затраты, избежав переделок.
- Тестировщики, QA — Ожидают от вас получить данные о частотности сценариев, чтобы проверять в первую очередь самые критичные. Также им важны четко описанные Corner Cases. Для проверки нужно указать различия сценариев в зависимости от локализации, а также четко определить все пределы — максимальную длину имени, максимальное количество машин в заказе и т.д. Для инженеров нужно описать реакцию на возможные внешние изменения (пользователь переключился, вышел, закрыл окно) и принять базовое состояние для работы приложения. Это необходимо, чтобы не сломалась логика бизнес процесса. Также очень важны требования к производительности и отказоустойчивости.
- DevOps и Datacenter Operations— Им нужно знать, с какими компонентами работает продукт, какая инфраструктура для него требуется, сколько ресурсов будет использоваться софтом от серверных мощностей. DevOps должны знать, какие метрики мониторинга важнее других, как убедиться, что всё работает с их стороны.
- Технический писатель — Он должен четко понимать, какая проблема может возникнуть у пользователя, и как ее решить. Поэтому писатель тоже будет изучать сценарии использования, частотность сценариев, характеристики мокапов и тексты ошибок.
Если вы пишете требования к разработке, обязательно задайтесь вопросом — кто ваш пользователь, что он делает (или может делать), в каких условиях находится. Создайте схему его поведения, она поможет описать все аспекты требований.
При составлении документа нужно быть максимально краткими и не оставлять непонятных мест. Requirements в любом случае будут занимать несколько страниц. Его должны прочитать много человек, и нужно, чтобы он был читабельным.
Руководствуйтесь простым правилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
Заключение
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
→ Видео-запись всех лекций курса доступна на YouTube
Лекция про дорожную карту и требования для разработки:
Разговариваете со своими разработчиками на разном языке? Сроки все время едут? Качество продукта оставляет желать лучшего? Пишите в личку, обсудим что с этим можно сделать.
