Страх и ненависть в эстимейтах

 

Содержание:

1. философская часть, постановка вопроса, почему эстимейты это зло, от которого нам надо уходить;
2. основные методики работы с оценкой времени (спойлер, их всего 2);
3. советы от меня и бывалых.

Как дать адекватную оценку времени, когда неопределённость бьёт по башке

Большинство людей не умеют адекватно оценивать сроки выполнения задач. 

Самый ненавистный вопрос

«На какой вопрос вы больше всего не любите отвечать?». 

 «Когда будет готово?!». 

наверняка человек начнет рассказывать о своих проблемах.

Понимаете? На вопрос «Когда?» — отвечают рассказом о проблемах! Так делает почти всё человечество.

Еще пример — для тех, кто помнит университетский курс программирования. Какой тип данных должна вернуть программа на запрос «Когда?». DataTime или что-то типа того. Человек же на это стабильно выбрасывает Exception. 

Почему люди так сильно не любят оценивать сроки? Ведь всё просто:

Неопределенность бьёт по башке

Корневая причина в том, что, оценивая объем работ, мы сталкиваемся с неопределенностью.

Мы вынуждены предсказывать будущее — строить прогноз и нести за него ответственность. 

Но прогнозы нужны нам как опора. Как попытка отгородиться от неопределенности. 

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

Вернёмся к формуле. Она, в принципе, верная.

Пакость в том, что ни числитель, ни знаменатель этой дроби не известны. Хотя бы потому, что:

• Подпись заказчика (кровью) под техническим заданием не гарантирует, что документ описывает именно тот объем работ, который реально нужен. Она даже не гарантирует, что заказчик читал ТЗ. Реальный объем работ вы узнаете только после приёмки проекта.
• Любая постановка задачи гарантированно содержит «дырки», которые можно трактовать двояко. Чем толще постановка — тем больше таких мест.
• Производительность людей (особенно программистов) может отличаться в РАЗЫ и зависит от столь большого числа факторов, что учесть влияние всех просто невозможно.

Все известные  математические модели, пытающиеся ответить на вопрос «ДОКОЛЕ?», построены на серьезных упрощениях. Применять их на практике можно только для демонстрации несостоятельности этих моделей и тщетности бытия, но мы попробуем...

Принципы адекватой оценки

Есть всего ДВА способа делать оценки:

1. опираясь на свою картину мира в прошлом (свой опыт и исторические данные);
2. продлевая свою картину мира в будущее (экспертные оценки и интуиция).

Работа заполняет время, отпущенное на неё

Всё, что может пойти не так, пойдёт не так

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

Задача руководителя — приучить оценивать свою работу. Не просто давать задачу и смотреть, как человек с криками «Бляха-муха!» бежит ее делать. А убедиться, что нужный объем работ проанализирован.

Опора на прошлое

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

Опора на прошлое имеет ряд недостатков, которые влияют на точность оценки.

1. Человек, делающий повторно одну и ту же (или очень похожую) операцию, начинает делать её быстрее. С мастерством растет скорость. Поэтому нельзя сказать, что одна и та же задача у одного и того же человека займет одинаковое время.
   
   
   для нас характерно творческое отношение ко всему. В том числе к регламентам и правилам. Иногда это хорошо, но сильно вредит на конвейерном производстве.
   
   
   Творческое отношение приводит к тому, что в какой-то момент делать однотипные вещи становится скучно. И, если мы вынуждены ими заниматься, пробуем делать их другим способом. А это значит, что качество работ и время, на них затраченное, изменятся. Возрастёт опасность ошибок и провала по срокам.
   
   
   Нет ничего страшного, если это контролируемо: мы понимаем, что задача носит экспериментальный характер и закладываем время на эксперимент (а не внезапно узнаем, что вместо четкой и отлаженной работы сотрудник чисто-по-приколу начал экспериментировать и упоролся).
   
   
2. Мы склонны забывать детали, нюансы и мелочи тех операций, которые выполняем редко. А это значит, что наши оценки, основанные только на прошлом опыте выполнения задачи, практически всегда будут слишком оптимистичными.
   
   
3. В противовес забывчивости в мелочах мы хорошо помним, если ранее больно получили за превышение сроков на похожей задаче. И, если у нас не кружок садомазо, повторений не хотим. И начинаем перестраховываться.
   
   
   Наша подстраховка будет основана только на страхе и нежелании испытать негативные последствия. Пускай даже они заключались в том, что мы не уложились в свои же оценки, и нас за это даже не ругали. На страхе, но никак не на здравом смысле.

Экспериментируем, забываем, боимся. Поэтому грамотному руководителю важно оговаривать не только оценку сроков, но и способ, которым будет получен результат — иначе его ждут сюрпризы. Все, что может быть рационально автоматизированно и стандартизированно — должно быть автоматизированно и стандартизированно. А задачи, предполагающие эксперименты с новыми технологиями или способами работы, должны быть отдельно оговорены как экспериментальные (с отдельным резервом бюджета и сроков).

Продление картины мира в будущее

Итак, одного опыта для оценки недостаточно. Два других способа — экспертные оценки и интуиция.

Лучшее, что мы должны проделать — представить, как именно мы будем реализовывать задачу. Чем детальнее представим, тем точнее будут прогнозы. Тут важно говорить правду самому себе: если в мысленном эксперименте по ходу работы появились технологические нестыковки — они гарантированно выльются в дополнительное время.

Картина мира может быть неадекватной — тогда в процессе работы мы сталкиваемся с неожиданностями. Там, где мы не хотим разбираться в мелочах и вникать в детали, мы хотим просто закинуть много подстраховки. У программистов есть формула «Оцени, а затем умножь либо на π (3,14...), либо на e (2,71...). Немаленькие множители, да и разброс большой. Но в итоге факапим даже с ними. Всё дело в невнимательности к мелочам, лени разбираться или отсутствии адекватных ресурсов на изучение нюансов.

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

1. Постановка задачи, анализ и предварительная оценка (оценивается срок получения сроков).
2. Фаза ресерча.
3. Уточненная оценка, начало работы, фиксация оценки (именно после ресерча и небольшого куска реальной работы).
4. Выполнение задания. Дальнейшее изменение оценки возможно только как форс-мажор или косяк, и должно происходить по принципу «уперся — сообщи». В длительных задачах — согласованные контрольные точки.

Чем мы внимательнее к мелочам — тем точнее наши прогнозы. 

Секретные методики мира IT

Абсолютные и относительные оценки

Человеку сложно оценивать абсолютные величины. А вот с относительным проблем меньше.

Какой размер у Юпитера? Руками не показать, словами не описать — цифры слишком большие для понимания маленьким земным мозгом.

А теперь скажите, какой размер у Юпитера по сравнению с Землёй, используя аналогии. Здесь уже проще: Земля размером с горошину, а Юпитер — с арбуз. Земля носит маечку размера S, а Юпитер — XXXL.

Мозг лучше воспринимает относительные величины — используйте это в оценке задач. Одну большую разбейте на десяток поменьше и дайте оценку каждой в отдельности. Сравнивайте подзадачи между собой: какая носит футболку XS, а какая L? Футболки даже не обязательно переводить в часы — вы уже поймёте примерный объём работ.

1. Индивидуальные эстимейты не могут переходить к другим членам команды без изменений

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

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

2. Не забывайте о времени, которое уходит на коммуникации

В своем бестселлере Manage the Unmanageable об управлении командой разработчиков авторы Микки Мантл (Mickey W. Mantle) и Рон Лишти (Ron Lichty) утверждают, что в среднем у девелоперов уходит на кодинг только около 55% времени, тогда как остальные 45% они тратят на взаимодействие и общение с коллегами, менеджерами, тестерами, дизайнерами, представителями клиента и т.д. Кроме того, эксперты пишут, что только одна шестая от общего времени работы над проектом приходится непосредственно на написание кода. Половина времени, а то и больше, уходит на тестирование и исправление ошибок. 

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

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

3. Оценивайте разные виды работы над проектом отдельно

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

4. Своевременно корректируйте ошибки в эстимейтах

“Обновлять и корректировать первоначальную оценку после того, как проект запущен и находится в процессе реализации, совершенно нормально. Чем больше информации предоставляет клиент, тем лучше вы понимаете, сколько человеко-часов потребуется на его реализацию. И чем быстрее вы поймете, что план нужно скорректировать, и сделаете это — тем лучше. Не стесняйтесь обсуждать этот вопрос с клиентом, даже если требуется перенести дедлайн или добавить в команду новых специалистов,” — советует Серхио Акоста (Sergio Acosta), опытный разработчик мультиплатформенных приложений. 

“Конечно, прежде всего за всем этим должен следить проджект менеджер или тимлид, но в реальности им часто не обойтись без участия рядовых разработчиков. Особенно в тех случаях, когда проджект менеджер/тимлид занимается несколькими проектами одновременно или слишком занят, чтобы следить за деталями реализации той или иной составной части проекта,” — добавил Акоста.