Может ли заинтересованное лицо быть со стороны исполнителя?

Заинтересованные лица со стороны исполнителя: да, это возможно и необходимо

Ответ — категорически да. В моей практике заинтересованные лица (stakeholders) часто приходят со стороны исполнителя, и это абсолютно нормально и полезно.

Кто такие заинтересованные лица со стороны исполнителя

Примеры:

• Tech Lead / Архитектор — заинтересован в соблюдении архитектурных принципов
• DevOps инженер — заинтересован в deployability решения
• QA Lead — заинтересован в testability и качестве
• Security специалист — заинтересован в безопасности
• DBA — заинтересован в performance и scalability БД
• Руководитель разработки — заинтересован в сроках, бюджете, загрузке команды

Почему это важно

Если мы не учитываем требования исполнителей, получаем:

Архитектурные проблемы:

• Код, который сложно поддерживать
• Нарушения паттернов и соглашений
• Технический долг

Операционные проблемы:

• Система, которая не масштабируется
• Сложность развёртывания
• Высокие расходы на инфраструктуру

Проблемы качества:

• Низкая testability (QA не может тестировать)
• Уязвимости в безопасности
• Баги в production

Реальный пример из моей практики

Ситуация: Заказчик хотел "быстро добавить экспорт данных в PDF"

Мой анализ требований включал:

1. Business Analyst (я): собрал требования заказчика

   • Нужен PDF экспорт
   • Быстрая генерация
   • Красивое оформление

2. Tech Lead (stakeholder): высказал озабоченность

   • "PDF генерация на backend требует значительных ресурсов"
   • "Предлагаю делать на клиенте через js library"
   • "Это снизит нагрузку на сервер в 10 раз"

3. DevOps инженер (stakeholder): добавил constraints

   • "У нас нет лицензии на ту библиотеку"
   • "Используйте open-source решение"

4. QA Lead (stakeholder): указал проблему

   • "Как мы будем тестировать PDF генерацию?"
   • "Нужны скриншот-тесты?"

Результат: Я модифицировал требования User Story с учётом всех заинтересованных лиц:

AS A пользователь
I WANT TO экспортировать отчёт в PDF
SO THAT I CAN распечатать или поделиться

Acceptance Criteria:
- PDF генерируется на клиенте (js-based solution)
- Используется open-source библиотека (pdfkit или aналог)
- Поддерживает кириллицу
- Работает в Chrome, Firefox, Safari
- Есть автотесты (jest snapshots)

Без учёта stakeholders со стороны исполнителя я бы:

• Выбрал неправильную технологию
• Создал узкое место на сервере
• Нарушил лицензионную политику
• Оставил систему без тестов

Баланс интересов

Sometimes возникают конфликты:

Заказчик: "Система должна поддерживать 1 млн пользователей"

Руководитель разработки: "Это потребует 3 месяца работы и 5 человек"

Business Analyst (я): Должен найти баланс

• Может ли это быть phased approach?
• Нужна ли эта масштабируемость сейчас или через год?
• Какой бюджет выделен?
• Какой ROI от дополнительной масштабируемости?

Как я работаю с такими stakeholders

1. Идентифицирую всех заинтересованных лиц на начале проекта
2. Проводу интервью** с каждым:
   • Tech Lead: какие архитектурные constraints?
   • DevOps: требования к deployment?
   • QA: как это тестировать?
   • Security: есть ли угрозы?
3. Документирую non-functional requirements
4. Включаю в definition of done:

   - Код соответствует архитектурным стандартам
   - Решение supportable и scalable
   - Есть automated tests
   - Нет security issues
   - Документация обновлена
   

Вывод

Да, заинтересованные лица часто приходят со стороны исполнителя.

Это не недостаток, а необходимая часть анализа требований.

Business Analyst должен быть "переводчиком" между:

• Бизнесом (заказчик, клиент, продакт-менеджер)
• Исполнением (разработка, QA, DevOps, безопасность)

Тольку в этом "сетевом" анализе появляется полная картина требований, которые действительно можно реализовать и которые будут работать в production.