Приоритезирует ли Project Manager задачи для тебя

Работа с приоритетами задач от Project Manager

В контексте разработки на Unity, взаимодействие с Project Manager (PM) по вопросам приоритизации задач является стандартной практикой. Ответ на ваш вопрос неоднозначен, так как зависит от модели работы команды, но в большинстве случаев можно выделить следующее.

Общее правило: совместная приоритезация

Обычно PM не просто назначает мне задачи в одностороннем порядке. Процесс является совместным и итеративным. PM формирует бэклог проекта (например, в Jira, Trello, Azure DevOps), который отражает бизнес-ценность, требования стейкхолдеров и зависимости. Однако мое участие как разработчика-эксперта критически важно по нескольким причинам:

1. Техническая оценка сложности: PM может видеть задачу как «добавить кнопку на экран», но для меня эта задача может включать перепроектирование UI-системы, интеграцию с бэкендом или оптимизацию. Без моей оценки PM не может корректно расставить приоритеты.
2. Выявление технических зависимостей: Часто задача «А» не может быть выполнена, пока не реализована неочевидная для не-технического специалиста задача «Б» (например, создание базовой системы событий). Я должен эти зависимости выявлять и сообщать PM.
3. Учет технического долга: Иногда в список приоритетов необходимо включать задачи по рефакторингу, оптимизации (профилирование памяти или CPU в Profiler) или исправлению критической архитектурной проблемы. PM полагается на мою экспертизу в этих вопросах.

Типичный процесс планирования спринта в Agile-команде

// Пример: Оценка задачи на планировании
public class SprintPlanning
{
    public UserStory EvaluateStory(UserStory story, Developer developer)
    {
        // PM описывает бизнес-ценность и Acceptance Criteria
        if (story.Title == "Реализовать систему сохранения прогресса")
        {
            // Разработчик анализирует техническую сложность
            int estimatedComplexity = developer.EstimateComplexity(story);
            story.SetStoryPoints(estimatedComplexity);

            // Разработчик выявляет зависимости и риски
            if (!IsSaveSystemArchitectureReady())
            {
                developer.FlagDependency("Требуется проектирование базового модуля данных");
            }
        }
        return story;
    }
}

В начале спринта или планировочного совещания:

• PM представляет список задач, ранжированный по бизнес-приоритету.
• Я, как разработчик, даю технический комментарий: оцениваю усилия, указываю на зависимости, предлагаю альтернативные решения или иной порядок выполнения для повышения эффективности.
• Вместе мы приходим к согласованному плану спринта, который учитывает оба аспекта: бизнес-ценность и техническую реализуемость.

Ситуации, когда приоритеты диктует PM

Однако бывают случаи, когда приоритеты задач определяются в одностороннем порядке, и я обязан им следовать:

• Критические баги в продакшене, влияющие на доход (например, падение сервера покупок).
• Срочные требования издателя или ключевого клиента со строгим дедлайном.
• Внезапные изменения на рынке, требующие немедленного изменения в продукте.

В таких ситуациях PM ставит задачу как блокер с высшим приоритетом, и моя задача — быстро переключиться, проанализировать проблему и приступить к решению.

Заключение

Таким образом, PM приоритезирует задачи для команды, но этот процесс не может быть эффективным без моего активного участия как технического эксперта. Идеальная модель — это диалог, где PM представляет видение «что» и «зачем», а я — «как» и «сколько времени». Итоговый приоритет всегда является результатом этого компромисса между бизнес-потребностями и технической реальностью проекта. Моя ответственность — не просто слепо выполнять список задач, а быть партнером в планировании, чтобы мы как команда достигали целей наиболее рациональным путем.