Вы должны определить стратегию, в которой есть диагностика текущей ситуации, всеобъемлющий план достижения вашей миссии и видения, а также набор действий для их достижения. Если у вас есть действительно отличная миссия, видение и стратегия для команды, вы можете перейти к разбиению своей стратегии на действенную дорожную карту с целями и ключевыми результатами. Дорожные карты должны состоять из ваших целей и ключевых результатов, а также списка функций, которые вы планируете создать для достижения ваших ключевых результатов.
Отличное исполнение — это поиск наиболее эффективного пути доставки продукта. Это включает в себя навигацию по следующим этапам: запуск, пробная версия, запуск и ретро.
Таким образом, начиная с начального этапа, цель начального этапа состоит в том, чтобы создать общее понимание требований к продукту и ключевых вех. Так что запланируйте стартовую встречу с вашей командой и пройдите PRD. Позвольте вашей команде обсудить проблему клиента, которую вы решаете, целевую метрику, которую вы пытаетесь увеличить, и пройдитесь по требованиям к продукту, которые вы хотите, чтобы команда создала.
Структура спецификации требований к программному обеспечению обычно представляла собой разновидность следующей структуры:
- Цели (бизнес-цель, бизнес-процессы и то, как продукт будет использоваться в этом контексте, пользователи программного обеспечения и взаимодействие с другими системами)
- Функциональные требования (заявление о функциональности, которое можно рассматривать как договор с заказчиком)
- Нефункциональные требования (производительность, доступность, удобство использования, безопасность и т. д.)
- Приложения (используются для сбора любой подробной информации, такой как диаграммы UML, список вариантов использования, модели данных и другие соответствующие сведения)
Существует стандарт SRS , разработанный IEEE, Стандарт IEEE 29148-2018, в котором обсуждается ряд тем, которые следует учитывать при создании ТЗ:
а. Функциональность: что должно делать программное обеспечение?
б. Внешние интерфейсы: как программное обеспечение взаимодействует с людьми, аппаратным обеспечением системы, другим оборудованием и другим программным обеспечением?
в. Производительность: какова скорость, доступность, время отклика, время восстановления различных программных функций и т. д.?
д. Атрибуты: каковы соображения переносимости, корректности, ремонтопригодности, безопасности и т. д.?
е. Ограничения проекта, накладываемые на реализацию: существуют ли какие-либо требуемые действующие стандарты, язык реализации, политики целостности базы данных, ограничения ресурсов, операционная среда (среды) и т. д.?
Функциональные требования часто написаны через сценарии или варианты использования на естественном языке или в любом согласованном формате. В двух словах, варианты использования — это методология, позволяющая фиксировать, моделировать и определять требования к системе. Вариант использования определяется как список действий или шагов, определяющих взаимодействие между ролью и системой для достижения заранее определенной цели. Это может быть человек или другая внешняя система.
Концепция вариантов использования была введена в 1987 году Якобсоном, который описал, как эта методология использовалась в Ericsson для сбора и спецификации требований к системе с использованием методов текстового, структурного и визуального моделирования для управления объектно-ориентированным анализом и проектированием.
Вариант использования — это сценарий, который содержит следующие элементы:
- Заголовок
- Описание
- Актеры
- Триггер(ы)
- Предварительные условия
- Постусловия
- Нормальный поток действий
- Альтернативные потоки
Часто варианты использования дополнялись UML как языком моделирования, например:
В 1999 году Кент Бек придумал термин "Истории пользователей" для описания функций продукта. Он описал, что история пользователя рассказывается с точки зрения пользователя относительно того, что он или она хочет иметь, а не того, что система может сделать для него. Таким образом, представление полностью перешло от продукта к пользователю, и пользовательские истории стали стандартом де-факто для требований во всех гибких фреймворках.
Пользовательские истории следуют стандартному формату, основанному на роли-действии-выгоде (или «кто-что-почему»).
Важно помнить о следующих хороших практиках :
- Роль («кто») представляет тип пользователя. Он должен быть максимально конкретным. Система может быть ролью, но команда разработчиков или менеджер по продукту не могут проектировать систему для собственной выгоды.
- Действие («что») описывает поведение системы. Обычно оно уникально для каждой пользовательской истории. Действия желательно писать в активном залоге (покупателю нужно купить книгу, а не «книгу нужно купить»).
- Необходимо указать причину или выгоду («почему?») (иначе возникает вопрос, зачем вообще разрабатывается эта фича). Несколько пользовательских историй могут иметь одно и то же преимущество. Выгода может быть для других пользователей или клиентов, а не только для пользователя в каждой конкретной истории.
Пользовательские истории записываются в определенном формате, который вы можете увидеть выше на рисунке.
Примеры:
• Как [менеджер], я хочу [сгенерировать отчет], чтобы [я мог понять, каким отделам требуется больше ресурсов].
• Как [клиент], я хочу [получить SMS-сообщение, когда товар будет доставлен], чтобы [я мог сразу же пойти и забрать его].
Для каждой пользовательской истории также определен критерий приемлемости, так что правильность реализации пользовательской истории подтверждается прохождением приемочного теста, основанного на Критерии приемки.
Ниже приведен примерный критерий принятия для примера снятия денежных средств клиентом User Story. Например,
Критерий приемки 1:
Учитывая, что учетная запись является кредитоспособной
- И карта действительна
- И в диспенсере есть наличные,
Затем убедитесь, что учетная запись списана
- И обеспечить выдачу наличных
- И убедитесь, что карточка возвращена.
Учитывая, что учетная запись переполнена
- И карта действительна
Затем убедитесь, что отображается сообщение об отклонении
- И убедитесь, что наличные деньги не выдаются
- И убедитесь, что карточка возвращена.
Дополнительно: как писать пользовательские истории
Если у команды есть большая пользовательская история, которая не может быть доставлена в соответствии с определением в рамках одной итерации или достаточно велика, чтобы ее можно было разделить на более мелкие пользовательские задачи / пользовательские истории, то она описывается в виде эпика (epic) - серии пользовательских историй с более широкой стратегической целью.
Пример эпика:
Выбор маркетинговых кампаний
1: Как вице-президент по маркетингу, я хочу проанализировать эффективность исторических рекламных кампаний, чтобы выявлять и повторять прибыльные кампании.
1a: Как вице-президент по маркетингу, я хочу выбрать временные рамки для анализа эффективности прошлых рекламных кампаний, чтобы …
1b: Как вице-президент по маркетингу, я могу выбрать, какой тип кампаний (прямая почтовая рассылка, телевидение, электронная почта, радио и т.д.) включать при анализе эффективности прошлых, чтобы …
1в1: Как вице-президент по маркетингу, я хочу видеть информацию о прямых рассылках при просмотре исторических кампании, чтобы...
1в2: Как вице-президент по маркетингу, я хочу видеть информацию о телевизионной рекламе при просмотре исторических кампаний , чтобы...
1b3: Как вице-президент по маркетингу, я хочу видеть информацию о рекламе по электронной почте при просмотре исторических кампаний
так что... и так далее для каждого типа рекламной кампании
Инициативы
Инициативы - это сборники эпосов, которые ведут к общей цели. В традиционном подходе дорожная карта продукта выражена и визуализирована в виде набора инициатив, построенных по временной шкале.
Темы (Theme)- это конструкция для определения того, что важно для ваших клиентов в настоящее время. Они позволяют команде сосредоточиться на ключевых целях:
Пользовательские истории не живут в вакууме. Они должны быть привязаны к карте пути пользователя и его конечной цели.
Путь пользователя — это поток или сквозное изображение действий пользователя для перехода из одного состояния в другое или из текущего состояние до конечной цели. Эти шаги и действия построены вместе для создания карты пути пользователя. Карта пользовательских историй - инструмент, разработанный Джеффом Паттоном, который он описывает в своей книге User Story Mapping . Как утверждает Паттон, «у вашего программного обеспечения есть основа и скелет — и ваша карта показывает это».
Карты историй помогают планировать и расставлять приоритеты, визуализируя решение в целом, а не просто через набор отдельных пользовательских историй. Картирование историй не предназначено для создания историй или создания плана выпуска — оно предназначено для понимания целей клиентов и задач, которые необходимо выполнить. Всякий раз, когда вы начинаете путешествие пользователя, начните с установки цели путешествия с точки зрения пользователя.
Акторы — это все пользователи (различные роли) и системы, взаимодействующие с продуктом, например, такие как покупатель, поставщик, менеджер по товарам, система управления контентом и т. д. для платформы электронной коммерции.
Каждое путешествие проходит через разные этапы, точки соприкосновения — это точки, в которых акторы взаимодействуют или общаются с продуктом.
На следующей диаграмме показан шаблон карты пути пользователя со всеми основными элементами, такими как конечная цель и этапы, различные точки взаимодействия, действующие лица и их конечные цели, а также поток от начала до конца.
Хорошие карты пути пользователя обычно очень детализированы, в них рассматриваются даже самые мелкие действия, движения и задачи. Они помогают раскрыть возможности для устранения препятствий и болевых точек. Эти препятствия и болевые точки в конечном итоге становятся основой для ваших тем и подтем.
Функциональные возможности . Функциональные возможности включают функциональные элементы или функции платформы, такие как поиск, просмотр, добавление, удаление и т. д.
Технические возможности . Технические возможности также называют нефункциональными возможностями. Эти возможности не соответствует функциональному требованию, такие как безопасность, управление данными, хостинг и так далее.
На следующей диаграмме показано, как возможности должны быть сопоставлены с пользовательским путем:
Мы должны пересмотреть путь пользователя для нарезки и отображения MVP на основе по заданным приоритетам всех функциональных и технических возможностей и точек соприкосновения. Чтобы получить визуальное представление о приоритетах, можно добавлять указание на все возможности и точки соприкосновения на карте пути пользователя следующим образом:
В дополнение к полученным важным отзывам клиентов, важные внутренние организационные элементы помогут настроить команду на непрерывное обучение. Некоторые примеры организационного совершенствования и обучения включают ответы на следующие вопросы:
- Можем ли мы сократить время от определения функции до передачи ее клиентам?
- Какие препятствия стоят на нашем пути к производству?
- Можем ли мы настроить инфраструктуру доставки для частых выпусков?
- Можем ли мы получить доступ к реальным данным клиентов, которые доступны с первого дня?
- Есть ли у нас стабильная среда для клиентского тестирования?
- Определили ли мы наших пилотных клиентов? Каковы сроки их найма? Какие коммуникации и ожидания должны быть установлены?
- Получите согласование многих мнений о том, каким может быть первый выпуск (и последующие выпуски) среди широкой группы заинтересованных сторон (например, продукт, распространение, маркетинг, финансы).
- Определите гипотезы, которые вы хотите проверить, которые могут привести к развороту в направлении
- Сведите к минимуму неопределенность в отношении идеи продукта, предоставив сквозную часть продукта как можно раньше небольшой группе клиентов для обратной связи.
Документ с требованиями к продукту содержит проблему, цель и решение в одном месте.
PRD бывают разных форматов и размеров, но мне нравится иметь следующую структуру:
- заинтересованные стороны: перечислите всех ключевых заинтересованных сторон, вовлеченных в продукт, вместе со ссылками на любые важные документы. Это позволяет любому, кто читает PRD, легко узнать, кто ы вовлечены и получить доступ ко всем важным ссылкам.
- проблема: в чем проблема клиента, как мы узнаем, что это проблема, и почему так важно, чтобы мы решили эту проблему?
- цель: этот раздел должен быть вашей гипотезой. Вы хотите обобщить свою целевую метрику: мы можем увеличить целевую метрику, если создадим эту функцию. Например, мы можем увеличить коэффициент активации, который представляет собой процент новых подписчиков, которые снова посещают приложение через семь дней, добавив экран «выберите темы для персонализации своей ленты». После гипотезы вы должны перечислить ключевые показатели. Опять же, вы должны перечислить его как выходные метрики, которые являются вашими целевыми метриками, и входные метрики, которые являются метриками, которые вы можете продвигать и перемещать, чтобы увеличить свою целевую метрику. Таким образом, в нашем примере выходом является коэффициент активации, а входными данными могут быть количество пользователей, посетивших ленту выбора тем, количество выбравших тему, количество выбранных тем и количество пользователей, которые фактически пингуются во время их первого сеанс после открытия приложения.
- требования: полезно писать требования в виде пользовательских историй
- дизайн
- примерный план запуска: какие пользователи будут пользоваться функцией, как выглядит опыт тестирования и контроля
- часто задаваемые вопросы.
Пример PRD можно посмотреть тут.
Унифицированный язык моделирования (UML) обеспечивает визуализацию бизнес-процессов и архитектуры программного обеспечения. Это графический язык, обеспечивающий стандартный способ описания функциональности и создания модели системы, охватывающей концептуальные идеи.
Хотя в UML было признано, что разработка программного обеспечения обычно выполняется итеративным и инкрементальным способом, в эту методологию не встроен итеративный процесс. Диаграммы должны обеспечивать достаточный уровень детализации в статическом виде, чтобы быть информативными, поэтому большая часть работы по определению требований должна быть выполнена заранее. Это не касается поэтапного и итеративного характера доставки программного обеспечения.
В Agile конструкция, которая находится в центре определения требований, — это пользовательская история. Пользовательские истории — это короткие простые описания функции, рассказанные с точки зрения человека, которому нужны новые возможности, обычно пользователя или клиента системы. Каждая пользовательская история выражает одну очень конкретную потребность пользователя. Его можно рассматривать как минимальное требование, ориентированное на потребности пользователя.
Каждая пользовательская история определяет ценность, которую эта функциональность предоставляет клиенту. Критерии успеха пользовательской истории определяются в форме утверждений, называемых критериями приемки.
Картирование историй — ценный инструмент для разработки программного обеспечения. В этом процессе команда исследует жизненный цикл пользовательской истории, начиная с возможностей и продвигаясь глубже к открытию, упорядочивая эти пользовательские истории в минимально жизнеспособном продукте (MVP) и последующих выпусках. Этот метод позволяет команде составить «общую картину» доставки продукта и упорядочить ее по выпускам, начиная с MVP.