Представь что на проекте нет PM и тебе прилетает 7 легких и 3 сложных задачи с одинаковым приоритетом как ты их будешь приоритезировать?

Стратегия приоритизации задач при отсутствии PM

В ситуации, когда нет Project Manager, разработчик должен взять на себя роль временного координатора. Приоритизация в таком контексте — это не только про техническую сложность, но и про управление потоком ценности для команды и продукта, минимизацию рисков и поддержание предсказуемости разработки. Если все задачи имеют заявленный одинаковый бизнес-приоритет, я буду использовать комбинацию факторов для создания эффективного порядка выполнения.

Ключевые критерии для оценки

Я выделяю несколько основных критериев для принятия решения:

• Зависимости и блокировки: Задачи, которые блокируют работу других разработчиков или смежных команд (например, бэкенд, дизайнеры), получают наивысший приоритет, даже если они сложные. Разблокировка коллег создает множитель эффекта.
• Риск и неопределенность: Сложные задачи часто несут в себе высокую неопределенность. Лучше начать исследование (Spike) или выполнить часть такой задачи раньше, чтобы снизить риск срыва сроков в будущем.
• Баланс «потока завершения»: Непрерывное завершение задач важно для морального состояния команды и видимости прогресса. Череда исключительно сложных задач может привести к выгоранию и ощущению «топтания на месте».
• Влияние на архитектуру: Задачи, результаты которых станут фундаментом для последующих фич (например, создание нового модуля, внедрение архитектурного паттерна), стоит делать раньше.
• Временные затраты: Легкие задачи можно оценить точнее. Их завершение дает более надежный прогноз по оставшемуся времени.

Практический план действий

Исходя из этих принципов, мой план будет следующим:

1. Быстрая аналитическая сессия (1. 5-2 часа):

    *   Создаю простую таблицу для всех 10 задач.
    *   По каждому пункту оцениваю: есть ли **зависимости от/для других**, примерный уровень **неопределенности (низкий/средний/высокий)**, предполагаемый **объем работы (в story points или часах)**.
    *   Провожу короткое обсуждение с тимлидом или другими senior-off разработчиками, чтобы выявить скрытые зависимости и собрать мнения.

1. Формирование очереди выполнения:

    *   **Первыми** берусь за сложные задачи с **высоким уровнем неопределенности** или те, что **блокируют других**. Цель — как можно раньше начать исследование, прототипирование или диалог с заказчиком для уточнения требований.

```swift
// Пример: Сложная задача — «Интегрировать новую платежную систему X».
// Первый шаг — не писать код, а провести Spike:
// 1. Изучить документацию SDK.
// 2. Создать тестовый проект для проверки работы флоу.
// 3. Выявить потенциальные проблемы (фоновые процессы, сертификаты).
```

    *   **Параллельно или сразу после** начинаю выполнять **легкие задачи, которые имеют зависимости для коллег**. Это быстро разблокирует работу всей команды.
    *   Далее создаю **ритм «сложная-легкая»** или даже «сложная-две легкие». После завершения исследования сложной задачи и составления четкого плана по ней, я могу взять 1-2 легкие задачи, чтобы «очистить» бэклог, почувствовать прогресс и дать мозгу перезагрузиться перед глубокой реализацией сложной фичи.

```swift
// Допустим, после Spike по платежке я понимаю, что реализация займет 5 дней.
// Вместо того чтобы погружаться в нее на всю неделю, я:
// 1. Делаю легкую задачу «Исправить краш в виджете» (1 день).
// 2. Начинаю реализацию платежного модуля (2 дня).
// 3. Делаю еще одну легкую задачу «Добавить анимацию обновления» (0.5 дня).
// 4. Завершаю платежный модуль (3 дня).
```

    *   Легкие задачи, **не связанные с зависимостями**, равномерно распределяю между этапами работы над сложными задачами как «наполнители» для поддержания скорости завершения.

1. Коммуникация и прозрачность:

    *   Я обязательно документирую принятый план и выявленные зависимости в общем инструменте (Jira, Linear, Confluence) и ставлю в известность команду и стейкхолдеров. Краткое сообщение: «Из.

за отсутствия PM я приоритезировал задачи на основе зависимостей и рисков. Текущий план: ...».

    *   Регулярно (раз в день или два) обновляю статус, особенно по сложным задачам с неопределенностью.

Итог

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