Как получаешь оценку задачи от исполнителей?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Процесс получения оценки задачи от исполнителей
Оценка (estimation) задач—это один из самых неточных, но критических процессов в разработке. Расскажу как я это организую и как получаю реальные, а не оптимистичные оценки.
Фаза 0: Подготовка задачи (ДО оценки)
Много PM делают ошибку: дают размытую задачу и просят оценить. Результат: оценка может быть в 2-3 раза неправильной.
0.1 Четкие требования
Перед тем как спрашивать оценку, я убеждаюсь:
- Acceptance Criteria четко описаны (что считается "готово")
- Happy path ясен (что должно происходить в обычном случае)
- Edge cases перечислены (что если юзер введет невалидные данные)
- API контракт определен (какие параметры, какой response)
- Дизайн готов (нет вопросов "как это должно выглядеть")
Пример плохой задачи:
"Добавить авторизацию через Google"
Техническую не ясно:
- Какие данные юзера нужно сохранять?
- Какую информацию запрашивать у Google?
- Что делать если email уже зарегистрирован?
- Нужна ли проверка домена?
Пример хорошей задачи:
"Добавить авторизацию через Google OAuth"
Acceptance Criteria:
1. Пользователь видит кнопку "Sign in with Google" на странице входа
2. При клике открывается Google Auth Flow
3. После авторизации:
- Если это новый пользователь → создаём аккаунт с email из Google
- Если пользователь существует → логиним в его аккаунт
4. После авторизации редирект на Dashboard
5. Токен сохраняется в secure cookies
Edge cases:
1. Пользователь отклонил Google Auth → показываем ошибку
2. Email уже используется другим аккаунтом → показываем ошибку
3. Session expired → редирект на Login
API:
- POST /auth/google (code) → returns JWT token
0.2 Встреча на уточнение (Refinement)
Да, я не просто выкладываю задачу. Я встречаюсь с tech lead / разработчиком:
- "Видишь ли ты какие-то проблемы с требованиями?"
- "Есть ли технические риски?"
- "Какие зависимости будут нужны?"
- "Нужна ли помощь с дизайном?"
Это занимает 10-15 минут, но часто выявляет проблемы ДО оценки.
Фаза 1: Процесс оценки (Story Points)
Я использую relative estimation (относительная оценка), не абсолютную (часы).
1.1 Калибровка (Baseline)
Все оценки должны быть относительно одной задачи. Я выбираю базовую:
"2 points" = "Типичная простая фишка, которую Middle разработчик делает за день-полтора"
Примеры:
- Изменить текст кнопки
- Добавить поле в форму (backend + frontend)
- Исправить баг в UI
Относительно неё:
- 1 point: очень простая (30 минут)
- 2 points: простая (0.5-1 день)
- 3 points: средняя (1-1.5 дня)
- 5 points: сложная (2-3 дня)
- 8 points: очень сложная (4-5 дней)
- 13 points: эпический (неделю+)
Если задача > 8 points → я разбиваю на подзадачи.
1.2 Планинг покер (Planning Poker)
Я использую asynchronous версию (потому что team разброс по часовым поясам).
Процесс:
- Выкладываю задачу в Jira
- Пишу комментарий: "@dev_team please estimate by EOD"
- Каждый разработчик независимо дает оценку (не видя других)
- Если все согласны (например, все сказали 3) → готово
- Если разброс (один 3, один 5, один 8) → обсуждаем
Обсуждение разброса:
- Кто выбрал 8 points? Какие риски видишь?
- Кто выбрал 3 points? Почему считаешь это просто?
- Какие assumptions у вас разные?
Обычно оказывается, что кто-то не заметил какое-то требование.
1.3 Правило 50% расхождения
Если две оценки отличаются больше чем на 50%, я спрашиваю почему:
- 3 vs 5 points (60% разница) → обсуждаем
- 3 vs 4 points (30% разница) → можно взять 3 или 4 (на усмотрение)
1.4 Кто оценивает?
Оценивает тот, кто будет делать:
- Если это backend задача → Backend developer оценивает
- Если frontend → Frontend developer
- Если full-stack → обсуждают вместе
Старший разработчик может переоценить (завышить в сложности), а Junior может недооценить.
Мой трюк: смотрю на историю.
- Если Junior обычно недооценивает, я добавляю 30% к его оценке
- Если Senior слегка завышает, я вычитаю 10%
Фаза 2: Уточнение и итерация
2.1 "Слишком высокая оценка"
Разработчик: "Это 13 points, минимум неделя" Я: "Оу, это много. Давайте разберемся."
Обычно есть 3 варианта:
- Я неправильно описал → переписываю
- Есть скрытый риск / зависимость → обсуждаем, может быть исключаем
- Задача действительно большая → разбиваю на подзадачи
Пример:
Я: "Добавить экспорт отчета в Excel (13 points это очень много)"
Dev: "Нам нужно интегрировать library для Excel, сделать правильное форматирование, обработать ошибки"
Я: "Окей, видится ли путь чтобы сделать MVP проще?"
Dev: "Да, сначала just CSV (3 points), потом Excel (5 points)"
Я: "Отлично, давайте сначала CSV"
2.2 "Слишком низкая оценка"
Разработчик: "Это 2 points, очень просто" Я: "Хм, а я вижу 5 edge cases в requirements. Ты их видел?"
Обычно Junior просто не заметил requirements.
2.3 История оценок
Накопление истории оценок помогает калибровке:
Задача Оценка Реальное время Точность
─────────────────────────────────────────────────
Login 3 points 2.5 дня ✓ (точно)
API auth 5 points 5.5 дней ✓ (точно)
Cache 8 points 12 дней ✗ (занижено)
DB migrate 13 points 8 дней ✓ (правильно)
EmailQueue 5 points 7 дней ✗ (занижено)
Я смотрю: если Cache и EmailQueue часто получают +40% к оценкам, значит мы недооцениваем асинхронные задачи.
Фаза 3: Факторы, влияющие на оценку
Когда я смотрю на оценку, я учитываю контекст:
3.1 Тип разработчика
- Senior: может переоценить ("5 points" потому что юнит-тесты, документация)
- Middle: обычно точен
- Junior: часто недооценивает (не видит подводных камней)
3.2 Фреш тема
Если разработчик первый раз работает с технологией:
- +1-2 points на learning curve
Пример: "Интеграция с Stripe (новая для нас)" Без опыта: 8 points C опытом: 5 points → Нужна оценка для first-time: 8 points
3.3 Спешка
Если дедлайн завтра и нужно срочно—оценка выше (из-за спешки, ошибок, переделок).
3.4 Технический долг
Если код старый и грязный, оценка выше.
Фаза 4: Мой чек-лист перед принятием оценки
[ ] Задача имеет четкие Acceptance Criteria?
[ ] Дизайн готов или не нужен?
[ ] Все зависимости известны?
[ ] Разработчик понимает requirements?
[ ] Оценка обоснована?
[ ] Есть ли скрытые риски?
[ ] Оценка соответствует истории (аналогичные задачи)?
[ ] Есть ли элемент спешки, который завышает оценку?
[ ] Согласны ли все заинтересованные разработчики?
Если что-то не ясно → отправляю обратно на уточнение.
Типичные ошибки PM
Ошибка 1: "Это должно быть 3 points, не 5"
Это не моя роль. Разработчик лучше знает сложность.
Если я не согласен:
- Спрашиваю почему, а не спорю
- Может быть, я недооценил сложность
Ошибка 2: Оценка без требований
"Сделай estimate для авторизации"
Это невозможно. Нужны детали.
Ошибка 3: Использование оценок для давления
"Ты сказал 5 points, а сейчас говоришь что 8. Почему лжешь?"
Оценка—не обещание, это guess. Когда разработчик начинает работать, может оказаться сложнее.
Мой идеальный процесс (суммарный)
1. PM пишет задачу с четкими требованиями (30 мин)
2. PM встречается с dev на 10-15 минут (refinement)
3. Dev независимо оценивают в Jira/Slack (15 мин)
4. Если разброс > 50%, обсуждаем (10 мин)
5. Принимаем финальную оценку
6. После завершения: фиксируем реальное время
7. Каждый квартал анализируем accuracy
Времени затрачено на оценку: 1.5-2 часа работы (включая dev time) Полезность: точное планирование спринтов, реальные сроки для бизнеса.
Один важный факт
По исследованиям, даже идеальная система оценок точна только на ±25%.
Поэтому я:
- Не обещаю очень точные сроки
- Всегда даю range ("5-7 дней, скорее всего 6")
- Буферизирую при планировании (добавляю 15% к velocity)
- Фокусируюсь на trend, не на point-точности
Оценка—это не наука, это искусство + опыт.