В разработке ПО существует неразрешимое противоречие — это оценка сроков.  С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве. С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если  Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий. Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже. Короче, предсказание сроков — это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии — честно, результат будет такой же. Херня полная. Самый рабочий подход — это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.  Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10. Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать… ну а всё-таки, сколько дней-то займёт?" В итоге просто называешь какую-то магическую цифру и молишься Ктулху. Вишенка на торте — это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо. Метрика "успел/не успел" многим кажется хорошим фактором оценки работы программиста. Почему так? Потому что других вообще нет, и тут мы плавно переходим к следующему пункту Противоречие: бизнесу абсолютно необходимо оценивать качество и скорость работы программиста, но это абсолютно невозможно сделать объективно. Ни одной качественной метрики работы программиста не существует. Кто-то в древности пробовал оценивать количество написанных строк кода, но это совсем наивный подход.  Кто-то придумывает kpi для всей команды: скорость потраченных сторипоинтов за спринт, покрытие кода, количество вылезших багов на прод и тд. Но во-первых, это не оценивает конкретного программиста, а во-вторых, эти, казалось бы, конкретные цифры основываются на абсолютно эфемерных вещах. Сторипоинт — это само по себе что-то нечёткое, люди постоянно спорят, что это такое, и часто приходят к упрощениям (а-ля "день работы"), так еще и с помощью них пытаются магически угадать сроки, а это смотри пункт 1. И не надо мне говорить про усреднение понимания этой оценки за несколько спринтов: в разных спринтах порой совершенно разные задачи, а часто еще и разные люди над ними работают. Количество багов на проде зависит от покрытия тестами, от того, в какое легаси пришлось забраться в этот раз и т.д., т.е. нечеткий показатель. Покрытие тестами — плохой показатель. Вопрос холиварный. Моё мнение, что есть места, связанные с деньгами или ключевыми вещами бизнеса, где надо покрывать вообще всю логику, но если есть богом забытый раздел внутренней админки, который не особо важен и 99% не будет меняться в будущем — там тестов надо чуть-чуть, если они вообще нужны. Еще добавлю, любую метрику в цифрах при желании можно накрутить, причем обычно в ущерб системе, так как локальная оптимизация всегда вредит системе в целом. Ктулху Фхтагн! Есть такие вещи, как качество кода — абсолютно субъективный показатель, и тоже не везде в это качество надо упарываться, зависит от проекта и задачи. Тимлид зачастую знает, кто плох, кто хорош (оценка производится опять же субъективно с помощью нейросети между ушей), но как оценить самого тимлида? Вдруг его нейросеть плохая? Вдруг он прикрывает друганов? Нет никаких выводов.  Можно пытаться уменьшить разброс сроков, уменьшая скоуп задач и поручая задачи тем, кто такое раньше уже делал, но это не всегда возможно. Можно давать разработчикам некий процент от прибыли, чтобы у них была мотивация, и не оценивать вообще, но и это не всегда возможно. В общем, на мой взгляд эти противоречия абсолютно неразрешимы, но если вы вдруг знаете какой-то магический способ, напишите в комментариях, что я дурак и ничего не понимаю, я всё это аккуратно соберу и сделаю пост в своём телеграм канале, в котором изначально и родилась идея для этой статьи. Go-тимлид, веду канал https://t.me/crossjoin