Возможности — различия между версиями

м (Рабочие продукты)
м
(не показано 7 промежуточных версий этого же участника)
Строка 1: Строка 1:
'''Возможности''' — это обстоятельства, которые делают возможным разработку (или доработку — изменение уже имеющейся) системы.
+
'''Возможности''' — это обстоятельства, которые делают возможным разработку (или доработку — изменение уже имеющейся) [[система|системы]].
 
* их наличие существенно зависит от времени (”окно возможностей” — период времени, в течение которого существует возможность выполнения проекта);
 
* их наличие существенно зависит от времени (”окно возможностей” — период времени, в течение которого существует возможность выполнения проекта);
* характеризуют пользовательские потребности (пользовательские нужды, user needs — то, что хотят пользователи такого, для чего им поможет наличие воплощения системы), а также нужды остальных стейкхолдеров;
+
* характеризуют пользовательские [[Потребности|потребности]] (пользовательские нужды, user needs — то, что хотят пользователи такого, для чего им поможет наличие воплощения системы), а также нужды остальных [[стейкхолдер|стейкхолдеров]];
* отражают наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей;
+
* отражают наличие возможностей [[Команда|команды]] с развёрнутыми для этой команды [[:Категория:Технологии|технологиями]] и доступными финансовыми ресурсами в удовлетворении этих потребностей;
* мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
+
* мотивируют [[стейкхолдер|стейкхолдеров]] заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
  
 
== Рабочие продукты ==
 
== Рабочие продукты ==
* “бизнес-план”,
+
В рабочих продуктах обосновывается польза разным [[стейкхолдер|стейкхолдерам]] от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерного проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
* “[[концепция]]”,
+
 
* “интервью пользователей”,
+
Примеры рабочих продуктов:
* “обоснование инвестиций”
+
* “[[бизнес-план]]”;
* и т.д. — в этих рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерный проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
+
* “[[концепция системы]]”;
 +
* “[[интервью со стейкхолдером|интервью пользователей]]”;
 +
* “[[обоснование инвестиций]]”.
  
 
== Дисциплины ==
 
== Дисциплины ==
* [[Маркетинг]] и продажи,
+
* [[Маркетинг]] и [[продажи]],
* [[Стратегирование]] и предпринимательство — для установления user needs;
+
* [[Стратегирование]] и предпринимательство — для установления [[Потребности|user needs]];
 
* Управленческий (финансовый) учёт — для обоснования прибыльности.
 
* Управленческий (финансовый) учёт — для обоснования прибыльности.
  
Строка 20: Строка 22:
 
* “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting),
 
* “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting),
 
* “[[потребности]]” (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, [[GORE|целеориентированная инженерия требований]] и т.д.).
 
* “[[потребности]]” (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, [[GORE|целеориентированная инженерия требований]] и т.д.).
 +
 +
== Состояния ==
 +
[[OMG Essence]] определяет следующие состояния для альфы "Возможность" и [[Практика контрольных вопросов|контрольные вопросы]] для проверки каждого состояния:
 +
 +
{| class="wikitable" style="font-size: 9pt;"
 +
! style="text-align: center; font-weight: bold; width:4%" | №
 +
! style="text-align: center; font-weight: bold; width:10%" | Состояние
 +
! style="text-align: center; font-weight: bold; width:10%" | State
 +
! style="text-align: center; font-weight: bold; width:16%" | Описание состояния
 +
! style="text-align: center; font-weight: bold; width:60%" | Контрольные вопросы
 +
|-
 +
| 1
 +
| style="font-weight: bold;" | Определена
 +
| Identified
 +
| Коммерческая, общественная или инвестиционная возможность, которая могла бы быть адресована программным решением, определена.
 +
| ❑ Идея по способу улучшения текущих технологий работы, увеличения рыночной доли или по применению новой или инновационной программной системы была определена.
 +
 +
❑ Как минимум один из стейкхолдеров желает сделать инвестицию в более подробное понимание возможности и пользы, связанной с адресацией этой возможности.
 +
 +
❑ Другие стейкхолдеры, для которых это общая возможность, определены.
 +
|-
 +
| 2
 +
| style="font-weight: bold;" | Нужно решение
 +
| Solution Needed
 +
| Потребность в программном решении была подтверждена.
 +
| ❑ Стейкхолдеры для возможности и предложенное решение были определены.
 +
 +
❑ Потребности стейкхолдеров, которые порождают возможность, были установлены.
 +
 +
❑ Любые связанные с возможностью проблемы и их корневые причины были определены.
 +
 +
❑ Было подтверждено, что программное решение нужно.
 +
 +
❑ По меньшей мере одно программное решение было предложено.
 +
|-
 +
| 3
 +
| style="font-weight: bold;" | Польза установлена
 +
| Value Established
 +
| Польза успешного решения была установлена.
 +
| ❑ Польза адресации возможности была определена количественно либо в абсолютных значениях, либо в единицах дохода или экономии за период (например, за год).
 +
 +
❑ Влияние решения на стейкхолдеров понятно.
 +
 +
❑ Польза, которую программная система предлагает стейкхолдерам, которые финансируют и используют систему, понятна.Критерии успеха, по которым будет приниматься решение о разворачивании системы, ясны.
 +
 +
❑ Желаемые результаты, требуемые от решения, ясны и определены количественно.
 +
|-
 +
| 4
 +
| style="font-weight: bold;" | Жизнеспособна
 +
| Viable
 +
| Согласовано, что решение может быть произведено достаточно быстро и дёшево, чтобы успешно адресовать возможность.
 +
| ❑ Решение обрисовано в общих чертах.
 +
 +
❑ Есть признаки, что решение может быть разработано и развёрнуто в текущих ограничениях.
 +
 +
❑ Риски, связанные с решением, приемлемы и управляемы.
 +
 +
❑ Грубая оценка цены решения меньше, чем ожидаемая польза от реализации возможности.
 +
 +
❑ Причины для разработки программного решения понимаются всеми членами команды.
 +
 +
❑ Ясно, что реализация возможности жизнеспособна.
 +
|-
 +
| 5
 +
| style="font-weight: bold;" | Адресована
 +
| Addressed
 +
| Решение, которое произведено, демонстрирует адресацию возможности.
 +
| ❑ Готовая к использованию система, которая демонстрирует реализацию возможности, доступна.
 +
 +
❑ Стейкхолдеры согласны, что доступное решение заслуживает разворачивания.
 +
 +
❑ Стейкхолдеры удовлетворены тем, как разработанное решение адресует возможность.
 +
|-
 +
| 6
 +
| style="font-weight: bold;" | Принесла выгоду
 +
| Benefit Accrued
 +
| Эксплуатация или продажа решения создаёт осзязаемые выгоды.
 +
| ❑ Решение начало извлекать выгоды для стейкхолдеров.
 +
 +
❑ Профиль возврата инвестиций по меньшей мере так хорош, как ожидалось.
 +
|}
 +
  
 
[[Категория: Концепции]]
 
[[Категория: Концепции]]
 +
[[Категория: Альфы]]

Версия 17:45, 10 января 2018

Возможности — это обстоятельства, которые делают возможным разработку (или доработку — изменение уже имеющейся) системы.

  • их наличие существенно зависит от времени (”окно возможностей” — период времени, в течение которого существует возможность выполнения проекта);
  • характеризуют пользовательские потребности (пользовательские нужды, user needs — то, что хотят пользователи такого, для чего им поможет наличие воплощения системы), а также нужды остальных стейкхолдеров;
  • отражают наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей;
  • мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.

Рабочие продукты

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

Примеры рабочих продуктов:

Дисциплины

Подальфы

Состояния

OMG Essence определяет следующие состояния для альфы "Возможность" и контрольные вопросы для проверки каждого состояния:

Состояние State Описание состояния Контрольные вопросы
1 Определена Identified Коммерческая, общественная или инвестиционная возможность, которая могла бы быть адресована программным решением, определена. ❑ Идея по способу улучшения текущих технологий работы, увеличения рыночной доли или по применению новой или инновационной программной системы была определена.

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

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

2 Нужно решение Solution Needed Потребность в программном решении была подтверждена. ❑ Стейкхолдеры для возможности и предложенное решение были определены.

❑ Потребности стейкхолдеров, которые порождают возможность, были установлены.

❑ Любые связанные с возможностью проблемы и их корневые причины были определены.

❑ Было подтверждено, что программное решение нужно.

❑ По меньшей мере одно программное решение было предложено.

3 Польза установлена Value Established Польза успешного решения была установлена. ❑ Польза адресации возможности была определена количественно либо в абсолютных значениях, либо в единицах дохода или экономии за период (например, за год).

❑ Влияние решения на стейкхолдеров понятно.

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

❑ Желаемые результаты, требуемые от решения, ясны и определены количественно.

4 Жизнеспособна Viable Согласовано, что решение может быть произведено достаточно быстро и дёшево, чтобы успешно адресовать возможность. ❑ Решение обрисовано в общих чертах.

❑ Есть признаки, что решение может быть разработано и развёрнуто в текущих ограничениях.

❑ Риски, связанные с решением, приемлемы и управляемы.

❑ Грубая оценка цены решения меньше, чем ожидаемая польза от реализации возможности.

❑ Причины для разработки программного решения понимаются всеми членами команды.

❑ Ясно, что реализация возможности жизнеспособна.

5 Адресована Addressed Решение, которое произведено, демонстрирует адресацию возможности. ❑ Готовая к использованию система, которая демонстрирует реализацию возможности, доступна.

❑ Стейкхолдеры согласны, что доступное решение заслуживает разворачивания.

❑ Стейкхолдеры удовлетворены тем, как разработанное решение адресует возможность.

6 Принесла выгоду Benefit Accrued Эксплуатация или продажа решения создаёт осзязаемые выгоды. ❑ Решение начало извлекать выгоды для стейкхолдеров.

❑ Профиль возврата инвестиций по меньшей мере так хорош, как ожидалось.