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

• Название: Гибкое управление проектами и продуктами
• Автор: Борис Вольфсон
• Жанр: Программирование
• Год: 2014
• ISBN: 978-5-496-01323-9

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

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

Начните применять на практике гибкие методологии, чтобы успешно управлять проектами и создавать продукты!

---

Определение приоритетов историй пользователя

I can’t get no satisfaction,
I can’t get no satisfaction.
‘Cause I try, and I try, and I try, and I try.
I can’t get no, I can’t get no.

The Rolling Stones

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

Рассмотрим более точную модель – модель удовлетворения потребностей Кано. Японский профессор Нориаки Кано (Noriaki Kano) предложил ее в работе «Привлекательное качество и необходимое качество» (Attractive Quality and Must-Be Quality) еще в 1984 году.

Разделим всю функциональность продукта на три категории в соответствии с удовлетворенностью пользователя и полнотой функциональности продукта.

Типы функций продукта

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

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

2. Линейные функции – чем больше и качественней они реализованы, тем больше доволен пользователь. К примеру, это долгая работа сотового телефона без подзарядки.

3. Привлекательные функции – функции, которые придают вашему продукту wow-эффект. В качестве примера можно рассмотреть эргономику и удобство использования (юзабилити) Apple IPhone.

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

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

Specific – точные и конкретные цели

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

Таблица 3.5.

Запись целей

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

Measurable – измеримые цели

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

Таблица 3.6.

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

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

Achievable – достижимые цели

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

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

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

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

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

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

Relevant – релевантные цели

Релевантность целей нужно рассматривать с двух сторон: релевантность для исполнителя и для компании. Релевантность (значимость) для исполнителя тесно связана с его мотивацией. Например, сотруднику, который любит изучать новые технологии, можно и нужно поручить исследовательский проект, а не рутинную работу. Когда команда понимает, что цель важна, усилия, которые она направит на ее достижение, будут заведомо больше усилий, направленных на «неважную» цель. Отмечу также, что букву R (и другие буквы аббревиатуры SMART) расшифровывают по-разному.

Time-bound – цели со сроком

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