Оффлайн
- Регистрация
- 21.07.20
- Сообщения
- 40.408
- Реакции
- 1
- Репутация
- 0
Привет, Хабр! Продолжая серию публикаций по
Оглавление курса
— Продолжение следует
Иногда кажется, что задача для разработчика просто очевидна! Но не стоит слишком сильно полагаться в вопросах постановки задачи на здравый смысл. Для любой, даже самой простой задачи возможны разночтения, потому что людям свойственно жить в мире собственных иллюзий. Например, в Республике Куба считается, что стены должны быть яркими и пестрыми, и если даже заказчик попросит покрасить стены в белый, работники могут добавить цветных пятен, потому что «так ведь красивее». То же самое касается и разработки.
Такой документ как требования помогает преодолеть «стену непонимания». Наличие требований позволяет создать одинаковое представление о том, что нужно сделать в продукте, какая именно должна быть фича.
Как строятся требования
Формируя требования к разработке, нужно нужно понимать, для какого пользователя разрабатываем продукт. Здесь очень полезны оказываются User Persona (мы уже говорили о них
Например, в приложении веб-форума могут быть определены следующие акторы:
● Администратор может всё, буквально все — в том числе назначать роли (персоны) другим пользователям
● Обычный пользователь может только оставлять сообщения
● Модератор может оставлять сообщения, удалять чужие сообщения, банить обычных пользователей
В случае с приложением для вызова такси, о котором мы периодически вспоминаем во время нашего курса, персонами могут быть пассажир, таксист и оператор.
Чтобы сформулировать адекватное требование, нужно составить документ который мы называем 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 обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
Заключение
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
→ Видео-запись всех лекций курса
Лекция про дорожную карту и требования для разработки:
You must be registered for see links
, сегодня мы обсуждаем требования к разработке. В этом посте речь пойдет о том, как продуктовый менеджер взаимодействует с разработчиками из R&D, зачем нужны требования, как правильно их сформулировать, и какие выводы из требований к разработке должны делать различные специалисты, включая самих разработчиков, менеджеров, QA и так далее. С другой стороны будущие и уже состоявшиеся разработчики узнают, что может (и вообще-то должен) предоставлять вам менеджер продукта. Все подробности — под катом.
Оглавление курса
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
You must be registered for see links
< — Вы здесь— Продолжение следует
Иногда кажется, что задача для разработчика просто очевидна! Но не стоит слишком сильно полагаться в вопросах постановки задачи на здравый смысл. Для любой, даже самой простой задачи возможны разночтения, потому что людям свойственно жить в мире собственных иллюзий. Например, в Республике Куба считается, что стены должны быть яркими и пестрыми, и если даже заказчик попросит покрасить стены в белый, работники могут добавить цветных пятен, потому что «так ведь красивее». То же самое касается и разработки.
Такой документ как требования помогает преодолеть «стену непонимания». Наличие требований позволяет создать одинаковое представление о том, что нужно сделать в продукте, какая именно должна быть фича.
Как строятся требования
Формируя требования к разработке, нужно нужно понимать, для какого пользователя разрабатываем продукт. Здесь очень полезны оказываются User Persona (мы уже говорили о них
You must be registered for see links
). 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 обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
Заключение
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
→ Видео-запись всех лекций курса
You must be registered for see links
Лекция про дорожную карту и требования для разработки: