Что не обязательно делать при работе с большим количеством стейкхолдеров?

Работа со множественными стейкхолдерами: что НЕ нужно делать

Работа с большим количеством стейкхолдеров — это одна из самых сложных задач Business Analyst. У каждого свои интересы, приоритеты, языки общения. Легко потеряться в попытке всем угодить. Поэтому важно знать не только что делать, но и что делать НЕ НУЖНО.

Основные ошибки при работе со стейкхолдерами

1. НЕ нужно обсуждать все требования со всеми одновременно

Это самая частая ошибка. Бизнес-аналитики собирают ВСЕХ в комнату и пытаются обсудить ВСЁ.

Что происходит:

• 15 человек в Zoom → переговоры длятся 3 часа
• Каждый озвучивает свои требования
• Конфликты между требованиями
• Никого не удовлетворяет
• Из встречи выходит: "Давайте подумаем и напишем в чат"

Что нужно делать вместо этого:

1. Индивидуальные встречи с ключевыми стейкхолдерами (Product Manager, Engineering Lead, Sales Manager, Finance)
2. Выслушать их требования отдельно
3. Собрать требования в документ
4. Провести ONE встречу по согласованию конфликтов
5. Представить финальный вариант

Результат: 5 встреч по 30 мин = 2.5 часа вместо одной 3-часовой.

2. НЕ нужно пытаться удовлетворить всех

Это психологическая ловушка. Ты пытаешься добавить в backlog 100% всех предложенных требований.

Реальность:

Имеем:
- Sales: "Нужна интеграция с Salesforce"
- Engineering: "Нужен рефакторинг старого модуля"
- Finance: "Нужна аналитика по затратам"
- Support: "Нужен чат с клиентами"
- Product: "Нужна мобильная версия"

Время команды: 100 дней в квартал
Нужно сделать: 500 дней работы

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

Что нужно делать:

• Установи чёткие приоритеты (должны быть основаны на OKR компании, не на громкости стейкхолдера)
• Скажи "нет" требованиям, которые не критичны
• Обоснуй почему: "Это важно, но в этом квартале приоритет на X. Добавим в следующий"

3. НЕ нужно обсуждать технические детали с нетехническими стейкхолдерами

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

Ошибка: Vice President: "Нам нужно перейти на микросервисы, чтобы быть быстрее"

Ты начинаешь обсуждать архитектуру микросервисов, рассказывать про API Gateway, message queue и т.д.

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

Что нужно делать:

Переведи в бизнес-язык: "Вижу, вас волнует скорость. Текущие системы загружаются 2 сек, нужно < 500ms. Согласны? Каким путём добраться (микросервисы или оптимизация базы) — техническая задача Engineering Lead."

Теперь обсуждаешь проблему (скорость), не решение (архитектура).

4. НЕ нужно собирать требования в формате "свободный текст" от каждого

Если каждый стейкхолдер напишет свои требования как-нибудь, получится хаос.

Ошибка:

• PM напишет в doc: "Нужна фича X"
• Sales напишет в Slack: "Клиенты просят Y"
• Support напишет письмо: "Баги с Z"
• Engineering напишет в GitHub issue: "Пока не можем E"

Что нужно делать: Установи ОДИН формат для всех требований:

• Все требования в одном место (Jira, Notion, Asana)
• Единый template (Проблема → Решение → Приоритет → Метрика успеха)
• Версионирование (когда что изменилось)
• Собственник каждого требования (кто его предложил, кто вопрос задаст)

5. НЕ нужно игнорировать конфликты

Когда два стейкхолдера предложили противоположные требования, не нужно пытаться сделать оба.

Ошибка: Finance: "Нужна дешёвая интеграция, максимум 10K" PM: "Нужна лучшая интеграция на рынке, стоит 50K"

Ты начинаешь искать середину: "Может, за 30K?" — и получаешь худший вариант.

Что нужно делать:

1. Выразить конфликт явно: "Finance хочет дешево, PM хочет качество. Это взаимоисключающие требования."
2. Провести анализ: какой вариант лучше для компании? (ROI, стратегия, конкурентное преимущество)
3. Принять решение и объяснить почему: "Выбираем 50K вариант, потому что это даст нам +500K в выручке, на этом квартальный OKR ориентирован"
4. Документировать решение

6. НЕ нужно обновлять требования в реальном времени на встречах

Некоторые BA пытаются писать требование прямо во время встречи. Результат: требование размытое, потому что участники всё ещё обсуждают.

Ошибка: На встречи ты открываешь Google Doc и пишешь на глазах у всех. Люди постоянно предлагают добавить/изменить. Из требования получается монстр из 50 критериев.

Что нужно делать:

1. На встречи: слушай (не пиши)
2. Делай заметки
3. После встречи: структурируй требование
4. Отправь черновик на согласование
5. Собери feedback
6. Опубликуй финальный вариант

7. НЕ нужно быть "миротворцем" во всех конфликтах

Все стейкхолдеры хотят BA был на их стороне. Если ты пытаешься всем угодить, теряешь доверие.

Ошибка: PM: "Я думаю, нам нужна фича X" Ty: "Да, супер идея!"

Engineering Lead: "Это плохая идея, нужна рефакторизация вместо этого" Ты: "Да, ты тоже прав!"

Результат: никто не верит твоему мнению, потому что у тебя его нет.

Что нужно делать:

1. Слушай обе стороны
2. Проведи анализ
3. Поддержи ту позицию, которая лучше для компании (объясни почему)
4. Убедись в том, что понимаешь аргументы другой стороны, но выбрал А вместо Б

8. НЕ нужно обещать быстрый результат, чтобы потом разочаровать

Ошибка: Sales: "Клиент ждёт интеграцию к пятнице" Ты: "Хорошо, сделаем!"

Это невозможно, но ты пообещал ради одобрения.

В пятницу: интеграция не готова → Sales разочарован → клиент ушёл → вся вина на тебе.

Что нужно делать:

Будь честен сразу: "К пятнице не получится. Реально к концу недели. Это есть у нас в roadmap с более низким приоритетом. Если вы хотите сделать это критичным, нужно отложить X. Согласны?"

СaleS может согласиться или нет. Но решение принято честно.

Правило 80/20 для стейкхолдеров

20% стейкхолдеров генерируют 80% требований

Обычно:
- 2-3 ключевых стейкхолдера (PM, CEO, Lead Engineer)
- 5-10 вторичных
- 20+ периферийных (которые говорят в чате раз в месяц)

НЕ нужно давать всем одинаковое внимание.
Дели время пропорционально влиянию.

Чек-лист: что НЕ нужно делать

• ❌ Собирать всех в одну встречу
• ❌ Пытаться удовлетворить 100% требований
• ❌ Обсуждать технику с нетехническими стейкхолдерами
• ❌ Имеет требования без структуры
• ❌ Игнорировать конфликты
• ❌ Писать требования в реальном времени
• ❌ Быть слишком хорошим мальчиком
• ❌ Обещать то, что не можешь доставить

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