Неразрешимые проблемы разработки

Сроки

В разработке ПО существует неразрешимое противоречие — это оценка сроков.

С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.

С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если

• новая функциональность нетипична
• есть зависимости на другие команды
• будет задействована новая технология
• ТЗ надо сильно уточнять
• надо разобраться в логике легаси-кода

Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.

Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже.

Короче, предсказание сроков — это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой ^[1], которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии — честно, результат будет такой же. Херня полная.

Самый рабочий подход — это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.

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

Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать… ну а всё-таки, сколько дней-то займёт?"

В итоге просто называешь какую-то магическую цифру и молишься Ктулху.

Вишенка на торте — это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо.

Метрика "успел/не успел" многим кажется хорошим фактором оценки работы программиста. Почему так? Потому что других вообще нет, и тут мы плавно переходим к следующему пункту

Оценка работы программиста

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

Ни одной качественной метрики работы программиста не существует. Кто-то в древности пробовал оценивать количество написанных строк кода, но это совсем наивный подход.

Кто-то придумывает kpi для всей команды: скорость потраченных сторипоинтов за спринт, покрытие кода, количество вылезших багов на прод и тд. Но во-первых, это не оценивает конкретного программиста, а во-вторых, эти, казалось бы, конкретные цифры основываются на абсолютно эфемерных вещах.

Сторипоинт — это само по себе что-то нечёткое, люди постоянно спорят, что это такое, и часто приходят к упрощениям (а-ля "день работы"), так еще и с помощью них пытаются магически угадать сроки, а это смотри пункт 1. И не надо мне говорить про усреднение понимания этой оценки за несколько спринтов: в разных спринтах порой совершенно разные задачи, а часто еще и разные люди над ними работают.

Количество багов на проде зависит от покрытия тестами, от того, в какое легаси пришлось забраться в этот раз и т.д., т.е. нечеткий показатель.

Покрытие тестами — плохой показатель. Вопрос холиварный. Моё мнение, что есть места, связанные с деньгами или ключевыми вещами бизнеса, где надо покрывать вообще всю логику, но если есть богом забытый раздел внутренней админки, который не особо важен и 99% не будет меняться в будущем — там тестов надо чуть-чуть, если они вообще нужны.

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

Ктулху Фхтагн!

Есть такие вещи, как качество кода — абсолютно субъективный показатель, и тоже не везде в это качество надо упарываться, зависит от проекта и задачи.

Тимлид зачастую знает, кто плох, кто хорош (оценка производится опять же субъективно с помощью нейросети между ушей), но как оценить самого тимлида? Вдруг его нейросеть плохая? Вдруг он прикрывает друганов?

Выводы

Нет никаких выводов.

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

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

В общем, на мой взгляд эти противоречия абсолютно неразрешимы, но если вы вдруг знаете какой-то магический способ, напишите в комментариях, что я дурак и ничего не понимаю, я всё это аккуратно соберу и сделаю пост в своём телеграм канале ^[2], в котором изначально и родилась идея для этой статьи.