Кто ставил задачи?

Как организуется постановка задач в моей практике

За годы работы я видел несколько моделей, но наиболее эффективной считаю гибридную модель с сильным Product Owner (PO) в рамках Scrum/Kanban. Ответ на вопрос «кто ставит задачи» не сводится к одному человеку — это процесс с четкими ролями и ответственностью.

Ключевые роли в процессе

1. Product Owner (Владелец продукта)

    *   **Что делает:** Формирует долгосрочное **Product Vision** и **Product Roadmap**. Отвечает за **бэклог продукта** — его наполнение, приоритизацию и ясность. Его главная задача — максимизировать ценность продукта для бизнеса и пользователей.
    *   **Как ставит задачи:** Пишет **User Stories** и **Epics**, определяет Acceptance Criteria (критерии приемки). Он отвечает на вопрос **«ЧТО** нужно сделать и **ЗАЧЕМ**». Например: *«Как пользователь, я хочу восстановить пароль через email, чтобы вернуться в аккаунт при утере данных»*.

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

    *   **Что делает:** Отвечает за техническое качество, архитектурную целостность, нефункциональные требования (NFR) и выбор технологий.
    *   **Как ставит задачи:** Формулирует **технические задачи (Tech Debt, Spikes, Refactoring)**. Например: *«Повысить покрытие модуля авторизации юнит-тестами до 80%»* или *«Исследовать возможность миграции на Swift Concurrency для модуля сетевого слоя»*.

1. Команда разработки (iOS + бэкенд + QA + дизайнер)

    *   **Что делает:** Активно участвует в уточнении задач на **планировании (Planning) и рефинментах бэклога (Backlog Refinement)**.
    *   **Как ставит задачи:** Разбивает крупные истории на подзадачи, выявляет скрытые сложности, предлагает альтернативные технические реализации. Часто сами инициируют задачи по улучшению инструментария или CI/CD.

Процесс превращения идеи в задачу

Вот типичный цикл, который я описываю на собеседовании:

// Это не код, а схема процесса в псевдокоде :)
struct TaskCreationProcess {
    // 1. Идея из разных источников
    let ideaSources: [IdeaSource] = [.analytics, .userFeedback, .businessRequest, .techTeam]

    // 2. Обработка и приоритизация PO
    func createBacklogItem(from idea: Idea) -> BacklogItem {
        // PO формирует цель (Goal) и ценность (Value)
        let userStory = UserStory(
            description: "Как <роль>, я хочу <возможность>, чтобы <ценность>",
            acceptanceCriteria: ["Критерий 1", "Критерий 2"]
        )
        return userStory
    }

    // 3. Совместное уточнение с командой
    func refine(item: BacklogItem, with team: Team) -> [Task] {
        // На рефинменте команда задает вопросы, предлагает решения
        let tasks = team.decomposeAndClarify(item) // -> [UI_Task, Network_Task, Logic_Task, Test_Task]
        return tasks
    }

    // 4. Фиксация в инструменте (Jira, Linear, etc.)
    let readyForSprintTask: Task = Task(
        id: "IOS-123",
        title: "Реализовать экран восстановления партива",
        type: .feature,
        description: detailedSpec,
        techNotes: "Использовать SwiftUI, добавить локализацию",
        points: 5
    )
}

Реалистичный пример из практики

Ситуация: В приложении растет количество отказов на экране оплаты.

1. Источник задачи: Аналитик приносит воронку и метрики PO.
2. Задача от PO: «Увеличить конверсию на экране оплаты на 15% в следующем квартале» (Epic).
3. Уточнение: На воркшопе с дизайнером, аналитиком и разработчиками решаем, что одна из гипотез — запутаный процесс CVV ввода.
4. Конкретная User Story: «Как пользователь, я хочу видеть иконку места нахождения CVV на карте, чтобы быстро найти и ввести его, завершив оплату без ошибок».
5. Техническая детализация командой: На планировании iOS-разработчик (я) разбиваю историю на задачи:

    *   *Добавить UIImageView с подсказкой в поле ввода CVV.*
    *   *Интегрировать анимацию появления подсказки по тапу на info-иконку.*
    *   *Написать юнит-тесты для валидации нового UI-состояния.*
    *   *Добавить A/B-тест для отслеживания метрики успешности оплаты.*

Важные принципы, которые я подчеркиваю

• Прозрачность: Бэклог открыт для всей команды, каждый может предложить улучшение.
• Сотрудничество, а не диктат: Лучшие задачи рождаются в диалоге между PO (понимающим рынок) и командой (понимающей возможности техники).
• INVEST-критерии: Хорошая задача — Independent, Negotiable, Valuable, Estimable, Small, Testable.
• Уровень детализации: Задача должна быть достаточно детальной для начала работы, но не ограничивать разработчика в выборе оптимального технического решения.

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