в облаке
Попробовать

Выявление требований: как проверять гипотезы

15.03.2014 17:32

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

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

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

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

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

  • Разработка хорошего теста для проверки гипотезы – это задание не для одного человека. Обсуждение должно вестись на уровне всех руководителей проекта, поэтому, во избежание недоразумений, текст должен быть прописан в простой и понятной форме.
  • Записывайте свои мысли в форме утверждений, то есть исключительно по существу вопроса. Это облегчит процесс создания самих тестов.
  • Определитесь с участниками (кто задействован), количественными переменными (что задействовано) и предположительными результатами (доказательствами).
  • Доказательства могут быть количественного характера (метрический результат) или качественного характера (доступный для наблюдения результат). Всегда стремитесь к измеримым результатам; метрика является абсолютным чемпионом в объективной интерпретации результатов теста.
  • Но самое важное, чтобы проверка гипотезы была тестируемой.

Простой процесс определения требований

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

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

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

Выводы

Система проверки гипотезы – это естественный способ для ее подтверждения или опровержения. Она пришла к нам из мира науки и представляет собой метод объективного определения достоверности неопределенных возражений. Путем определения, построения и распространения наименьшего возможного варианта продукта, который сможет пролить свет на саму гипотезу, нам удастся избежать нерационального использования ресурсов, выделяемых на разработку бесполезных продуктов.

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

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

--

Автор: Mats Wessberg

Оригинал статьи: http://re-magazine.ireb.org/issues/2014-[...]-learning-to-fly/think-like-a-scientist/

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

 

Еще интересные статьи на эту тему: