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

Что НЕ обязательно делать при работе со стейкхолдерами

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

1. Не нужно согласовывать КАЖДОЕ решение со стейкхолдерами

Чём НЕ нужно согласовать:

• Способ сбора информации — не нужно спрашивать разрешение на проведение интервью или опроса
• Глубину анализа — сам выбираю, какие метрики анализировать и на какую глубину копать
• Инструменты — не нужно спрашивать одобрение на использование Tableau вместо Power BI
• Промежуточные гипотезы — не каждую идею обсуждать до валидации

Парадокс: Это создаёт иллюзию участия, но на самом деле замедляет процесс и размывает ответственность. Если я аналитик — я собираю информацию, предварительно её обрабатываю, затем показываю результат.

Пример: Вместо: "Хотите, я проведу A/B тест по цвету кнопки?" (ждём одобрения) Лучше: "Я провёл A/B тест. Вот результаты: красная на 15% больше кликов. Рекомендую красную."

Второй подход показывает экспертизу и уважение к времени стейкхолдера.

2. Не нужно создавать документацию для каждого стейкхолдера

Что часто делают неправильно:

• Создают одинаковую презентацию для CEO, разработчика и дизайнера
• Пишут 30-страничный отчёт, когда нужна 2-страничная summary
• Документируют каждый шаг анализа, хотя стейкхолдеров интересуют только выводы

Что на самом деле нужно:

• Одна версия истины — единый источник (например, Confluence), куда все идут за информацией
• Разные форматы для разных контекстов:
  • Для CEO: 1 слайд с числом и рекомендацией
  • Для дизайнера: интерактивный Figma с требованиями
  • Для разработчика: требования в Jira, не в Confluence
  • Для аналитика: полный отчёт с методологией

Антипаттерн: Постоянно переделываешь одно исследование в разные форматы вместо того, чтобы один раз сделать правильно.

3. Не нужно быть "другом" для каждого стейкхолдера

Иллюзии, которые нужно развеять:

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

Что на самом деле важно:

• Профессионализм и уважение
• Честность (сказать "Я не согласен" — это нормально)
• Открытость к их point of view, но не слепое следование

Пример: Менеджер говорит: "Наши пользователи точно хотят эту фичу!" (интуиция, без данных) Вместо: "Хорошо, давай её делать!" (попытка угодить) Лучше: "Давай проверим эту гипотезу. Проведём опрос 20 пользователей на неделю, затем примем решение"

Это не враждебно, это профессионально.

4. Не нужно собирать requirements по одному в бесконечных встречах

Что делают новички:

• Организуют встречу с каждым отделом (тратят по часу)
• Потом встречу со всеми вместе (ещё час)
• Потом мирят противоречивые мнения в еще одной встречи

Что нужно:

• Массовый сбор (опрос, анкета, workshop) вместо индивидуальных встреч
• Асинхронная коммуникация (документ на review в Confluence, затем вопросы в Slack)
• Структурированное обсуждение (agenda → обсуждение → decision → next steps, не болтовня)

Факт: Меньше встреч = больше time to decision. Встреча — это последнее средство, когда нельзя обойтись без синхрона.

5. Не нужно писать requirements в формате "а что если?"

Неправильно: "Пользователи могут хотеть фильтр по категориям, потому что они могут захотеть фильтровать по товарам, потому что им может быть интересно, может они..."

Правильно: "Пользователи теряют 3-5 минут на поиск товара в списке из 500 товаров. Предложение: добавить фильтр по категориям. Это сократит время на поиск вдвое (по A/B тесту)."

Второй вариант подкреплён данными и не содержит спекуляций.

6. Не нужно постоянно давать обновления статуса

Анти-паттерн: "Привет! Я ещё работаю над требованиями!" (каждый день) "Всё ещё анализирую!" (вторая неделя)

Правильный подход:

• Скажи дедлайн: "Готово к среде"
• Если что-то изменится — про-активно сообщи причину: "Нашли новую информацию, готово к пятнице"
• Иначе — тишина до результата

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

7. Не нужно защищать себя в требованиях

Защитные трюки, которые раздражают:

• "Согласно опросу 5 человек, 80% предпочитают красный" (защита от критики неправильными числами)
• "Может быть, возможно, может" (неуверенность в словах)
• Писать все assumptions в требованиях (грузишь стейкхолдеру)

Правильно:

• Скажи чистый вывод: "Красный на 15% более эффективен" (уверено)
• Assumptions скажи устно: "Это валидно для нашей аудитории, но может отличаться для других стран"
• Если есть сомнения — выдели как открытый вопрос: "Нужно уточнить: нужна ли поддержка мобильных платежей?"

8. Не нужно быть экспертом во всём

Синдром переусложнения:

• Стараешься понять деньги (Finance), маркетинг (Marketing), продакт (Product) и код (Engineering) одновременно
• Результат: поверхностное понимание везде и отсутствие глубокой экспертизы

Что работает:

• Быть глубоким экспертом в 1-2 доменах (например, Growth Metrics и User Research)
• В остальном быть "грамотным любителем"
• Знать, когда просить помощь у специалиста

Пример: Вместо: "Я тебе объясню весь financial model" (слишком амбициозно) Лучше: "Давай пригласим бухгалтера на встречу, я сфокусируюсь на пользовательских метриках, ты — на финансах"

Итог: Матрица "Обязательно vs Опционально"

ОБЯЗАТЕЛЬНО:

• Слушать и понимать боли стейкхолдеров
• Быть экспертом в требованиях
• Давать честную обратную связь
• Показывать результаты своей работы
• Уважать время всех
• Принимать решения на основе данных

ОПЦИОНАЛЬНО (не граждане):

• Согласовывать каждый шаг
• Быть другом всем
• Писать док для каждого
• Бесконечные встречи
• Защитные формулировки
• Быть экспертом во всём

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