TGViewer
Инженер и Менеджер Инженер и Менеджер @engineering_manager · 1.86K subscribers
Post #92 1.99K
Как сделать так, чтобы разработчики не завышали оценку задач?

⬅️ Совершите shift left
Прямо сейчас у нас в Циане я активнее сдвигаю разработку "влево" — то есть поближе в discovery. Это и есть shift left.

Так разработчики лучше понимают фичу, зачем мы ее пилим и как ее реализовать потом в коде сервиса. Задают вопросы по ходу discovery, следят за развитием мысли продакта и так далее.

Если же ваши разработчики получают требования откуда-то из черного ящика и в discovery не вовлекаются, они по-любому будут пытаться перестраховаться. Вы ведь просите их оценить что-то, что они видят в первый или второй раз в жизни.

⏳ Создайте буфер
Чтобы люди меньше пытались перестраховаться, заложите буфер на опоздания в конце квартала. Например, когда я планировал проекты, я всегда делал дату релиза ровно за один спринт до дедлайна. Таким образом, у нас всегда оставался спринт на то, чтобы порешать какие-то зависшие проблемы или нагнать отставание.

При этом в остальных, рабочих спринтах, я исключал перестраховку. Перестраховка уже заложена в конце квартала, нечего туда лезть внутри спринта.

🥊 Челленджите оценки
Это самый тяжелый, но в то же время самый простой способ. Легкий он потому что требует лишь одного вопроса, "а чо так долго?". Тяжелый — потому что его бывает непросто задавать.

Стесняться челленджить оценку — это критически плохо, потому что если оценка излишне высокая, вы просто потратите лишнее время зря. А могли бы потратить на другую задачу, на которую времени в итоге у вас может не хватить.

Но мне спрашивать было легко. Я — менеджер "от станка" и лет десять писал код каждый день. Поэтому когда я стал тимлидом, практически на любую оценку задачи я мог ответить, что сделал бы задачу в полтора-два раза быстрее.

Это — другая крайность, не делайте так. Потому что очень уж высок риск услышать в ответ на ваше "да я эту задачу за пару дней бы сделал" ответ "ну вот бери и делай тогда".

‼️ Выводы
- Совершите shift left — погрузитесь в продукт и фичи
- Создайте буфер — единый для всего проекта, а не несколько маленьких для каждой задачи
- Челленджите оценки — не стесняйтесь, но и борщить тут нельзя

Есть еще способы, но эти три — самые действенные для меня. А какие вы используете в своей работе?
  • 👍 17
  • 🥰 6
  • 👎 5
  • 🔥 2
  • ❤ 1
  • 💯 1
More from @engineering_manager
  1. Sep 15, 2026Жаль, что продакт менеджмент существует. Цитата CPO Whatnot'а — сравнительно нового сервис…
  2. Sep 14, 2026Ожидание: у нас CI/CD, push on green, канарейки и авторолбэки Реальность:
  3. Sep 14, 2026Даже лучшие инженеры порой дают опасные советы. Представьте инженера, чьим советам по коду…
  4. Sep 10, 2026Обнаружена первая (и, вероятно, единственная) причина покупки нового айфона.
  5. Sep 9, 2026Николай Петрович прислал замечания к документу в девять утра, а в десять уже чувствовал се…
  6. Sep 7, 2026Uber увольняет 3300 человек — 10% штата. И нет, подождите, в этот раз причина не «ИИ нас в…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →