Как распределяли задачи между разработчиками

# Как распределяли задачи между разработчиками

Это управленческий вопрос, который показывает не только технические знания, но и навыки коммуникации, планирования и лидерства. Расскажу о подходе, который использовал в реальных проектах.

Контекст: Типичный проект

На последнем проекте я работал в Agile команде из 6-8 разработчиков:

• 2 Senior'а (я + ещё один)
• 3-4 Mid'а
• 1-2 Junior'а

Мы разрабатывали микросервис на Java, требующий регулярных релизов каждые 2 недели.

Процесс распределения задач

Фаза 1: Planning Meeting (начало спринта)

Документ: Epic → User Story → Task → Subtask

Epic (большая функция): "Система рекомендаций"
    ↓
User Story: "Как пользователь, я хочу видеть рекомендации по интересам"
    ├─ Task 1: "Добавить API endpoint GET /recommendations"
    ├─ Task 2: "Написать ML модель для рекомендаций"
    ├─ Task 3: "Добавить кэширование результатов"
    └─ Task 4: "Написать тесты и документацию"

Фаза 2: Оценка размера

Использовали Story Points (Fibonacci: 1, 2, 3, 5, 8, 13):

Task 1: API endpoint - 5 points (Mid developers, 2-3 дня)
Task 2: ML модель - 13 points (Senior, 5-7 дней)
Task 3: Кэширование - 3 points (Junior, 1-2 дня)
Task 4: Тесты и docs - 5 points (Mid, 2-3 дня)

Общо на User Story: 26 points
Велосити команды: ~25 points в спринт
Знач, укладываемся в 2-недельный спринт

Критерии распределения

1. По уровню компетентности

// ВЫСОКАЯ СЛОЖНОСТЬ → Senior Developer
// Архитектурные решения, оптимизация, проблемные области
private void assignComplexTask(
    Task task,
    List<Developer> team
) {
    Developer senior = team.stream()
        .filter(d -> d.getLevel() == Level.SENIOR)
        .filter(d -> d.hasExperienceIn(task.getDomain()))
        .filter(d -> d.getWorkload() < 80)
        .findFirst()
        .orElseThrow();
    
    task.assignTo(senior);
}

// СРЕДНЯЯ СЛОЖНОСТЬ → Mid Developer
Developer mid = team.stream()
    .filter(d -> d.getLevel() == Level.MID)
    .filter(d -> d.hasExperienceIn(task.getDomain()))
    .min(Comparator.comparingInt(Developer::getWorkload))
    .orElseThrow();

task.assignTo(mid);

// НИЗКАЯ СЛОЖНОСТЬ → Junior + Mentoring
Developer junior = team.stream()
    .filter(d -> d.getLevel() == Level.JUNIOR)
    .filter(d -> d.isReadyForChallenge())
    .min(Comparator.comparingInt(Developer::getWorkload))
    .orElseThrow();

Developer mentor = findMentor(junior);
task.assignTo(junior);
task.setMentor(mentor);  // Менторинг для обучения

2. По размеру задачи

Задача 1-3 points:
  → Делают Junior разработчики (обучение)
  → Обычно есть менто́р

Задача 5 points:
  → Mid разработчики (основная работа)
  → Иногда Senior для сложных частей

Задача 8+ points:
  → Надо разбить на подзадачи!
  → Или Senior + Mid (парное программирование)

3. По типу работы

Типы задач:

[BACKEND] Сложная логика на Java
  → Senior разработчик
  → Причина: критично для production

[FRONTEND] UI компоненты
  → Mid разработчик
  → (у нас был фронтенд team, но я знаю весь стек)

[DEVOPS] Миграция на новый сервер
  → Senior или специальный DevOps инженер

[TESTING] Покрытие тестами
  → Mid + Junior
  → Junior пишет, Mid ревьюит

[DOCS] Документация
  → Автор кода + Tech Writer
  → После код ревью

Пример реального распределения

Sprint Planning встреча (вторник, 10:00)

I: "Ребята, обсудим спринт 15"

Бэклог для спринта:
1. [13pts] Реализовать ML рекомендации
   - Сложность: Высокая
   - Требует: История SQL, ML знания
   → Я (Senior): "Возьму это, нужна неделя"
   → Риск: Невысокий, знаю ML

2. [5pts] REST API endpoint для рекомендаций
   - Сложность: Средняя
   - Требует: Spring Boot, REST опыт
   → Алекс (Mid): "Я возьму, обычно делаю за 2-3 дня"
   → Это после того, как я закончу core логику

3. [5pts] Redis кэширование результатов
   - Сложность: Средняя
   - Требует: Redis опыт
   → Катя (Mid): "Есть опыт с Redis, возьму"
   → Параллельно основной задаче

4. [3pts] Unit тесты для API
   - Сложность: Низкая
   - Требует: MockMvc, TestNG
   → Миша (Junior): "Хочу писать тесты"
   → Я буду менто́р: review + помощь если запрет

5. [5pts] Интеграционные тесты в базе
   - Сложность: Средняя
   - Требует: TestContainers, PostgreSQL
   → Алекс или я after code review Миши

Итого: 31 points, велосити 25 → Обсуждаем что сдвинуть

Техники распределения

Техника 1: Матрица умений

Значение: O - не может, 1 - учится, 2 - может, 3 - эксперт

Разработчик | Java | Spring | PostgreSQL | Redis | K8s
──────────────────────────────────────────────────────
Алекс (Mid) │  3   │   3    │     2      │   1   │  0
Катя (Mid)  │  2   │   2    │     3      │   3   │  1
Миша (Jr)   │  1   │   1    │     1      │   0   │  0

Задача "Оптимизация PostgreSQL запросов" → Катя (3)
Задача "Настройка Redis кластера" → Катя (3) или Senior
Задача "Разработка Spring сервиса" → Алекс (3)
Задача "Обучение Миши K8s" → Senior менторит

Техника 2: Work-in-progress лимит (WIP)

public class TaskDistribution {
    
    private int maxWipPerDeveloper = 3;  // Не более 3 задач одновременно
    
    public void assignTask(Task task, Developer developer) {
        int currentWip = developer.getActiveTasks().size();
        
        if (currentWip >= maxWipPerDeveloper) {
            throw new DeveloperOverloadedException(
                "Разработчик " + developer.getName() + 
                " уже работает над " + currentWip + " задачами"
            );
        }
        
        task.assignTo(developer);
    }
}

Техника 3: Зависимости между задачами

Task A: ML модель (Senior, 13 points) → MUST FIRST
   ↓ зависит от
Task B: API endpoint (Mid, 5 points) → AFTER A
   ↓ зависит от
Task C: Frontend интеграция (Frontend Team, 3 points) → AFTER B


WEEK 1-2:
├─ Senior: Task A (ML модель)
├─ Junior: Task D (unit тесты) - независимая
└─ Frontend: другие задачи

WEEK 2-3:
├─ Mid: Task B (API) - как только Task A готова
├─ Mid: Task C (кэш) - параллельно
└─ Frontend: Task C (интеграция)

Обработка проблем

Проблема 1: Разработчик застрял

// Признаки:
if (developer.getLastUpdate() > 2.days()) {
    // Больше 2 дней без прогресса
    
    // Действие:
    organizeCodeReview(task);
    assignMentor(developer);
    
    // Или переассайн:
    if (task.isPriorityBlocker()) {
        reassignToSenior(task);
        Junior_learns_by_watching();
    }
}

Проблема 2: Разработчик перегружен

if (developer.getWorkload() > 90%) {
    // Перегруз
    
    // Перераспределяем часть задач:
    Task lowest = developer.getActiveTasks()
        .stream()
        .filter(t -> !t.isBlocking())
        .min(Comparator.comparingInt(Task::getPriority))
        .orElse(null);
    
    if (lowest != null) {
        AnotherDeveloper available = findAvailable();
        lowest.reassignTo(available);
    }
}

Проблема 3: Неправильная оценка

Социология: Люди недооценивают сложность (Optimism bias)

Если Task оценена в 5 points, но Senior говорит 13:
1. Доверяй Senior (они видят скрытые сложности)
2. Перепланируй спринт
3. Разбей на подзадачи
4. Затем переоцени

// Code:
if (developer.getActualTime() > estimatedTime * 1.5) {
    task.updateEstimate(developer.getActualTime());
    futureTasksWithSimilarity.updateEstimate(upward);
}

Лучшие практики

1. Понимай уровень каждого разработчика

   • Проводи 1-on-1 встречи
   • Обсуждай карьерные цели
   • Подбирай задачи для роста

2. Балансируй между скоростью и обучением

   • Не все задачи Senior'ам
   • Junior'ам даёшь возможность учиться
   • Mid'ы растут в лидеров

3. Распределяй зависимостей логично

   • Критичные на Senior'ов
   • Независимые параллельно
   • Дай время на инициацию

4. Коммуницируй публично

   • Board в Jira/Trello (видно всем)
   • Ежедневные standup (5 мин)
   • Еженедельный retro (улучшения)

5. Будь справедлив

   • Не закрепляй Junior'а за сложными
   • Не отнимай интересные задачи
   • Учитывай личные обстоятельства

Инструменты

Мы использовали:

• Jira: Planning, tracking, story points
• Confluence: Документирование решений
• Slack: Ежедневная коммуникация
• GitLab: Code review, merge requests
• Jenkins: Automated testing

Итого: Формула успеха

Успешное распределение =
    правильный уровень сложности ×
    понимание каждого разработчика ×
    логичные зависимости ×
    менторинг и поддержка ×
    справедливая оценка времени

Большая часть - это понимание людей, а не только технических навыков!