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

В то же время, когда вы сдаете сделанную работу заказчику и он говорить вам: «это не то, что я имел в виду», — то такие ситуации уже не вызывают смех. Наоборот, часто они связаны со спорами, проблемами, возможно, со срывом сроков, потерей денег и можно представить себе еще много разных неприятных последствий. Странно, эффект тот же, а какая разница в результатах? 🙂

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

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

Вы пришли в ресторан и видите в меню следующую фразу: «Основное блюдо идет с супом или салатом и хлебом». В итоге вы должны ломать голову и гадать о том, что вы получите.

  • (Супом или Салатом) и Хлебом?
  • (Супом) или (Салатом и Хлебом)?

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

Лично я являюсь активным сторонником работы с требованиями, сформулированными с точки зрения конечных пользователей. «Истории Пользователей» (User Stories) являются простым, удобным и одновременно мощным инструментом записи того, что должна делать система. На самом деле система неживая и никому ничего не должна, а вот живые люди всегда хотят получить что-то от вашего продукта, чтобы удовлетворить свои нужды.

Формат простой: «Как <КТО>, я хочу <ЧТО>, для того <ЧТОБЫ>» (As <user type>, I want <to do something>, so < value>). Звучит предельно просто. Прежде чем записать что-то в список требований к системе, подумайте о том, кому нужна эта функция, и какую пользу он получит от ее использования.

Конечно, «Истории Пользователя» не являются «Серебряной Пулей» ;-). Они хорошо помогают формулировать новые требования и являются хорошими элементами Бэклога Продукта. Как и любой инструмент, чтобы быть полезным, Истории Пользователя требуют практического опыта и понимания нескольких основных концепций, а также знание разных полезных практик из опыта применения других.

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

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

Испорченный телефон или как исправлять ошибки коммуникации требований
Tagged on: