Март 19

Как определить и оценить ценность разрабатываемого ПО

Привет, меня зовут Артур Селецкий, я Co-Founder / Partner в It Network. Мы с коллегами занимаемся развитием сообщества бизнес-аналитиков и руководителей проектов в Украине. В этой статье я хотел бы поделиться своим опытом и подходом к определению ценностей разрабатываемого ПО и их оценке.

Проблема удовлетворенности разработанным ПО

По среднестатистическим данным исследования Standish Group:

29% IT-проектов завершились успехом;
52% завершились с превышением бюджета, не в срок или с реализацией меньшего функционала, чем ранее было запланировано;
19% IT-проектов закончились провалом.

Также Standish Group проанализировала, насколько часто используется функционал после внедрения разработанного программного обеспечения. Результаты шокирующие:

Источник

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

Я также часто в своей практике опираюсь на ценности, чтобы принимать решения. Именно поэтому каждый рабочий день я начинаю с мысли: «Чем я могу быть полезен моей команде, чтобы сегодня она принесла максимальную ценность на проекте».

Для того чтобы лучше понять, как этого достичь, следует ознакомиться с взаимодействием ценности с другими проектными сущностями. В этом нам поможет концептуальная модель по бизнес-анализу BACCM:

Концептуальная модель по бизнес-анализу BACCM. Источник

Модель состоит из шести ключевых концепций, которые приведены ниже в таблице.

Изменения	Для того, чтобы достигать поставленных целей, удовлетворять потребности заинтересованных лиц, необходимо проводить изменения.
Потребности	проблемы и возможности, которые вызывают изменения, являются стимулом действовать для заинтересованных лиц; требуют решения; разрушают или повышают ценности.
Заинтересованные лица	Группа или человек с учетом их: потребностей; воздействия и влияния на изменения; отношений к решению.
Решение	Выбор способа действовать, который: должен удовлетворять потребности; учитывать сложившийся контекст (ситуацию); соответствовать заинтересованным сторонам.
Контекст	Обстоятельства, оказывающие влияние, на которые оказывается влияние и которые обеспечивают понимание изменения.
Ценность	Потенциальная или реализованная стоимость, значимость или полезность чего-либо: для заинтересованных сторон; в конкретной ситуации (контексте); для удовлетворения потребностей.

Виды ценностей

Для себя я выделяю два вида ценностей:

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

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

Визуализация ценностей корпоративного портала

Определение ценностей

Определение ценностей — это непрерывный процесс на протяжении всего жизненного цикла проекта или продукта. Для определения ценностей привлекаются все заинтересованные лица, которые принимают участие в проекте. Определение ценностей начинается из определения целей проекта или, другими словами, поиска ответа на вопросы:

Почему это необходимо разрабатывать?
Какая польза от этого?

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

Пример цели внедрения корпоративного портала: «Автоматизировать и консолидировать накопление экспертных знаний сотрудников путем создания корпоративной базы знаний».

Ценность:

сохранить экспертный опыт сотрудников
сократить времени поиска информации;
повысить вовлеченности сотрудников компании.

Далее цели должны быть декомпозированы на высокоуровневые концептуальные требования (epic), которые соотносимы с проектными целями и их ценностями. В свою очередь epic должны быть декомпозированы на более детальные составляющие (story), которые в свою очередь также должны быть соотносимы с ценностями epic. Таким образом, каждое наше требование, каждая задача, выполняемая в рамках проекта, должна сопоставляться с ценностями проекта. Чем выше ценность выполняемой задачи, тем выше будет приоритет ее выполнения.

Следующий рисунок отображает соотношения ценностей задач с ценностями проекта:

Соотношения ценностей задач с ценностями проекта

Когда заказчики приходят с новыми требованиями, я всегда определяю, насколько новое требование соотносится с целями и ценностями проекта. Если ценность требования (epic или story) не соотносится с ценностями проектных целей, следует задуматься над вопросами:

Действительно ли стоит реализовывать это?
Какую пользу от этого получать пользователи?
Почему это не соотносится с нашими проектными целями?

Этот рисунок отображает пример соотношения ценности epic с ценностями проекта:

Пример соотношения epic с ценностями проекта

Оценка ценностей

На старте некоторых проектов (к сожалению, не во всех проектах это можно сделать) мы собирались со стейкхолдерами и выполняли следующие действия:

Определение целей проекта.
Определение ценностей по каждой цели проекта.
Оценивание ценностей по каждой из цели проекта.
Определение приоритетов по достижению целей.

При определении целей я использую два простых правила:

цель должна основываться на ценностях;
цель должна быть достижима.

Для определения ценностей, как отмечал я выше, ищем ответы на два вопроса:

Почему это необходимо разрабатывать?
Какая польза от этого?

Часто использую подход «покер планирования» из гибких методологий для оценки ценностей. Ранжирование ценностей происходит по так называемых размерах майки: S, M, L, XL, XXL.

Цель	Ценности	Оценка
Цель 1
	Ценность 1	S
	Ценность 2	L
Цель 2
	Ценность 1	L
	Ценность 2	XL

Не сложным путем, основываясь на весе или размере ценности, вывожу приоритет достижения каждой из цели. Такой же подход использую для определения приоритетов выполнения epic и story.

Epic	Оценка ценности	Приоритет
Epic 1	S	3
Epic 2	L	1
Epic 3	M	2
Epic 4	M	2

В случае, если оценка ценности равна между собой (Epic 3 = Epic 4), команда определяет самостоятельно, какой еpic первый брать в работу. Не стоит забывать, что все в мире меняется, и ценности необходимо пересматривать и переоценивать на протяжении всего проекта.

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

Гармонии вам и процветания.