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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ценность:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *