Что будешь делать если считаешь задачу бесполезной?

Стратегия работы с субъективно «бесполезными» задачами в проекте

Как Senior IT Project Manager с более чем 10-летним опытом, я не раз сталкивался с ситуациями, когда задача на первый взгляд казалась малополезной или неэффективной с точки зрения бизнес-целей. Ключевой принцип здесь — системный анализ до принятия решения, а не эмоциональное отвержение. «Бесполезность» часто оказывается иллюзией, вызванной недостатком контекста или понимания.

Алгоритм действий

Мой подход структурирован и следует четкой последовательности:

1. Верификация и углубленный анализ.

    *   **Уточняю источник требования:** Задача пришла от стейкхолдера, из бэклога продукта, как технический долг? Это важно для понимания ее природы.
    *   **Ищу скрытый контекст:** Провожу встречи с инициатором задачи (Product Owner, бизнес-аналитик, ключевой пользователь), чтобы выяснить:
        *   Какая бизнес-проблема или гипотеза стоит за задачей?
        *   Каковы ожидаемые метрики успеха (OKR, KPI)?
        *   Есть ли связанные регуляторные требования или договоренности?
    *   **Анализирую «стоимость бездействия»:** Что произойдет, если задачу *не* выполнить? Это часто выявляет риски, не очевидные на первый взгляд (безопасность, постепенная деградация системы, будущие блокирующие зависимости).

1. Количественная оценка и приоритезация.

    *   Использую метод **WSJF (Weighted Shortest Job First)** или подобный для сравнения ценности задачи с другими в бэклоге, даже если ее ценность изначально неочевидна.
    *   Пытаюсь формализовать ценность, даже если в гипотетических единицах. Пример структуры для обсуждения:

```json
{
  "task_id": "TASK-123",
  "perceived_value": "low",
  "potential_risks_if_ignored": ["security_patch", "tech_debt_compound"],
  "linked_strategic_goal": "Platform Stability",
  "effort_estimate": "5 story_points",
  "suggested_approach": "Discuss at next PI Planning"
}
```

3. Эскалация и прозрачная коммуникация.

    *   Если после анализа я остаюсь при убеждении, что задача не создает ценности, я **не игнорирую ее, а готовлю обоснованное предложение**.
    *   Создаю краткий документ или презентацию для **Steering Committee** или ключевых стейкхолдеров, где:
        *   Излагаю понимание задачи и ее предполагаемых целей.
        *   Привожу данные анализа: затраты команды (человеко-дни), возможное влияние на timeline других высокоприоритетных задач.
        *   Четко формулирую альтернативу: «Отложить», «Отменить», «Заменить более эффективным решением».
        *   **Важно:** Предлагаю альтернативу, а не просто критикую. Например: «Вместо реализации отдельного отчета Х, предлагаем расширить фильтры в существующем отчете Y, что закроет 80% потребности за 30% времени».

Пример из практики и ключевые уроки

Ситуация: В одном из e-commerce проектов команда получила задачу на создание сложного кастомного отчета для маркетинга, оцененную в 40 человеко-дней. На первый взгляд, отчет дублировал функциональность BI-системы.

Мои действия:

1. Провел воркшоп с маркетологами: выяснил, что им нужны определенные данные в реальном времени для оперативных решений, а BI-отчет строился с задержкой.
2. Проанализировал архитектуру: обнаружил, что нужный слой данных уже существует в кеше.
3. Вместо 40-дневного кастомного отчета предложил и протопировал за 3 дня REST API endpoint, отдающий сырые данные. Маркетинг подключил к нему свой Google Sheets скрипт.
4. Результат: Потребность была закрыта за 5% от первоначально оцененного времени. Задача оказалась не «бесполезной», а просто неправильно сформулированной.

Главные выводы, которые я усвоил:

• «Бесполезная задача» — это чаще всего «недоисследованная задача». Роль PM — докапываться до сути.
• Прямое неподчинение или саботаж неприемлемы. Профессионализм — в аргументированном диалоге и поиске оптимальных решений.
• Прозрачность решений критична. Даже если задачу исключают из бэклога, это должно быть задокументировано и согласовано, чтобы избежать «зомби-требований» в будущем.

В итоге, мой ответ на «бесполезную» задачу — это не действие, а мини-проект по исследованию: анализ, количественная оценка, коммуникация и поиск оптимального для бизнеса и команды решения.