Если ты когда-нибудь писал код, ты знаешь:
🔸 переменные нужно называть точно
🔸 если переименуешь не тот файл — всё сломается
🔸 дашь функции странное имя — команда тебя проклянёт

Разработчики учатся быть предельно аккуратными с языком.
Каждое слово — с прицелом на ясность, логику, последствия.

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

😶 Пример — “story point velocity”.

✖️ Это не скорость
Story points — не километры, не часы и не джоули.
Они субъективны, относительны, и означают разное в разных командах.

✖️ Это не про ценность
Команда может закрыть 40SP за спринт, и не сдвинуть продукт ни на миллиметр.
А может сделать одну задачу на 3SP и клиент останется в восторге.

✖️ Это не инструмент ТОЧНОГО планирования
Каждый спринт уникален: кто-то ушёл в отпуск, кто-то перегорел, кто-то просто внезапно понял, что жить надо иначе.
Думать, что прошлое velocity даст точный прогноз — магическое мышление.

✖️ И уж точно это не метрика, чтобы сравнивать команды между собой или оценивать их зрелость.
Тут вступает в игру закон непреднамеренных последствий:
стоит начать сравнивать — и команды начинают играть. Делить задачи мельче. Раздувать оценки. Прятать работу.
В любом случае, реальность страдает.

❕Story Points — полезный инструмент.
Но только как внутренний язык команды, чтобы прикинуть сложность и использовать как ориентир.
А не как контракт, KPI или средство давления.

💡Что делать вместо этого?
☑️ Считать throughput: сколько историй реально завершено
☑️ Смотреть на cycle time: сколько заняла работа от начала до конца
☑️ Ввести value points и говорить про ценность, а не только сложность

А может, вообще отпустить идею «мерить эффективность» одной цифрой.
И начать говорить о том, что действительно важно: ценность, частота поставки, прозрачность, предсказуемость.