Ставишь ли оценки вместе с аналитиком

Общая философия сотрудничества с аналитиком

Однозначно да. Я, как IT Project Manager, считаю совместную постановку оценок с аналитиком одним из краеугольных камней эффективного и реалистичного планирования. Это не просто формальность, а ключевой этап, который минимизирует риски и повышает предсказуемость проекта. Я воспринимаю аналитика не как поставщика готовых требований, а как стратегического партнера, чья экспертиза в предметной области критически важна для понимания реальной сложности задач.

Почему это неработающая практика — оценки только от PM или только от аналитика?

• Оценки только от PM (меня): Рискнут быть основанными на поверхностном понимании, исторических аналогиях («такое мы делали за 5 дней») без учета специфики нового контекста. Не учитывают детали реализации, которые видит только аналитик, погруженный в документирование.
• Оценки только от аналитика: Могут быть излишне оптимистичными (не видя организационных сложностей, зависимостей, нагрузку на команду) или, наоборот, пессимистичными (закладывая избыточный «буфер» на все гипотетические сценарии). Часто не включают трудозатраты на саму аналитику, согласования и доработку ТЗ.

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

Практический процесс совместной оценки

Наш процесс выглядит как серия итеративных уточнений:

1. Предварительная нарезка и приоритизация. Аналитик структурирует высокоуровневый объем работ (Epics, User Stories). Вместе мы расставляем бизнес-приоритеты.
2. Сессия глубокого погружения. Проводим воркшоп с ключевыми разработчиками (тимлидом, архитектором) и аналитиком.

    *   Аналитик представляет **детализированные сценарии (use cases)**, бизнес-логику, нефункциональные требования.
    *   Разработчики задают уточняющие вопросы, вскрывают «серые зоны», предлагают технические решения.
    *   Я, как PM, модерирую дискуссию, фокусирую ее на оценке, выявляю **скрытые зависимости**, **риски** (например, необходимость интеграции с legacy-системой, о которой упомянул аналитик) и **организационные моменты** (доступ к средам, нужна ли помощь DevOps).

1. Метод оценки. Чаще всего используем планирование покера (Planning Poker). Это не только дает оценку, но и выравнивает понимание задачи всей командой. Я, как правило, не голосую, но участвую в обсуждении, помогая команде учитывать нетехнические аспекты.

   # Пример того, как мы могли бы структурировать выводы после сессии:
   user_story = {
       "id": "US-101",
       "title": "Реализация двухфакторной аутентификации через SMS",
       "описание": "Пользователь может включить 2FA в личном кабинете...",
       "оценка_команды": "5 story points", # Результат Planning Poker
       "ключевые_зависимости": [
           "Интеграция с SMS-шлюзом (договор с провайдером)",
           "Обновление мобильного приложения для ввода кода"
       ],
       "открытые_вопросы_от_аналитика": [
           "Сценарий восстановления доступа при утере телефона?"
       ],
       "нефункциональные_требования": "Время доставки SMS < 10 сек. (аналитик)"
   }
   

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

    *   **Трудозатраты на саму аналитику:** Уточнение, проработка edge-кейсов, написание и согласование ТЗ.
    *   **Время на тестирование (QA):** Согласуем с тест-лидом, исходя из сложности функционала.
    *   **Время на развертывание и риски.**

Итогом этого процесса является не просто число в Jira, а разделяемое понимание сложности, границ задачи и ее рисков между мной, аналитиком и командой разработки.

Моя роль в этом тандеме

• Фасилитатор: Создаю условия для эффективного диалога между аналитиком и разработчиками.
• Интегратор: Свожу воедино технические оценки, оценки на аналитику, тестирование, управленческие риски и формирую итоговую оценку для стейкхолдеров (часто в диапазоне, например, 20-30 чел/дней с учетом всех фаз).
• Реалист: Помогаю аналитику и команде найти баланс между идеальным решением и ограничениями по времени и бюджету. Задаю вопросы: «Что минимально необходимо для выполнения этой user story?», «Что можно вынести в отдельную задачу на следующую итерацию?».
• Коммуникатор: Прозрачно доношу до заказчика или спонсора обоснование полученных оценок, используя аргументы как от аналитика (бизнес-сложность), так и от команды (техническая сложность).

Вывод: Совместная постановка оценок — это не «снятие с себя ответственности». Это профессиональная практика, которая повышает качество планирования, укрепляет взаимопонимание в проектной команде и, в конечном счете, ведет к более предсказуемым результатам и довольным заказчикам. Без глубокого погружения аналитика в оценку любая цифра будет строиться на зыбком фундаменте.