Стейкхолдер

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Стейкхо́лдер (англ. stákeholder) (заинтересованная сторона, причастная сторона) — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008,[1]:4 ISO/IEC 29148:2011[2]:6).

Другие определения:

  • Физическое лицо, команда, организация или их классы, имеющие интерес в системе (ISO/IEC 42010:2011).[3]:2
  • Физическое лицо, группа лиц или организация, которые могут влиять на систему или на которых может повлиять система (OMG Essence).[4]:5

Стейкхолдеры обеспечивают возможности для системы и являются источником требований для системы.[4]:14

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

Tom Gilb[5].

В системной инженерии стейкхолдеры рассматриваются в контексте процесса принятия решений как физические лица или организации, зависящие от результатов принимаемых решений. Понимание того, кто является стейкхолдером по отношению к принимаемым решениям, должно быть установлено заранее. Очень часто этого не происходит — стейкхолдеры не определяются до принятия решений. Однако, как только решение будет объявлено или реализовано, все, кто хоть как-то был затронут этим решением, выскажут своё мнение.[6]:258

Взаимосвязь стейкхолдеров с другими сущностями инженерного проекта[править | править вики-текст]

Альфы инженерного проекта (OMG Essense)[4]

На рисунке показано взаимодействие основных сущностей и объектов, встречающихся в проекте. Объекты сгруппированы между собой в области интересов. Таким образом, стейкхолдер относится к области интересов клиента (англ. client), так как эта область содержит все, что касается использования и эксплуатации системы.[4]:13-14

Типы (группы) стейкхолдеров[править | править вики-текст]

Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии[6]:

  • Приобретающая сторона, или покупатель (англ. acquirer) — организация или физическое лицо, которое приобретает или получает (англ. procures) продукт или услугу от поставщика.[2]:3[1]:2[7]:177 Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель.[8]
  • Заказчик, или клиент (англ. customer) — организация или физическое лицо, получающее продукт или услугу.[2]:4
  • Разработчик (англ. developer) — организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.[2]:4[8]
  • Поставщик (англ. supplier) — организация или физическое лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги.[1]:4[8]
  • Пользователь (англ. user) — лицо или группа лиц, извлекающих пользу в процессе применения системы.[1]:4[8]
  • Производитель (англ.  producer) — представитель, ответственный за выполнение работы[4]:227; лицо, ответственное за выравнивание расписания, бюджета и ограниченность ресурсов, чтобы удовлетворить клиентам.[7]:743
  • Сопровождающая сторона (англ. maintainer) — организация или физическое лицо, выполняющее поддержку системы на одном или нескольких этапах жизненного цикла[1]; организация, которая осуществляет деятельность по сопровождению.[8]
  • Ликвидатор (англ. disposer) — организация или физическое лицо, выполняющее ликвидацию (изъятие и списание) рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб.[1]
  • Аккредитор, или инспектор (англ. accreditor) — организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию.[6]
  • Регулирующий орган (англ. regulatory bodies) — организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации.[6]
  • Остальные — персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators) и другие.

Идентификация стейкхолдеров по стадиям жизненного цикла[править | править вики-текст]

Каждая система имеет свои собственные стадии жизненного цикла, например, концептуальное проектирование, разработку, производство, внедрение, эксплуатацию и ликвидацию. Для каждой стадии определяется список всех стейкхолдеров, имеющих интерес (отношение) к будущей системе. Целью этого действия является рассмотрение точки зрения каждого стейкхолдера на всех стадиях жизненного цикла системы для утверждения полного набора потребностей стейкхолдеров, которые могут быть приоритезированы и преобразованы в требования стейкхолдеров. Примеры связи стейкхолдеров со стадиями жизненного цикла представлены в таблице 1.

Таблица 1. Определение стейкхолдеров в соответствии со стадиями жизненного цикла системы[7]:262
Стадии жизненного цикла Примеры стейкхолдеров
Инженерия (проектирование, анализ) Приобретающая сторона, потенциальные пользователи, отдел маркетинга, отдел разработки, орган по стандартизации, поставщики, отдел тестирования (верификация и валидация), система производства и др.
Разработка Приобретающая сторона, поставщики, проектировщики, команда по интеграции и др.
Передача в производство или в использование Отдел по контролю качества, система производства, операторы и др.
Логистика и сопровождение Вспомогательные сервисы, инструкторы, участники цепочек поставок и др.
Эксплуатация Обычные пользователи, случайные пользователи и др.
Ликвидация Операторы, подтверждающий орган и др.

Степень учёта и вовлечения стейкхолдеров[править | править вики-текст]

Состояния стейкхолдеров (OMG Essense)[4]

Согласно предложениям OMG выделяются 6 состояний, в которых может находиться проект с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров[4]:20-21:

  • Признаны (англ. Recognized) — стейкхолдеры были определены.
  • Представлены (англ. Represented) — согласованы методы привлечения стейкхолдеров и назначены представители от каждой группы стейкхолдеров.
  • Вовлечены (англ. Involved) — представители групп стейкхолдеров принимают активное участие в работе и выполняют свои обязанности.
  • В согласии (англ. In agreement) — представители стейкхолдеров находятся в согласии.
  • Удовлетворены внедрением (англ. Satisfied for deployment) — минимальные ожидания представителей стейкхолдеров были достигнуты.
  • Удовлетворены использованием (англ. Satisfied in use) — система удовлетворяет или превышает минимальные ожидания стейкхолдеров.

Для оценки текущего состояния проекта с точки зрения учёта, вовлечения и удовлетворённости стейкхолдеров предлагаются следующие контрольные списки:

Таблица 2. Контрольные списки для стейкхолдеров[4]:22-23
Состояние Контрольный список
Признаны

Crystal Clear app clean.png Все различные группы стейкхолдеров, которые на данный момент или в будущем будут затронуты разработкой и функционированием системы, определены.
Crystal Clear app clean.png Есть соглашение по группам стейкхолдеров, которые будут представлены. Как минимум, должны приниматься в расчёт группы стейкхолдеров, которые финансируют, используют, поддерживают и обслуживают систему.
Crystal Clear app clean.png Ответственности представителей стейкхолдеров были определены.

Представлены

Crystal Clear app clean.png Представители стейкхолдеров согласились выполнять свои обязанности.
Crystal Clear app clean.png Представители стейкхолдеров уполномочены выполнять свои обязанности.
Crystal Clear app clean.png Подход к обеспечению сотрудничества среди представителей стейкхолдеров был согласован.
Crystal Clear app clean.png Представители стейкхолдеров поддерживают и уважают технологию работы команды.

Вовлечены

Crystal Clear app clean.png Представители стейкхолдеров помогают команде в соответствии со своими обязанностями.
Crystal Clear app clean.png Представители стейкхолдеров обеспечивают обратную связь и принимают участие в принятии решений своевременно.
Crystal Clear app clean.png Представители стейкхолдеров быстро сообщают изменения, которые имеют значение для их групп стейкхолдеров.

В согласии

Crystal Clear app clean.png Представители стейкхолдеров согласились с минимальными ожиданиями по последующему внедрению новой системы.
Crystal Clear app clean.png Представители стейкхолдеров удовлетворены своей вовлечённостью в работу.
Crystal Clear app clean.png Представители стейкхолдеров согласны, что их вклад в работу ценится командой и учитывается в работе с уважением.
Crystal Clear app clean.png Члены команды согласны, что их вклад в работу ценится представителями стейкхолдеров и учитывается в работе с уважением.
Crystal Clear app clean.png Представители стейкхолдеров согласны с тем, как их различные приоритеты и точки зрения балансируются для обеспечения ясного руководства для команды.

Удовлетворены внедрением

Crystal Clear app clean.png Представители стейкхолдеров обеспечивают обратную связь с точки зрения их групп стейкхолдеров.
Crystal Clear app clean.png Представители стейкхолдеров подтверждают, что система готова для разворачивания.

Удовлетворены использованием

Crystal Clear app clean.png Стейкхолдеры используют новую систему и предоставляют обратную связь об их опыте.
Crystal Clear app clean.png Стейкхолдеры подтверждают, что новая система соответствует их ожиданиям.

Роль стейкхолдеров в процессах организационного обеспечения проектов[править | править вики-текст]

Организационное обеспечение проекта состоит из управления возможностями организаций поставлять и приобретать продукты и услуги через поддержку, инициализацию и управление проектами. Это обеспечение поставляет ресурсы и инфраструктуру необходимые для содействия проектам и гарантирует исполнение организационных целей и действующих соглашений. Оно не претендует на звание совокупности деловых процессов, составляющих управление деловой деятельностью организации.[8]

Роль стейкхолдеров в управлении портфелем проектов[править | править вики-текст]

В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами.[8]

В результате успешного управления портфелем проектов:

  • уточняются, расставляются по важности и выбираются возможности, инвестиции или потребности деловой сферы с учетом рисков;
  • определяются и распределяются ресурсы и денежные средства для каждого проекта;
  • изменяются или ликвидируются проекты, не удовлетворяющие условиям соглашения или запросам стейкхолдеров;
  • формулируются полномочия и ответственность руководства проектом;
  • оказывается помощь проектам, удовлетворяющим условиям соглашения и требованиям стейкхолдеров.[8]

Роль стейкхолдеров в управлении качеством[править | править вики-текст]

Организации необходимо выполнять периодические ревизии планов обеспечения качества проектов. Для каждого проекта устанавливаются различные цели в области качества, которые в свою очередь основываются на требованиях стейкхолдеров.[8]

Назначение ревизии заключается в поддержке общего со стейкхолдерами понимания развития относительно целей соглашения и того, что именно требуется сделать для помощи в обеспечении разработки продукта, удовлетворяющего стейкхолдеров. Ревизии применяются как в процессе управления проектом, так и на техническом уровне и проводятся в течение всей жизни проекта.[8]

Роль стейкхолдеров в управлении рисками[править | править вики-текст]

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

Сущность соответствующего профиля рисков должна периодически сообщаться стейкхолдерам в зависимости от их потребностей, так как профиль рисков может изменяться в случае обновления отдельного состояния риска.

Стейкхолдерам необходимо предоставлять рекомендованные альтернативы обработки риска в требованиях на действия по отношению к риску. Если стейкхолдеры решают, что следует предпринять действия для того, чтобы сделать риск оптимальным, то должна быть реализована альтернатива обработки риска. Если стейкхолдеры принимают риск, который превышает максимальное значение, то этот риск должен рассматриваться как высоко приоритетный и постоянно контролироваться для определения необходимых будущих действий по его обработке.[8]

Роль стейкхолдеров в технических процессах[править | править вики-текст]

Технические процессы используются для формулирования требований к системе, модификации этих требований в эффективный продукт, позволяющий осуществлять, при необходимости, устойчивое повторное производство этого продукта, использовать его для обеспечения требуемых услуг, поддерживать обеспечение этими услугами и ликвидировать продукт, когда он изымается из обращения.[1]:19 Технические процессы определяют содержание работ, которые позволяют в рамках задач предприятия и проекта увеличить прибыли и минимизировать риски, возникающие в процессе принятия технических решений и осуществления соответствующих действий.

Роль стейкхолдеров в процессе определения требований[править | править вики-текст]

В стандарте о процессах жизненного цикла программных систем задача определения требований стейкхолдеров формулируется, как: определение требований к системе, выполнение которых может обеспечивать предоставление услуг, необходимых пользователям и другим стейкхолдерам в заданной среде применения. Этот процесс позволяет определять стейкхолдеров или классы стейкхолдеров, связанных с системой на протяжении всего ее жизненного цикла. Кроме того выделяются их потребности и пожелания. В процессе требования анализируются и модифицируются в общую совокупность требований стейкхолдеров, описывающих желаемое поведение системы в процессе взаимодействия со средой применения. Относительно этой совокупности каждая предоставляемая услуга подвергается валидации для подтверждения того, что система полностью удовлетворяет заявленным требованиям.[8]

Результатами успешного осуществления процесса определения требований стейкхолдеров является:

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

Процесс идентификации стейкхолдеров можно сформулировать как: идентификацию стейкхолдеров или классов стейкхолдеров, имеющих интерес к системе в процессе её жизненного цикла. Если непосредственная коммуникация невозможна, выбираются представители стейкхолдеров.[8]

Процесс идентификации требований состоит из решения следующих задач:

  1. Необходимо определить требования стейкхолдеров проекта. Требования стейкхолдеров могут проявляться в виде потребностей, пожеланий, требований, ожиданий или ограничений. В стандартах по качеству программных продуктов описывается модель качества продукции и требования к качеству, которые играют большую роль в определении требований стейкхолдеров.[9] [10] Приобретающая сторона, а также возможности пользователей могут накладывать некоторые ограничения на систему, которые должны быть учтены в требованиях стейкхолдеров наряду с потребностями и пожеланиями. Для измерения и оценки требований ключевых стейкхолдеров рекомендуется устанавливать показатели результативности.
  2. Вследствие существующих организационных и технических решений возникают ограничения для системы. В проекте необходимо определить ограничения системы.
  3. Последовательность видов деятельности, бизнес-процессы определяются для установления рабочих сценариев и сценариев поддержки в условиях применения системы. Это необходимо для идентификации не выявленных требований, то есть требований, формально незаданных стейкхолдерами. При помощи рабочих сценариев и сценариев поддержки анализируются условия использования системы, необходимые для последующего проектирования.
  4. На этапе реализации необходимо учесть возможности и способности пользователей системы, а, следовательно, и накладываемые ограничения.
  5. В проекте необходимо учесть возможные неблагоприятные воздействия использования системы на здоровье и безопасность человека. Для этого устанавливаются определенные требования к здоровью, безопасности, окружающим условиям, защищенности и другим свойствам.[8]
Базовая линия

Спецификация или продукт (версия системы), которые были официально рассмотрены и согласованы с тем, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения.[3]:2 Часто употребляется как «базис», «утвержденная версия», «сданная в архив версия».

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

В проекте должен прослеживаться источник возникновения потребностей от требований стейкхолдеров. Требования стейкхолдеров проверяются в моменты принятия ключевых решений в процессе жизненного цикла для гарантии того, что учитываются любые изменения потребностей.[8] Ограничения в системе могут возникать в результате:

  • примеров или областей решений, определенных стейкхолдерами;
  • реализации решений, принятых на более высоком уровне системной иерархии;
  • требований по использованию определенных обеспечивающих систем, ресурсов и штатного персонала.[8]

Примечания[править | править вики-текст]

Литература[править | править вики-текст]

  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds) Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.
  • ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)
  • ГОСТ Р ИСО/МЭК 9126-1 Программная инженерия — Качество программного продукта — Часть 1: Модель качества (см. ISO/IEC 9126-1:2001 Software Engineering — Product quality — Part 1: Quality model)
  • ГОСТ Р ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программных продуктов — Требования к качеству (см. ISO/IEC 25030:2007 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality Requirements)
  • ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)
  • ISO/IEC 29148:2011 Systems and software engineering — Life cycle processes — Requirements engineering
  • ISO/IEC 42010:2011 System and software engineering — Architecture description
  • Object Management Group Essence — Kernel and Language for Software Engineering Methods, Version 1.0, Beta 2. — 2014.