Существенные и Несущественные требования

Одной из самых сложных вещей при создании простого продукта является определение того, какие возможности стоит реализовывать, а какие нет. Мы для этого использовали разделение требований на Существенные и Несущественные. Несущественные выносили за пределы версии 1.0.

Великолепный способ отсеять несущественные требования – это использовать простой фильтр. Если требование начинается со слов «было бы неплохо если…» или «было бы круто если…», то это обычно несущественное требование.

Во время разработки «Campfire» у нас было много «неплохих и крутых» требований. Отличный способ обработать их – это немедленно отложить их до версии 1.1. Это означает, что мы рассмотрим их уже после запуска продукта.

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

Приоритезация требований – какой способ самый лучший?

Я только что прочитал интересную запись Джейсона в блоге «37 signals» «Существенные и Несущественные требования».

Он описывает процесс приоритезации требований, через который прошла его команда, когда разрабатывала небезызвестный продукт Campfire, выпущенный недавно. В сущности, он вводит разделение требований на «Существенные» (то, что должно быть) и «Несущественные» (неплохо/круто было бы).

Это подводит нас к вопросу, как лучше всего расставлять приоритеты для требований? И вообще существует ли «наилучший» путь? Как на самом деле вы решаете, какие требования отнести к «Существенным» а какие нет?

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

Другими словами, существенные требования определяются, в зависимости от важности источника (автора) этих требований! Разве это лучший способ?

В теории, капитал должен распределяться в соответствии с максимальной Окупаемостью Инвестиций (ROI). Окупаемость инвестиций может быть определена разными путями – но обычно она определяется в финансовых терминах, таких как NPV (net present value - Чистый дисконтированный доход).

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

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

Как только мы сможем оценить дополнительные доходы для нас и пользу для клиентов, которые принесет каждая реализованная возможность (каждое требование), мы сможем составить список в соответствии с этими приоритетами. Звучит просто, да? Нет!

Самая первая проблема – Каким образом оценивать доходы от каждой реализованной возможности (каждого требования)?

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

Другая распространенная проблема – это Стратегические нужды. Что если требование может принести высокий доход, но не соответствует «Стратегии компании/продукта»? Эти самые нужды обычно определяется кем-нибудь из начальства и это обычный способ, с помощью которого оно вносит свой вклад в расстановку приоритетов.

Еще одна распространенная проблема – это Технически возможности. Что если требование может принести высокий доход, но у компании нет необходимого опыта (экспертизы) для его реализации? Эти возможности определяются обычно руководителем разработки/производства. Это самый распространенный способ, с помощью которого руководители команды разработчиков способствуют расстановке приоритетов.

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

Есть два основных фактора, которые нужно учитывать: 1) Доход для компании, и 2) Польза для клиентов, но есть и другие менее явные факторы, которые также нужно принимать во внимание.