Кто давал бриф в компании?

Анализ запроса и контекст роли

Прежде чем ответить на вопрос «Кто давал бриф в компании?» напрямую, важно уточнить, что в моей практике как IT Project Manager под термином «бриф» (от англ. brief — краткий, сжатый) чаще всего понимается исходный документ, описывающий бизнес-задачу, требования, цели и ограничения проекта. Он служит отправной точкой для планирования и уточнения деталей. Источник брифа напрямую зависит от организационной структуры компании, процессов управления требованиями и типа проекта (внутренний, внешний, продуктовая разработка, заказная).

Ключевые источники брифа в IT-компаниях

В зависимости от модели работы, бриф может исходить от разных ролей:

1. Внешние заказчики или клиенты (Agency/Outsource-модель)

• Прямой заказчик (например, представитель бизнеса клиента — Product Owner, Brand Manager, IT-директор).
• Бизнес-аналитик или консультант со стороны клиента, который формализует потребности.
• Коммерческое подразделение нашей компании (продакт-менеджеры, аккаунт-менеджеры), которые собирают и транслируют требования после предпродажных переговоров.

2. Внутренние стейкхолдеры (Product/In-house-модель)

• Владелец продукта (Product Owner) или Продуктовый менеджер, который формирует видение продукта на основе рыночных исследований, аналитики и обратной связи от пользователей.
• Бизнес-подразделение (например, отдел маркетинга, продаж, финансов), инициирующее проект для решения внутренних задач (например, разработка CRM, дашборда).
• Высшее руководство (CEO, CTO, CIO), задающее стратегические цели и приоритеты.

3. Технические или процессные инициаторы

• Архитекторы или тимлиды, предлагающие улучшения инфраструктуры, технический долг, миграции.
• Отдел аналитики или данных, требующий новые инструменты для обработки информации.

Мой практический опыт работы с брифом

В проектах, которыми я управлял, процесс обычно выглядел так:

1. Получение исходного документа: Бриф поступал от аккаунт-менеджера (во внешних проектах) или от Product Owner (во внутренних). Например, в одном из проектов по разработке мобильного банкинга бриф был представлен в виде презентации от директора по цифровым технологиям банка-клиента.

2. Анализ и уточнение: Полученный бриф редко бывал полным и однозначным. Моя задача как PM — организовать серию workshops с ключевыми сторонами для детализации. Использовались техники:

   • Собеседования с заказчиком и конечными пользователями.
   • Мозговые штурмы с командой разработки.
   • Прототипирование для проверки гипотез.

# Пример структуры данных из брифа, с которой часто работаем на старте
class ProjectBrief:
    def __init__(self, source, objectives, success_metrics, constraints):
        self.source = source  # Кто предоставил: "client", "internal_po", "management"
        self.business_goals = objectives  # Бизнес-цели: список
        self.success_criteria = success_metrics  # KPI: например, {"conversion": 15%, "load_time": "<2s"}
        self.constraints = constraints  # Ограничения: бюджет, сроки, технологический стек

1. Формализация в рабочие артефакты: На основе брифа и уточнений мы создавали:
   • Устав проекта (Project Charter).
   • Бэклог продукта в формате User Stories с критериями приемки.
   • Техническое задание (ТЗ) или Software Requirements Specification (SRS) — в зависимости от зрелости процессов.

Критически важные аспекты работы с брифом

• Проверка на полноту и противоречия: Часто бриф содержит размытые формулировки типа «сделать удобно» или «увеличить производительность». Задача PM — перевести это в измеримые требования.
• Выявление скрытых стейкхолдеров: Тот, кто дал бриф, — не всегда ключевой лицо, принимающее решения. Важно выявить всех влиятельных персон.
• Управление ожиданиями: Ранняя оценка усилий и рисков на основе брифа позволяет сразу скорректировать ожидания заказчика.

Вывод: В моей практике первичный бриф чаще всего поступал от представителя бизнеса заказчика (в аутсорсе) или внутреннего Product Owner (в продукте). Однако ключевая ответственность IT Project Manager — не просто принять бриф, а активно участвовать в его детализации, валидации и трансформации в исполняемый план, выступая связующим звеном между бизнесом и технической командой. Умение задавать правильные вопросы и выявлять истинные потребности за брифами — один из самых важных навыков успешного управляющего проектами.