Документ с требованиями к продукту

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

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

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

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

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

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

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

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

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