Возможности — различия между версиями
Admin (обсуждение | вклад) м (→Рабочие продукты) |
Admin (обсуждение | вклад) м |
||
(не показано 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 — то, что хотят пользователи такого, для чего им поможет наличие воплощения системы), а также нужды остальных стейкхолдеров;
- отражают наличие возможностей команды с развёрнутыми для этой команды технологиями и доступными финансовыми ресурсами в удовлетворении этих потребностей;
- мотивируют стейкхолдеров заниматься инженерным проектом, именно возможности объединяют стейкхолдеров на цели выполнения инженерного проекта по созданию целевой системы.
Содержание
Рабочие продукты
В рабочих продуктах обосновывается польза разным стейкхолдерам от выполнения инженерного проекта, ибо если нет обоснованных возможностей, то выполнение инженерного проекта не приносит пользы, а приносит вред (например, убытки для инженерной компании).
Примеры рабочих продуктов:
Дисциплины
- Маркетинг и продажи,
- Стратегирование и предпринимательство — для установления user needs;
- Управленческий (финансовый) учёт — для обоснования прибыльности.
Подальфы
- “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting),
- “потребности” (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, целеориентированная инженерия требований и т.д.).
Состояния
OMG Essence определяет следующие состояния для альфы "Возможность" и контрольные вопросы для проверки каждого состояния:
№ | Состояние | State | Описание состояния | Контрольные вопросы |
---|---|---|---|---|
1 | Определена | Identified | Коммерческая, общественная или инвестиционная возможность, которая могла бы быть адресована программным решением, определена. | ❑ Идея по способу улучшения текущих технологий работы, увеличения рыночной доли или по применению новой или инновационной программной системы была определена.
❑ Как минимум один из стейкхолдеров желает сделать инвестицию в более подробное понимание возможности и пользы, связанной с адресацией этой возможности. ❑ Другие стейкхолдеры, для которых это общая возможность, определены. |
2 | Нужно решение | Solution Needed | Потребность в программном решении была подтверждена. | ❑ Стейкхолдеры для возможности и предложенное решение были определены.
❑ Потребности стейкхолдеров, которые порождают возможность, были установлены. ❑ Любые связанные с возможностью проблемы и их корневые причины были определены. ❑ Было подтверждено, что программное решение нужно. ❑ По меньшей мере одно программное решение было предложено. |
3 | Польза установлена | Value Established | Польза успешного решения была установлена. | ❑ Польза адресации возможности была определена количественно либо в абсолютных значениях, либо в единицах дохода или экономии за период (например, за год).
❑ Влияние решения на стейкхолдеров понятно. ❑ Польза, которую программная система предлагает стейкхолдерам, которые финансируют и используют систему, понятна.Критерии успеха, по которым будет приниматься решение о разворачивании системы, ясны. ❑ Желаемые результаты, требуемые от решения, ясны и определены количественно. |
4 | Жизнеспособна | Viable | Согласовано, что решение может быть произведено достаточно быстро и дёшево, чтобы успешно адресовать возможность. | ❑ Решение обрисовано в общих чертах.
❑ Есть признаки, что решение может быть разработано и развёрнуто в текущих ограничениях. ❑ Риски, связанные с решением, приемлемы и управляемы. ❑ Грубая оценка цены решения меньше, чем ожидаемая польза от реализации возможности. ❑ Причины для разработки программного решения понимаются всеми членами команды. ❑ Ясно, что реализация возможности жизнеспособна. |
5 | Адресована | Addressed | Решение, которое произведено, демонстрирует адресацию возможности. | ❑ Готовая к использованию система, которая демонстрирует реализацию возможности, доступна.
❑ Стейкхолдеры согласны, что доступное решение заслуживает разворачивания. ❑ Стейкхолдеры удовлетворены тем, как разработанное решение адресует возможность. |
6 | Принесла выгоду | Benefit Accrued | Эксплуатация или продажа решения создаёт осзязаемые выгоды. | ❑ Решение начало извлекать выгоды для стейкхолдеров.
❑ Профиль возврата инвестиций по меньшей мере так хорош, как ожидалось. |