Куда записываешь задачи?

Куда записываешь задачи?

Как BA я работаю с несколькими инструментами в зависимости от типа задачи и контекста проекта. Рассказываю про каждый.

Основной инструмент — Jira

Для чего

• Создание и отслеживание User Stories, Bug Reports, Tasks
• Спринт-планирование (доска Kanban или Scrum board)
• Оценка (story points) и velocidad команды
• История изменений с полным аудитом
• Интеграция с CI/CD (автоматическая закрытие при merge в главную ветку)

Примерная структура задачи

Заголовок: Как пользователь, я хочу экспортировать отчёт в PDF
Тип: Story
Приоритет: High
Оценка: 5 points
Описание:
  - Acceptance Criteria:
    [ ] Кнопка Export видна на странице Reports
    [ ] PDF содержит таблицу, диаграммы
    [ ] Файл скачивается с корректным именем
  - Технические замечания: использовать библиотеку ReportLab
  - Зависит от: TICKET-123 (API для экспорта)
Лейблы: backend, pdf, reporting
Ответственный: Ване Петрову

Google Docs / Confluence — для документации

Когда использую

• Требования высокого уровня (PRD — Product Requirements Document)
• Ссылки с Jira на полный контекст
• Спецификации API с примерами
• Квартальные планы развития продукта
• Постмортем после инцидентов

Преимущество: живой документ, который можно редактировать в реальном времени, обсуждать в комментариях.

Email / Slack

НЕПРАВИЛЬНО использовать как основной источник истины

• "Вот задача, которую я дал в Slack" — это потеряется через неделю
• Когда команда растёт, информация рассыпается

Правильно использовать для

• Срочных коммуникаций ("Сервер упал, вся команда в Slack")
• Обсуждения перед созданием задачи ("Что вы думаете про этот подход?")
• Напоминаний о Jira-задачах
• Информирования команды о закрытых/отклоненных задачах

Стикеры на доске (для физических команд)

Когда работаете в одном офисе

• Спринт-доска с колонками: To Do → In Progress → Review → Done
• Быстрое визуальное восприятие
• Моральный момент (видишь, что сделал)

Но это дублирование — информация все равно в Jira (как источник истины).

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

1. Одна истина

• Jira (или другой issue tracker) — центральное хранилище
• Все остальное — ссылки на него
• Никогда не обновляй только Slack, забыв про Jira

2. Детализация растёт ближе к выполнению

Первый вариант (Quarterly Plan, Google Doc):
- Q2: Улучшить performance приложения

После детализации (Jira Epic):
- Epic: Performance optimization
  - Story: Оптимизировать запрос к базе (N+1)
  - Story: Добавить кеширование Redis
  - Story: Сжать Bundle 40%

Перед спринтом (в Jira, с AC):
- Task: Identify N+1 queries with profiling tool
- Task: Refactor ProductService query
- Task: Add unit tests

3. Удобство доступа

• Для Product Manager: Jira, бэклог приоритизирован
• Для разработчика: Jira, доска спринта
• Для аналитика: Confluence (документы), Jira (текущие задачи)
• Для PM/CEO: обзорный dashboard (velocity, burndown)

Что я не рекомендую

• Excel/Google Sheets как основной tracker — нет версионирования, нет прав доступа
• Трелло для крупных проектов — слишком простой, нет гибкости
• Разговоры как план — "Помню, что-то говорил о бэклоге" — путь к хаосу

Вывод

Оптимальный stack:

• Jira — все задачи и их история
• Google Docs/Confluence — контекст, спецификации, планы
• Slack — быстрая коммуникация, с ссылками на Jira
• Доска спринта (физическая или Jira board) — ежедневное отслеживание

Это позволяет иметь полную картину, избегать потери информации и эффективно координировать работу команды.