С какой детализацией ожидал постановку задач

# С какой детализацией ожидал постановку задач

Я считаю, что качество постановки задачи напрямую влияет на скорость разработки и количество ошибок. Мне удобнее работать с определенным уровнем детализации требований.

Оптимальный уровень детализации

Мне нужна информация, которая помогает уловить контекст задачи, но не замораживает развитие мышления:

1. Бизнес контекст (ОБЯЗАТЕЛЬНО)

✅ Хорошо:
"Нужно реализовать фильтрацию заказов по статусу,
потому что клиенты часто ищут отмененные заказы
для проверки причины отмены. Это уменьшит количество
тикетов в support на 15% по текущей оценке."

❌ Плохо:
"Нужно реализовать фильтрацию заказов по статусу."

2. Требования и constraints

✅ Хорошо:
"Фильтр должен работать при выборе из 50000+ заказов
за последний год. Ожидаемое время ответа < 500ms.
Тестирование: staging среда с production copy.
Приоритет: MEDIUM, deadline 2 спринта."

❌ Плохо:
"Надо быстро."

3. Критерии принятия (Definition of Done)

✅ Хорошо:
DOD:
1. Фильтр работает на всех поддерживаемых браузерах
2. Состояние фильтра сохраняется в URL (для шаринга)
3. Есть unit тесты с coverage > 80%
4. Есть E2E тест с основными сценариями
5. Code review пройден
6. Performance: <500ms на production data
7. Mobile: адаптация работает на экранах 320px+

❌ Плохо:
"Сделай и чтобы работало."

4. Граница scope (что НЕ входит)

✅ Хорошо:
Входит:
- Фильтрация по одному статусу
- Сохранение выбора в URL

НЕ входит (future scope):
- Фильтрация по нескольким статусам одновременно
- Сохранение prefetch в localStorage
- API для фильтрации через GraphQL

❌ Плохо:
Без описания границ → разработчик гадает

Уровни детализации для разных типов задач

Задачи с четкой спецификацией (70% задач)

Этот уровень детализации подходит:

ТЛДР: Добавить endpoint для получения истории платежей

API:
GET /api/v1/users/{userId}/payments/history
Query params:
  - limit: int (default 20, max 100)
  - offset: int (default 0)
  - status: enum (PENDING, COMPLETED, FAILED)

Response:
{
  "items": [
    {
      "id": "uuid",
      "timestamp": "2024-03-22T10:30:00Z",
      "amount": 99.99,
      "status": "COMPLETED",
      "method": "CREDIT_CARD"
    }
  ],
  "total": 150,
  "hasMore": true
}

Ошибки:
- 400: Invalid status
- 401: Unauthorized
- 404: User not found
- 500: Internal error

Примечания:
- Данные отсортированы по timestamp desc
- Пользователь может видеть только свои платежи
- Кеш: Redis 5 минут

Testing:
- Unit test на валидацию параметров
- E2E test с 3+ платежами в истории
- Performance: <300ms на 10000 платежей

Исследовательские задачи (10% задач)

Здесь нужна более гибкая постановка:

ТЛДР: Исследовать возможность кэширования сессий в Redis

Что надо сделать:
1. Оценить текущую архитектуру session storage
2. Найти bottleneck (если есть)
3. Предложить решение с Redis
4. Оценить effort (сколько времени займет)
5. Дать рекомендацию (делать или не делать)

Делайте как посчитаете нужным, главное итоговый вывод
и рекомендация.

Дедлайн: 1 спринт
Результат: документ с выводами

Refactoring задачи (20% задач)

Здесь нужна система метрик:

ТЛДР: Рефакторить UserService для лучшей maintainability

Текущие проблемы (по PR feedback):
- Класс 400 строк (слишком большой)
- 8 зависимостей через constructor (слишком много)
- Нет документации на public методы
- 3 метода делают 2+ вещи (смешивают ответственность)

Цель:
- Разбить на 2-3 smaller classes
- Каждый класс < 200 строк
- Добавить Javadoc на public методы
- SRP: каждый класс одну ответственность
- Не ломать существующий API

Критерии принятия:
- Все старые тесты проходят
- Новые тесты для выделенных классов
- Code review approved
- Performance НЕ ухудшена

Информация, которую я ценю в постановке

Примеры данных

// ✅ Полезно: конкретные примеры

"Input:
  - User с 10000 orders
  - Filter: status = COMPLETED
  
Expected output:
  - Возвращаются только COMPLETED orders
  - В порядке desc по created_at
  - Время ответа < 500ms
  
Counter example:
  - Если filter не указан → возвращаются ВСЕ orders
  - Это может быть 50000 orders, поэтому нужна пагинация"

Links к релевантным документам

✅ Полезно:
- Ссылка на текущую архитектуру docs
- Ссылка на похожую реализацию (если есть)
- Ссылка на upstream issue (если это fix для бага)
- Ссылка на какие-то стандарты компании

Зависимости от других задач

✅ Полезно:
"Зависит от #321 (миграция на Spring Boot 3)
Блокирует #567 (добавление GraphQL API)
Релировано с #789 (рефакторинг UserService)"

Инструменты для постановки

Структурированный шаблон

## Проблема
[Что не так в текущем состоянии]

## Решение
[Как это должно работать]

## Детали реализации
[Технические подробности если нужны]

## Критерии принятия
1. [Критерий 1]
2. [Критерий 2]
3. [Критерий 3]

## Зависимости
[Что нужно сделать перед этим]

## Ресурсы
[Ссылки на документацию]

## Оценка effort
[Примерное время S/M/L/XL]

## Deadline
[Когда нужно к какому спринту]

Мой идеальный workflow

Пн: Product owner постановка задачи (30 мин встреча)
  ↓
Вт: Я читаю задачу, задаю уточняющие вопросы через Slack
  ↓
Ср: Получаю ответы, уточняю детали
  ↓
Чт: Начинаю разработку (уже знаю все детали)
  ↓
Пт: Code review + готов к merge
  ↓
Сл. пн: Деплой в production

Минусы недостатка информации

❌ Недостаточная детализация ведет к:
1. Переделкам (40% времени тратится впустую)
2. Коммуникационным gaps ("я думал что...", "я имел в виду...")
3. Unexpected scope creep
4. Low morale (непонятно что ты вообще делаешь)
5. Ошибкам в реализации

✅ Хорошая постановка → 
1. Фокус (знаешь точно что делать)
2. Скорость (нет переделок)
3. Качество (учтены edge cases)
4. Удовлетворение (видишь результат)

Итог

Мне нужна "Goldilocks zone" детализации:

• Достаточно информации чтобы понять контекст и цель
• Достаточно constraints чтобы ограничить scope
• Достаточно примеров чтобы уловить edge cases
• Но не настолько детально чтобы блокировать креативность

Лучшая постановка — это когда я могу сказать "я вижу картину" и сразу начать работать.