Кто такой стейкхолдер и как он участвует в разработке программного обеспечения?

Каждая задача, которую выполняет бизнес-аналитик, включает в себя взаимодействие с людьми, которым важен результат выполнения задачи. Кого из заинтересованных лиц должен привлечь аналитик, чтобы обсудить детали задачи на этапе анализа и сбора требований? Одного заказчика со стороны бизнес-процессов часто бывает недостаточно, чтобы получить всю нужную информацию для запрашиваемых изменений процессов. Пришло время познакомиться с понятием «Стейкхолдеры».

Кто такие «Стейкхолдеры»?

Стейкхолдер — это (от анл. Stakeholder) — заинтересованное лицо, то есть человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата и сама может влиять на процесс или результат.

То есть в круг заинтересованных лиц в рамках анализа задачи попадают все, кто:

• выполняет проект — например, команда разработки (как основного ПО, так и систем-партнёров) или служба поддержки клиентов, юристы, то есть все, кому нужно выполнить работу в рамках задачи;
• использует результат проекта — например, пользователь ПО или система-партнёр, которая взаимодействует с основной системой;
• влияет на результат проекта — например, управляющее звено отдела или компании, архитекторы системы, внешние партнёры и даже представители власти, диктующие требования к системе со стороны законодательства.

На примере «Сытого зайки» заинтересованными лицами могут быть:

• Команда разработки ПО «Сытый зайка» — те, кто выполняет проект для этого ПО.
• Клиент, оформляющий доставку продуктов, — тот, кто использует результат продукта.
• Директор компании по доставке продуктов «Сытый зайка» — лицо, влияющее на результаты проекта.

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

Классификация стейкхолдеров

Искать стейкхолдеров будет быстрее, если их классифицировать в рамках проекта: по ролям, типам, уровням влияния и уровням взаимодействия.

Расскажем про эти классификации подробнее.

По ролям

Классификация по ролям — объединение заинтересованных лиц по зонам ответственности (или причастности) в рамках выполнения задачи.

Роли, объединённые одним видением ожидаемого результата изменений:

• Бизнес-аналитик — заинтересованная сторона для всех видов деятельности в рамках бизнес-анализа. Он несёт ответственность за полноту и качество выполняемых действий в рамках изменений продукта.
• Клиент — лицо, получающее от продукта прямую или косвенную выгоду.

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

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

Клиент не всегда может быть пользователем продукта. Например, магазины-партнёры, поставляющие продукты на склады «Сытого зайки» являются клиентами компании, но они не используют ПО компании для доставки этих продуктов. А покупатели, которые осуществляют заказ через приложение доставки продуктов «Сытый зайка», — это пользователи ПО компании, и они же являются клиентами компании.

• Эксперт предметной области бизнеса — человек c глубокими знаниями потребностей бизнеса и его процессов. Это могут быть как представители бизнеса (владельцы продукта, топ-менеджмент), так и эксперты из других сфер (юристы, бухгалтеры, сотрудники отдела маркетинга и так далее).
• Операционная поддержка — отвечает за повседневное управление и обслуживание системы или продукта, например специалисты службы поддержки.
• Специалист по реализации — специалист, обладающий знаниями по реализации одного или более компонентов решения. Например, разработчик, администратор базы данных, дизайнер и так далее.
• Руководитель проекта — отвечает за управление работой для предоставления решения по потребностям бизнеса. Руководитель проекта следит за выполнением целей задачи и отслеживает ключевые показатели проекта (объём, бюджет, график, ресурсы, качество и риски). Эту роль часто исполняют технический директор, менеджер проекта или командный лидер (TeamLead, тимлид).
• Регулятор — отвечает за определение и применение стандартов в рамках проектируемого решения. Чаще всего регуляторами выступают правительство страны, регулирующие органы и аудиторы.
• Поставщик — провайдер, вендор или консультант за пределами организации, предоставляющий услуги для компании или её продукта (в том числе для ПО). Эти услуги должны учитываться в некоторых задачах в рамках бизнес-анализа.
• Спонсор — директор, спонсор проекта или другое лицо, заинтересованное в результатах, влияющих на развитие компании. Спонсоры являются основными инициаторами задач, которые удовлетворяют потребности бизнеса.
• Тестировщик или инженер по тестированию — проверяет, чтобы решения соответствовали требованиям, которые сформулировал бизнес-аналитик. Тестировщики стремятся, чтобы реализованное решение соответствовало стандартам качества и в нём было как можно меньше рисков, дефектов и сбоев.

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

Пример 1

Выгрузить отчёт по применению пользователями промокода GOOD_LUCK к заказам со статусом «Доставлено» за четвёртый квартал 2022 года.

Здесь администратор базы данных будет и пользователем (данных ПО), и специалистом по реализации (тот, кто сделает выгрузку).

Пример 2

Реализовать в администраторском ПО «Сытый зайка» возможность загрузки, хранения и использования унифицированных государственных шаблонов договоров для подключения партнёров компании.

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

По типам

Классификация по типам — разделение заинтересованных лиц на группы в зависимости от их отношения к проектной команде или компании, предоставляющей изменяемое ПО.

По типам заинтересованные лица могут быть внутренними и внешними.

• К внешним стейкхолдерам относятся регулирующие органы, партнёры компании, пользователи ПО, спонсоры и внешние консультанты.
• К внутренним стейкхолдерам относятся представители организации, в рамках которой планируется разработка ПО, и сама проектная команда, которая будет разрабатывать систему.

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

По уровню влияния

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

• Первичные стейкхлодеры — это ближний круг, активно влияющий на деятельность организации либо выполнение проекта: клиенты, команда разработки ПО, владельцы и партнёры бизнеса.
• Вторичные стейкхолдеры — это дальнее окружение, имеющее косвенное влияние на компанию или проект: инвесторы, конкуренты, СМИ и представители органов власти.

По уровню взаимодействия

По уровню взаимодействия с продуктом стейкхолдеры делятся на прямых и косвенных.

• Прямые стейкхолдеры — это те, кто взаимодействует с продуктом компании напрямую: к примеру, пользователи, оформляющие доставку продуктов в приложении «Сытый зайка», или проектная команда которая занимается разработкой и поддержкой ПО.
• Косвенные — те, кто оказывают на него опосредованное влияние. Например, партнёры, которые предлагают скидки для заказа продуктов в приложении «Сытый зайка», или заказчики изменений для ПО.

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

Документирование данных стейкхолдеров

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

Часто достаточно небольшого объёма информации, которая поможет грамотно выстраивать коммуникацию со стейкхолдером. Например, во многих IT-компаниях по умолчанию принято обращаться на «ты», но это не всегда уместно, особенно если стейкхолдер значительно старше собеседника. Поэтому можно учитывать следующие атрибуты для документирования заинтересованных лиц:

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

Итоги

• Стейкхолдер (Stakeholder) — заинтересованное лицо, то есть человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата и сама может влиять на процесс или результат.
• Чтобы определить возможных стейкхолдеров конкретного проекта, нужно посмотреть максимально широко. Важно никого не пропустить и всех грамотно задокументировать — так уменьшается риск несоответствия конечного продукта ожиданиям потребителей.
• Искать представителей каждой заинтересованной в изменениях ПО структуры можно быстрее, если опираться на классификацию. Способы классификации стейкхолдеров:
  • По ролям — объединение заинтересованных лиц по зонам ответственности (или причастности) в рамках выполнения задачи.
  • По типу отношения к проектной команде: внутренние и внешние.
  • По уровню влияния на продукт: первичные и вторичные.
  • По уровню взаимодействия с продуктом: прямые и косвенные.