Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Привет, меня зовут Артур Селецкий, я 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 с ценностями проекта

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

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

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

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

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

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

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

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

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

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

EpicОценка ценностиПриоритет
Epic 1S3
Epic 2L1
Epic 3M2
Epic 4M2

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



7 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Чомусь склалося враження що пропонується підхід вже з кінця. Хтось вже переконав budget owner-ів, описав цілі проекту і бенефіти — отримав політичне «добро» на запуск — а тоді вже починається набивання проекту смисловими цілями, заміна одних іншими і т.д. В житті частіше інший підхід працює — описав, переконав, запустив, зробили — а що вже виявилося дійсно корисним узнаємо по факту використання. Напевно все-таки — практика — критерій істини, а не гіпотетичні розмірковування про цінності.

Интересно, успехом закончилось 29% проэктов, провалом 19%, а чем закончились остальные 52%?
И что в таком случае считается успехом и провалом, если превышение бюджета выделено в отдельную группу?

условным успехом, очевидно же

Доставляет идеальный лэйаут текста в мобильной версии доу. Вот бы все сайты такие были.

Это по дефолту, даже не надо статистику приводить.

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі