Гибкое управление проектами и продуктами - Борис Вольфсон

1. Как вы отнесетесь к наличию данной функциональности в продукте?

2. Как вы отнесетесь к отсутствию данной функциональности в продукте?

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

В качестве ответов опрашиваемому пользователю предлагаются следующие варианты ответов:

• нравится;

• ожидаю этого;

• все равно;

• могу смириться с этим;

• не нравится это.

После такого опроса можно проводить анализ результатов с помощью следующей таблицы (табл. 3.2).

Таблица 3.2.

Анализ результатов

В результате функции продукта разобьются на шесть категорий:

• A (attractive) – привлекательные;

• O (one-dimensional) – линейные;

• M (must-be) – обязательные;

• R (reverse) – обратные (ненужные);

• Q (questionable result) – сомнительный/противоречивый результат;

• I (indifferent) – безразлично.

Первые три категории для нашего анализа являются самыми интересными и дают более глубокое понимание требований по нашему продукту:

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

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

По завершении опроса необходимо подвести итоги, просуммировав ответы пользователей (табл. 3.3).

Таблица 3.3.

Суммы ответов пользователей

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

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

Владелец продукта должен ставить перед собой и командой четкие и понятные цели, для чего существует несколько критериев, которые собираются в английскую аббревиатуру SMART («умный») (табл. 3.4).

Таблица 3.4.

Расшифровка SMART

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

Таблица 3.5.

Запись целей

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

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

Таблица 3.6.

Измеримость целей

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

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

Недостижимые. При постановке таких задач заранее понятно, что исполнитель с ними заведомо не справится. Например, нельзя за день нарисовать 1000 качественных макетов для разных сайтов. Такие задачи перед подчиненными ставить нельзя.

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

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

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

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