Как оформить PRD (документ, отражающий требования к продукту) | Umbrella IT

Как оформить PRD (документ, отражающий требования к продукту)

 

PRD: что это за документ, как он выглядит, и можно ли обойтись без него?

 

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

Начиная какой-либо проект, мы все уверены в том, что наша идея безукоризненна, а  новому продукту (или услуге) просто суждено занять достойное место на рынке.

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

Ищите надежного партнера для реализации  своего IT проекта? Свяжитесь с Umbrella – мы обеспечим вашему продукту успех!

Одним из шагов на пути к успеху нового проекта является определение требований к вашему будущему продукту: описание того, каким вы его видите.

 

Важно:

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

И не менее важно: вы  и команда понимаете их одинаково.

 

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

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

 

Что такое  PRD?

(от англ. Product Requirements Document – документ с требованиями к продукту)

Описание, включающее все требования к определенному продукту и отражающее, как продукт будет выглядеть, и как он будет работать . Требования могут быть представлены как в форме одного документа, так и в форме комплекта документов или набора артефактов (макеты, схемы, диаграммы, документы).

 

Кто составляет PRD?

Требования в таком документе отражают видение и ожидания заказчика в отношении продукта. Если у заказчика есть специалисты, которые имеют представление о том, как оптимально оформить требования, то этим занимается именно сторона заказчика. Но если подобного опыта нет, то оформление требований может взять на себя команда разработчиков (PM, тестировщик или любой член команды).

 

Для чего нужен PRD?

  • и заказчик, и каждый член команды разработчиков должны знать требования к продукту. При этом все они должны иметь идентичное представление и однозначно понимать, каким должен быть готовый продукт.
  • информация передается один раз для всех. Нет необходимости уточнять и повторять требования для каждого отдельно. Соответственно, экономится время, которое можно потратить не на бесконечные объяснения, а на фактическую работу над продуктом.
  • вся информация зафиксирована письменно или графически. Таким образом исключается риск путаницы и недопонимания.
  • информация всегда сохранится в доступном и понятном виде и в полном объеме, даже если по каким-либо причинам в рамках проекта изменится система работы с требованиями (например, проект покинет специалист, ответственный за их составление).

 

Исходя из собственного опыта можем подтвердить, что требования к продукту помогают разумно распределить время и усилия и исключить большинство рисков, если они:

  • четко и однозначно сформулированы;
  • оформлены в удобной и простой форме;
  • согласованы между заказчиком и командой разработчиков в самом начале проекта в том объеме, который необходим для старта проекта (впоследствии такие требования будут дополняться по мере разработки).

 

Что  включает в себя PRD?

Содержание и объем требований напрямую зависят от сложности проекта.

Например:

  • для мобильных приложений необходимы прототипы (возможно интерактивные), так как такие приложения характеризуется  активным взаимодействием пользователя с устройством, и разработчикам нужно изначально представлять и понимать все процессы;
  • для чат бота (например, JivoSite) достаточно функционального описания, прототип, скорее всего, будет излишним;
  • для ERP-систем планирования ресурсов предприятия обязательно нужна максимально полная информация о будущем продукте, которая может включать в себя прототипы, пользовательские истории, диаграммы данных и т.д.

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

Для всех проектов независимо от сложности и длительности, требования к продукту должны включать в себя информацию о том:

  • с какой целью и для кого создается продукт;
  • как будет выглядеть продукт (помните, что проект не обязательно начинается с красивого дизайна, на первом этапе могут использоваться прототипы или эскизы, и этого будет достаточно);
  • как будет работать продукт (схема взаимодействия пользователя с продуктом);
  • как будет измеряться и по каким критериям будет оцениваться успешность продукта.

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

 

ex1

 

Как составить PRD?

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

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

  • сформулируйте цель проекта: для кого создаем продукт, какую проблему решаем, что продукт будет делать;

Важно: цель должна быть сформулирована четко и кратко.

Хороший способ проверить себя: можете ли вы сформулировать цель так, чтобы она вписалась во временные рамки “презентации для лифта”, т.е. в 30 секунд.

Например: цель нового проекта –  создание приложения, при помощи которого можно в течение Х дней (в зависимости от территориального расположения) получить по почте заверенный качественный перевод документа об образовании.

  • определите целевую аудиторию для вашего продукта

В нашем примере это люди, выезжающие за рубеж для продолжения учебы или устройства на работу, или люди, получившие образование за рубежом, которым необходимы документы об образовании на родном языке.

  • составьте перечень компонентов продукта

Например:

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

Например:

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

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

После этого выбирается формат загрузки оригинала документа об образовании – оригинал загружается; менеджер обрабатывает заказ и передает его в работу переводчику.

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

Например:

Вы планируете в недалеком будущем добавить в свое приложение новую услугу – отправку почтой или курьером нотариально заверенного перевода. Укажите это в своих требованиях к продукту. Тем самым вы поможете разработчикам заранее учесть все, что может понадобиться для внедрения такого нового сервиса, и им не придется в будущем переделывать готовое приложение.

 

Существуют ли требования к требованиям?

Поскольку требования к продукту нужны не ради самих требований, они должны быть:

  • понятными (формулируйте свои требования простым языком так, чтобы тому, кто будет с ними работать не пришлось разгадывать загадки и распутывать клубки причинно-следственных связей);
  • читабельными (подумайте о том, кто будет работать с вашим документом (в какой бы форме вы его ни предоставляли): обрадовались бы вы, если бы вам вручили схему, набросанную на листике из блокнота, или документ со 150 страницами сплошного текста?);
  • полными, но не переполненными излишней информацией (здесь можно было бы снова упомянуть о 150 страницах текста, но нужно учитывать, что для крупномасштабных проектов такой объем может оказаться вполне обоснованным. Чтобы такой объемный документ было легко читать, заменяйте текст картинками и схемами там, где это возможно);
  • разумными (просто помните, что вы работаете ВМЕСТЕ с командой разработчиков, а не проверяете их на способность справляться со сложностями. Постановка нереальных задач изначально ставит под угрозу успешность и соблюдение сроков реализации проекта).

 

tips and tricks

 

Несколько советов

  • описывайте каждое требование отдельно, либо разбейте их на логические группы: не нужно собирать все требования в одном пункте. Если они взаимосвязаны, сгруппируйте их, например, в соответствии с функционалом. Такое разделение облегчит восприятие и поможет правильно расставить приоритеты.
  • соблюдайте последовательность: у документа должна быть простая структура, чтобы его было легко читать. Если продукт разбит на модули, такие модули стоит расположить в логической последовательности: например, если продукт создается пользователем, то сначала нужен модуль пользователя, а потом уже модуль продукта.
  • давайте четкие указания: старайтесь избегать таких фраз, как “если необходимо”, “по возможности”.
  • исключите любые неясности: старайтесь избегать слов “примерно”, “и так далее”. Любые используемые определения должны иметь однозначное значение: например, слово “удобный” может означать разное для разных людей.
  • нужно рассуждать не о том, КАК сделать, а о том ЧТО нужно сделать.
  • храните все требования в одном месте (например, мы используем Trello): должна быть одна точка входа для требований, и все участники проекта должны знать о том, где их найти.
  • если над требованиями работают несколько человек, определите одного человека, который будет отвечать за согласование, иначе потеряется целостность.

 

Как выглядит PRD?

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

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

Двумя наиболее распространенными подходами в сфере разработки ПО являются каскадная модель (Waterfall)  и гибкая методология разработки (Agile).

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

В рамках такой модели требования к продукту определяются в самом начале проекта, в полном объеме, и разработка не начнется, пока они не будут готовы. Скорее всего это будет достаточно объемный документ или комплект документов (артефактов).

Мы же хотим остановиться более подробно на второй модели, которую мы выбираем для работы с нашими заказчиками. Гибкая методология разработки Agile предполагает, что проект разбит на несколько коротких циклов длительностью две-три недели каждый (итерации), и каждый из которых представляет собой мини-проект со всеми необходимыми этапами реализации.

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

Какой бы метод вы ни выбрали – подойдите к этому РАЗУМНО.

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

 

ppl

 

Как мы работаем?

Все начинается с общения: это может быть как устное общение (телефон, Skype, личная встреча), так и письменное. Но в любом случае результаты такого общения фиксируются в письменной форме.

Мы регулярно общаемся с вами, выясняем ваше видение продукта. Мы не ставим вас в рамки определенного шаблона, скорее работаем так, как удобно вам. Со своей стороны, на основании предоставленной вами информации мы параллельно составляем функциональную карту.

Функциональная карта (mind map) отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты. В традиционном формате такая карта напоминает карту сайта.

Мы же вкладываем в это понятие несколько иную логику: наша функциональная карта – это функции, сгруппированные по модулям в соответствии с логикой работы, а не страницы.

 

Пример функциональной карты:

map 1

 

В результате такая карта становится отправной точкой для дальнейшей работы (то есть является составной частью PRD). Мы согласовываем функциональную карту с клиентом и работаем над проектом, используя ее в качестве основы.

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

Помните, можно вдоль и поперек изучить BABOK (профессиональный стандарт в сфере бизнес-анализа) и отобрать все самые лучшие практики и инструменты, связанные с требованиями к продукту, но они могут просто оказаться избыточными в вашей конкретной ситуации.

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

  • прототипы интерфейсов (wireframes): структурные схемы страниц;

 

Пример прототипа интерфейса:

ex 3

 

  • сценарии использования (use cases): описания или UML диаграммы, которые обеспечивают понимание того, как пользователь будет взаимодействовать с системой (то есть какие действия будет совершать пользователь в системе, и как она будет реагировать);

Пример сценария использования:

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

  • Пользователь регистрируется в приложении, используя email;
  • Пользователь выполняет вход в свой аккаунт;
  • Если пользователь забыл пароль, он восстанавливает его (функция “Забыли пароль?”);
  • Пользователь видит карту со своим текущим местоположением;
  • Пользователь просматривает предлагаемые языки перевода и выбирает нужную языковую пару;
  • Пользователь просматривает предлагаемые форматы и способы получения перевода и выбирает то, что подходит ему;
  • Пользователь выбирает формат загрузки оригинала и загружает документ;
  • Пользователь получает расчет стоимости и подтверждение сроков исполнения заказа;
  • Пользователь выбирает способ оплаты;
  • Пользователь проверяет статус выполнения заказа;
  • Пользователь получает уведомление о готовности заказа, загружает перевод и оплачивает заказ.
  • ER диаграммы: отображают структуры данных и связи между ними, зачастую становятся прототипами для создания баз данных.

 

map again

 

Таким образом, мы собираем и регулярно обновляем всю информацию о требованиях к продукту и о самом продукте. Все вышеуказанные диаграммы и описания формируют своего рода PRD, на который разработчики и дизайнеры ориентируются непосредственно при разработке продукта.

С какой формой PRD вам удобнее работать – решать только вам. Просто придерживайтесь основных принципов формулирования требований к продукту:

  • простота формулировок;
  • удобная для восприятия форма;
  • полнота информации;
  • выполнимость;

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

 

Если у вас остались вопросы  – свяжитесь с Umbrella прямо сейчас! Мы будем рады поделиться с вами своим опытом и знаниями!

 

Фото: Shutterstock.com


Ещё

  • Как выжить после GDPR: самый прикладной чек-лист на соответствие регламенту
    Как выжить после GDPR: самый прикладной чек-лист на соответствие регламенту
    В нашей предыдущей статье, посвященной GDPR, мы сделали лирическое отступление о том, кого затронет новый регламент и во сколько обойдется его нарушение. Мы обещали рассказать, как продолжить гнуть свою линию и не попасть под санкции. И мы всегда держим слово. Наши специалисты подготовили самый прикладной чек-лист на соответствие GDPR. Для удобства он разбит на 5 …
  • Как выжить после GDPR: что делать и кто виноват
    Как выжить после GDPR: что делать и кто виноват
    После 4 лет ожесточенных дебатов европейский парламент принял регламент по защите персональных данных — GDPR. Документ экстерриториален. Это значит, что где бы физически ни находилась ваша компания, если вы сотрудничаете с резидентами ЕС — вам придется уважать европейский закон. Мы запускаем серию статей, посвященных GDPR. В первой части мы пробежимся по основным положениям регламента, выясним, …
  • CEO компании Umbrella на Agile Days 2018: рецепт эффективного и контролируемого роста команд разработчиков
    CEO компании Umbrella на Agile Days 2018: рецепт эффективного и контролируемого роста команд разработчиков
      22-23 марта в московском Центре Международной Торговли прошла 12-я глобальная конференция по гибкому управлению процессами Ag;)le Days 2018. Одним из спикеров конференции стал основатель и CEO компании Umbrella Станислав Мешков. Мы попросили Стаса рассказать немного о том, как это было. Интервьюер: Привет, Стас! На конференции Ag;)le Days 2018 ты выступал с докладом: “Разработка: увеличь компанию, …