TGViewer
Плохой менеджер Артём Арюткин Плохой менеджер Артём Арюткин @badtechproject · 14.3K subscribers
Post #1806 4.32K
Классические модели оценки Storypoints, Functionpoints не работают!

А что если я вам скажу, что Storypoints, Functionpoints имеют мало общего со сложностью задач?
И мысль тут не моя, а ребят из Stanford - Егора Денисова-Бланш и его коллег.

Но как так получилось?
Они разработали модель, натренировали ее на 100+ тыс.репозиториях и 10 экспертах в разработке, а затем проверили и убедились, что лучшая метрика - это сколько инженерного усилия и сложности было в фактических коммитах!

Обычно, вот эта задача оценки сложности хм…сложная!
Но статья ребят раскрывает то, как это посчитать.

Фактически, метрика комплексная и состоит из следующих:
1.
Сколько времени (в часах) в этом коммите “закодировано”
2.
Насколько трудной была задача, судя по коду и контексту
3.
Какие объективные признаки сложности есть внутри изменений (кохезия, сложность, coupling, архитектурные изменения, объём и тип модификаций)

И как менеджер вы скажите мне:
«Да нафига мне оценки сложности уже после написания когда?»


И тут я сижу «сижу на двух стульях» вместе с вами и ребятами, кто готовил статью:
1.
Как менеджер, я хочу знать оценку до старта.
Но оценка до старта - это гипотеза. Фактически, это шум!
2.
Но как эксперт я понимаю, что люди отваритетельно оценивают задачи и планируют.

Авторы прямо пишут, что их результаты «подсвечивают ограничения традиционных forward‑looking методов» и что backward‑оценка по коду даёт более точную меру усилия.

Как можно это применить на практике:
1.
Код ревью важная задача в нашей индустрии и модель из статьи может позволить вам распределять более сложные задачи на ревью на более «экспертных ребят».
2.
Такая модель может позволить объяснить стоимость реализации отдельных фич и задержку сроков.
3.
Если научиться надёжно оценивать усилие и сложность по коду, можно затем искать связи между «постфактум» метриками и ранними артефактами (типы требований, области системы и т.п.). То есть модель даёт основу для более качественной калибровки планирования (сравнивать фактический effort по коду с изначальными оценками), но не описывает модель, которая сразу из описания задачи выдаёт оценку сложности/усилия.

А разве умение учиться на основе прошлого не ключевой навык менеджера?

«Storypoints - это гипотеза.
Код - это факт.
Без измерения факта гипотеза никогда не станет лучше.»


А вы верите в умение людей оценивать сроки?

🔥 - да, люди умеют оценивать сроки с достаточной точностью
🦄 - ох о чем вы, сроки мы особо оценивать не умеем
😎 - оцениваю сроки с точностью до минуты
  • 🦄 64
  • 🔥 19
  • ❤ 4
  • 😎 4
  • 👍 2
  • 🤩 2
  • 🤔 1
More from @badtechproject
  1. Sep 23, 2026Сервис, который держится на конкретных людях, это не сервис 😁 Это ручное управление. Коро…
  2. Sep 23, 2026Как правильно уходить в отпуск и возвращаться из него, чтобы прямо по кайфу (Часть 2) Вот…
  3. Sep 22, 2026Ааааааа
  4. Sep 21, 2026Купили всем AI. Теперь быстрее ждём согласования Короче, McKinsey выпустили статью про «на…
  5. Sep 21, 2026Вы уверены наверняка, что будет с инфраструктурой, если завтра трафик вырастет в 5 раз? Се…
  6. Sep 21, 2026Как изучать искусство, если ты в нем нифига не понимаешь Короче, сходили с Наташкой на выс…
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 →