Цена оценки

Перевод статьи Mathias Verraes «The Cost of Estimation»

tl;dr Спрашивать оценки времени может стоить вам больше, чем вы думаете. Когда вы делаете оценки, берите в расчёт время, сложность и риски.

Плюс-минус километр

(В оригинале «Ballpark Figures» — прим. перев).

Риски

Когда кто-нибудь просит вас оценить, сколько времени займёт фича или проект, вы будете оценивать минимально возможное время, в течение которого вы сможете завершить задачу. Подумайте об этом. Понаблюдайте за своими мыслями, пока оцениваете, и вы поймёте, что это правда. Даже если вопрос был задан с наилучшими намерениями, неявно полагается, что спрашивают не «как много времени это займёт, если делать правильно», а «как быстро вы сможете это сделать».

Если вы уже сыты по горло этим, то вы перемещаетесь в фазу 2: раздувание оценки. Вы делаете это втайне и чувствуете себя словно обманщик. По какой-то причине, это табу — оценивать время для правильного выполнение задачи, в отличие от того, чтобы оценивать время на быстрое выполнение.

В худшем случае это превращается в «поиск стрелочника» (blame culture — прим. перев). Кто-нибудь врывается в офис и требует от вас «какие-нибудь приблизительные оценки» (guesstimate or ballpark figure — прим. перев). Да, он всё ещё действительно ожидает, что вы закончите задачу в обозначенное время, при этом без каких-либо колебаний скидывая всё больше задач на ваши плечи. В конце концов, вас обвиняют в «расхождении с планом» или «совершении неверных оценок». Растёт недоверие внутри команды, равно как и отлынивание от работы. Возникают множество параллельных вселенных: реальность, планы менеджеров, а также и негласный договор, что план в любом случае провальный.

Тройные оценки

Некоторые люди пытаются хакнуть эту ситуацию, используя тройные оценки: комбинацию ожидаемой продолжительности, оптимистической продолжительности и пессимистической продолжительности. Я никогда не видел, чтобы это работало на практике. Управление программными проектами достаточно сложно само по себе, а использование всё время трёх чисел вместо одного не делает его проще. И эти числа обычно считаются (опять неявно) как ожидаемое время ± 20%, что вовсе не то же самое, что истинные оптимистичные и пессимистичные оценки.

Творческое решение проблемы

Всё это происходит везде. Это интуитивно, это — обычно, нормально. Многие люди спрашивают оценки, даже никогда не размышляя об этом. Оценивание воспринимается как эффективный способ контроля проектов. Мы измеряем время и деньги, поскольку время и деньги проще измерять. Мы даже дурачим себя верой в то, что время — это деньги, и что они могут быть легко переведены друг в друга.

Много раз ранее говорилось, но не будет лишним повторить: разработка ПО — это творческая профессия. Если вы проектируете ПО правильно, то вы решаете каждую задачу лишь однажды. Это значит, что каждая задача — это новая задача. Вы никогда не решали её раньше, так что вы в полном неведении относительно того, какое решение лучше и как много времени оно займёт.

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

Цена оценки

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

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

Другими словами, давление временем — это источник большей части нашего legacy-кода. Да, мальчик, у нас есть legacy-код в индустрии! Как следует из моего введения, оценки часто вызывают или подразумевают давление временем. Интересно, что будучи сделанными при неуправляемом техническом долге, они обладают привнесённой сложностью: модели, которые не соответствуют домену, непонятные пользовательские интерфейсы, недостаточное тестирование… Это, в свою очередь, затратно: сложные системы тяжелее изучить, тяжелее с ними работать, тяжелее менять. Когда бизнес зависит от ПО, которое тяжело менять, тогда становится тяжело менять сам бизнес. До того, как вы поймёте это, следующий стартап вырвется вперёд, быстрее, умнее, более гибкий, и он просто сотрёт вашу организацию с лица земли.

Почему оценки всегда неправильные

Риски

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

Почему так происходит? В разработке ПО решения высоко переиспользуются. Вы автоматически берёте это в расчёт, когда оцениваете время. «Мы уже делали что-то похожее, мы сможем использовать это». Но несмотря на то, что разработка первой части уже занимает больше времени, чем вы думали, в этот момент вы всё ещё предполагаете, что неудач не будет. Мы слепы к нашей собственной неспособности оценивать. Нам, кажется, никогда не научиться на собственных ошибках, поэтому нам будут набивать шишки вновь и вновь: от траты половины дня на поиск бага, вызванного забытой запятой где-нибудь, до потери половины месяца в ожидании, что клиент предоставит какую-нибудь критическую часть информации, про которую он сказал «будет в вашем ящике к концу дня». Как будто у них есть какие-то секретные знания и умения для правильной оценки времени!

Чтобы сделать неявное явным, давайте назовём это «риски»: вероятность, с которой основанная на времени оценка может быть неверной.

Лучшие оценки

К чему мы пришли в итоге. Есть лучший метод для оценивания, если сделать все ингредиенты очень явными. Формула для оценивания в стори-поинтах выглядит так:

стори-поинты = время × сложность × риски

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

comments powered by Disqus
Система Orphus