Кто ставил задачи разработчикам на проекте?

Кто должен ставить задачи разработчикам: роль Business Analyst

Вопрос о том, кто ставит задачи разработчикам, касается фундаментального вопроса организации работы и роли Business Analyst в проекте.

Основные роли, ставящие задачи

Product Manager / Business Analyst

• Определяет, что нужно разработать
• Формулирует требования через User Stories, Acceptance Criteria
• Ставит приоритеты и сроки исходя из бизнес-целей
• Взаимодействует с заинтересованными сторонами (stakeholders)

Tech Lead / Архитектор

• Определяет, как это реализовать
• Ставит технические требования и constraints
• Декомпозирует задачу на subtasks для разработчиков
• Обеспечивает соответствие архитектуре

Scrum Master (в Agile)

• Фасилитирует процесс постановки задач
• Помогает разработчикам разобраться в требованиях
• Удаляет блокеры
• Не ставит сами задачи, а координирует процесс

Модель в моём опыте

В успешных проектах существует clear separation of concerns:

1. Business Analyst встречается со stakeholders, собирает requirements

2. Создаёт User Story:

   AS A сотрудник отдела продаж
   I WANT TO экспортировать список контактов в CSV
   SO THAT I CAN загрузить их в CRM
   
   Acceptance Criteria:
   - Кнопка "Export" видна на странице контактов
   - Экспорт включает колонки: ФИО, Email, Phone, Company
   - Файл кодируется в UTF-8
   - Обработать 10K+ записей без таймаутов
   

3. Tech Lead прочитал требования и создаёт technical tasks:

   • Добавить endpoint /api/contacts/export
   • Интегрировать library для CSV generation
   • Добавить pagination в query для больших объёмов
   • Написать unit tests (coverage >80%)

4. Разработчик получает конкретные tasks и реализует

Когда я вижу проблемы

❌ BA ставит детальные технические задачи

• "Добавь caching в Redis с TTL 300 сек"
• Это не компетенция BA, это решение Tech Lead
• Разработчик теряет autonomy

❌ Никто не ставит задачи (full autonomy)

• Разработчик угадывает требования
• Результат часто не совпадает с ожиданиями
• Много переделок

✅ Правильно: BA + Tech Lead

• BA: четкие requirements + acceptance criteria
• Tech Lead: декомпозиция на технические задачи
• Разработчик: выбирает как реализовать внутри constraints

Пример конфликта

Ситуация: BA говорит "Нужна авторизация через OAuth"

Проблема: Это уже решение, а не требование.

Правильно:

• BA: "Пользователи не хотят помнить пароли (требование)"
• Tech Lead: "Предлагаю OAuth через Google и GitHub (решение)"
• Разработчик: "Окей, реализую с использованием oauth2 library"

Взаимодействие в Agile команде

Sprint Planning:

• BA представляет backlog items (user stories)
• Tech Lead оценивает effort, предлагает декомпозицию
• Разработчики берут задачи и коммитятся

Daily Standup:

• Разработчик: "вчера реализовал экспорт CSV, сегодня пишу тесты"
• BA: уточняет, соответствует ли это требованиям
• Tech Lead: предлагает помощь с technical issues

Вывод

Business Analyst не ставит задачи разработчикам в смысле деталей реализации.

BA ставит требования и критерии приёма (what), а Tech Lead / Архитектор ставит технические задачи (how).

Это разделение ответственности:

• Защищает от микроменеджмента
• Сохраняет техническую свободу разработчикам
• Обеспечивает ясность требований
• Минимизирует пересделки и confusion