Был ли руководитель проекта?

Опыт работы с руководителями проектов

Да, я работал с различными руководителями проектов (Project Managers, Scrum Masters) в разных компаниях и проектах. Этот опыт научил меня очень многому о том, как правильно строить сотрудничество между аналитиком и PM.

Типы руководителей, с которыми я работал

Классический Project Manager (Waterfall)

• Работал на проектах с жёсткой структурой и предоставленным бюджетом
• PM отвечал за сроки, бюджет и scope
• Моя роль как BA — предоставить полную спецификацию в начале проекта
• Изменения требований были очень затратны

Agile Scrum Master

• Работал в Agile командах, где Scrum Master фасилитирует процесс
• Нет фиксированного плана на весь проект, планирование по спринтам
• Взаимодействие более гибкое и частое
• Требования эволюционируют по ходу проекта

Product Owner (в некоторых командах)

• В стартапах и продуктовых командах PO может совмещать роли PM и stakeholder
• Очень близкое взаимодействие, так как PO часто задаёт направление продукта

Что я узнал о работе с руководителями проектов

Различие в приоритетах

• PM часто озабочен сроками и ресурсами
• BA озабочен качеством требований и полнотой анализа
• Нужно найти баланс между "идеальным анализом" и "практическими сроками"

Коммуникация — ключ

• Хороший PM знает, как и когда просить информацию от BA
• Хороший BA знает, какую информацию нужна PM
• Слабая коммуникация приводит к задержкам и переделкам

Управление изменениями

• Когда стейкхолдер просит добавить требование в процессе разработки
• PM оценивает impact на сроки и бюджет
• BA оценивает complexity и dependencies
• Вместе мы принимаем решение

Планирование спринтов

• В Agile работаю с Scrum Master при планировании спринтов
• BA представляет user stories, которые технически готовы для разработки
• SM помогает командой оценить stories

Примеры успешного сотрудничества

Сценарий 1: Предотвращение переделок

• PM хотел взять в спринт 10 очень больших stories
• Я провел анализ и показал, что это технически невозможно
• Вместе с PM пересмотрели priority и взяли меньше, но более чётко определённых stories
• Результат: спринт был успешен, не было переделок

Сценарий 2: Управление stakeholder ожиданиями

• Клиент просил очень много функций в сжатые сроки
• Я подготовил анализ: сколько времени нужна для каждой функции
• PM использовал эту информацию для переговоров с клиентом
• Договорились на MVP + фазовый rollout
• Результат: реалистичный план, довольный клиент

Сценарий 3: Разрешение конфликтов между требованиями

• Два разных stakeholder давали противоречивые требования
• PM организовал встречу, я подготовил альтернативные варианты с плюсами и минусами
• Вместе нашли оптимальное решение
• Результат: все стороны согласны, нет переделок

Роли и ответственность

Ответственность PM:

• Управление timeline (график работ)
• Управление ресурсами (кто, когда работает)
• Управление рисками проекта
• Коммуникация со stakeholder'ами о статусе
• Закрытие проекта

Ответственность BA:

• Полное и правильное описание требований
• Анализ и исследование
• Разработка спецификаций и документации
• Участие в тестировании и приёмке

Пересечение:

• Оба заинтересованы в успехе проекта
• Оба работают с stakeholder'ами
• Оба должны знать о рисках и проблемах
• Оба должны быть гибкими при управлении требованиями

Что я ценю в хорошем PM

1. Уважение к анализу — понимает, что хорошие требования экономят время потом
2. Открытость к коммуникации — легко обсудить проблемы или риски
3. Справедливое распределение — не навязывает нереалистичные сроки
4. Поддержка в конфликтах — помогает отстоять качество требований
5. Доверие — дал мне автономию в моей области

Чему я научился

• Баланс между идеальным анализом и практическими сроками
• Как быстро коммуницировать результаты анализа
• Управление expectations stakeholder'ов
• Как быть полезным для PM, а не препятствием
• Значимость регулярных синхронизаций

В целом, опыт работы с PM'ами научил меня, что успех проекта — это командная работа, и хорошие отношения между BA и PM критичны для результата.