- PVSM.RU - https://www.pvsm.ru -
Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.
В этой статье собраны и структурированы принципы и методы, с помощью которых можно научить себя и других давать адекватные оценки. В начале — общие принципы и чуть-чуть математики. В конце — конкретика для студий.
Выступая на десятках конференций, я часто спрашивал людей в зале: «На какой вопрос вы больше всего не любите отвечать?». И всегда ответом было: «Когда будет готово?!». Вопрос волнует и вызывает эмоции. Вот прямо сейчас подойдите к вашему коллеге и спросите его, когда будет готово. Знаете, что вы скорее всего услышите?
Нет, не обязательно вам укажут направление и пожелают доброй дороги. Все же кругом много культурных людей. Зато почти наверняка человек начнет рассказывать о своих проблемах.
Понимаете? На вопрос «Когда?» — отвечают рассказом о проблемах! Так делает почти всё человечество.
Еще пример — для тех, кто помнит университетский курс программирования. Какой тип данных должна вернуть программа на запрос «Когда?». DataTime или что-то типа того. Человек же на это стабильно выбрасывает Exception. Да не один, а много, желательно с General Protection Fault. Это реально баг в прошивке практически всех людей!
Что за гадость такая? Почему люди так сильно не любят оценивать сроки? Ведь всё просто:
Корневая причина в том, что, оценивая объем работ, мы сталкиваемся с неопределенностью.
Мы вынуждены предсказывать будущее — строить прогноз и нести за него ответственность. Начальники и клиенты требуют этого от нас, а мы — от своих подчиненных.
Но прогнозы нужны нам как опора. Как попытка отгородиться от неопределенности. Как попытка удовлетворить главное желание. И я не про секс, голод и сон, а про желание управлять реальностью. Каждый день. О, как велико в этот момент искушение спихнуть контакт с неопределенностью на другого…
Самое лучшее, что мы можем сделать — построить адекватную модель работы с неопределенностью. Которая позволит создать алгоритм оценки или хотя бы разделить ответственность между этой моделью и оценщиком. Знать ограничения этой модели. А затем — научить пользоваться моделью тех, кто даёт оценки вам.
С древности такими моделями были гадания: бросание костей, гадание по внутренностям животных, по тени и прочая мистическая радость. На гаданиях основаны мировые религии. Но это не совсем то, на чём я бы хотел основывать свои бизнес-процессы.
Судя по всему, даже Бог подчиняется принципу неопределённости, и не может одновременно знать положение и скорость частицы.
Стивен Хокинг
Вернёмся к формуле. Она, в принципе, верная.
Пакость в том, что ни числитель, ни знаменатель этой дроби не известны. Хотя бы потому, что:
Все известные мне математические модели, пытающиеся ответить на вопрос «ДОКОЛЕ?», построены на серьезных упрощениях. Применять их на практике можно только для демонстрации несостоятельности этих моделей и тщетности бытия.
С определенной долей вероятности можно спрогнозировать дату завершения задачи или проекта, если:
Хуже всего дела обстоят у сэйлов, которые вынуждены делать вид, что все эти условия выполнены (хотя как раз наоборот). Но мы попробуем проникнуться этой галлюцинацией. В этом случае можно допустить, что вероятность завершения задачи к определенному сроку соответствует нормальному распределению Гаусса.
Про колокол Гаусса что-то слышали даже гуманитарии. Это распределение часто встречается в природе. Понятие «нормальный рост», «нормальный вес» и «нормальный человек» — это как из области Гауссовской нормальности. Колокол Гаусса пытаются привязать везде, где можно и нельзя, если речь идет о чем-то подверженном влиянию огромного числа случайных помех.
Итак, если возникает вопрос: «Какая там вероятность уложиться в оценку?» — можно ответить — «Нормальная» — и показать этот график.
Посередине колокола — наиболее вероятная трудоёмкость. Но поскольку мы работаем с величинами, подверженным случайностям — нам нужно делать допуск на величину рассеивания значений случайных величин (по-умному — среднеквадратичное отклонение или σ). Проблема в том, что если мы берем диапазон в ± 1σ — вероятность, что мы уложимся в наш интервал оценки, всего 68%. В оставшейся трети случаев нас обвинят в некомпетентности и поставят в угол.
На величину 2σ — вероятность будет 95%, но сам интервал получится до неприличия большой. Тут уже ваш заказчик скажет: «Фу-фу, вы не можете мне сказать точные оценки, а конкуренты сказали. Вы — упыри. До свидания». Пять процентов — это не так то мало, если у вас много задач, и за срыв сроков по каждой из них мучительно бьют.
3σ — 99.7% вероятности попадания в нужный нам интервал. Если клиент спрашивает «К какому сроку вы гарантированно закончите проект» — ответ НИКОГДА будет математически правильный. Даже в этих синтетических условиях математика против вас.
К сожалению, для оценки задач Гауссово распределение использовать некорректно. Если компания аккуратно собирала данные по прогнозам и реальным срокам, скорее всего, график распределения вероятностей будет выглядеть примерно так:
Это больше похоже на распределение Пуассона (похоже, да не оно). От нормального распределения Гаусса отличается тем, что сначала какое-то время имеет значение 0, затем начинает расти (в этой точке оценки дают оптимисты), быстро доходит до пика (это точка, в которой дают оценки реалисты) и имеет длинный хвост справа (там сидят все факапы и сработавшие риски).
Такое распределение вероятностей естественно, т.к. сделать задачу на час раньше реалистичного срока сложнее, чем затянуть на неделю. Работа занимает столько времени, сколько на неё отвели — закон Паркинсона [1]. Поэтому раньше всё равно не получится.
А оптимисты не укладываются в сроки практически всегда.
Для нас важно иметь возможность давать вилки на проекты с разбросом от реалистичной оценки до наиболее вероятной, например, 80%. А клиенту может быть интересна именно оптимистичная оценка. Но назвать её одну вы не можете, потому что не знаете, какие риски могут сработать с этим человеком. Поэтому сообщаете вилку.
Клиент может отреагировать на неё крайне резко (особенно если он — бывший программист). Ему не понятно, почему появилась вилка — задача ведь известна! Сказать клиенту в лоб, что «Вилка появилась потому, что мы еще не знаем, насколько ты адекватный» — конфликтный вариант. Проще объяснить, что вилка нужна для подстраховки.
Более веселые математические модели (PERT-анализ, логнормальное или устойчивое распределение) годятся только для изысканных понтов на конференциях. Но не особо помогают при общении с клиентом, который просит «не грузить этой фигней, а четко сказать, сколько стоит и когда будет готово».
Тем не менее, ознакомить своих сотрудников с азами этих моделей очень полезно. Ознакомить и попросить действовать адекватно, не грузить этой фигней и четко говорить, сколько стоит и когда будет готово.
Под адекватной моделью я понимаю такую, которая дает приемлемую для практической деятельности точность.
Я считаю, что нужно приучить людей жить с неопределенностью. Да, математика и бытие сильно против нас. Но нужно заставлять себя давать оценки с хорошей долей вероятности (скажем, 80% или 90% в зависимости от сферы), оставшиеся риски брать на себя. В случае, если они возникли — извиниться (перед клиентом), поулыбаться и замять конфликт или сделать профакапленное за свой счет (не уходя в отрицательную прибыль).
Клиента нужно приучить к вилкам и к тому, что в них заложена подстраховка. Это не обман, а реальность. Мы можем быть уверенными только в одном: здесь работает закон Мёрфи. Если он бьёт часто, буферы должны быть больше. Проверить частоту Мёрфи можно итеративно.
Если клиент категоричен и не хочет видеть вилки — просто уберите нижнюю границу. Но важно не только закладывать адекватные буферы, но и пристально контролировать их расход.
Если буфер съеден на треть, а работа еще не готова — это повод начать экспедирование и проталкивание. В сфере веб-разработки мы используем burndown chart, чтобы визуализировать расход.
Экспедирование и проталкивание при отлаженных процессах должны занимать не более 5% всей работы. Если меньше — значит, у вас есть запас мощностей. Если больше — у вас проблема.
На сложных проектных цепочках наибольший контроль должен быть на выявлении бутылочного горлышка проекта и контроле его питающих буферов.
Есть всего ДВА способа делать оценки:
На начальном этапе, когда человек еще не приучен давать точные оценки, ему надо рассказать, зачем они нужны. И не бить, если что-то пойдет не так — это вредно, т.к. будут презакладывать, а потом сработает закон Паркинсона, затем закон Мёрфи и тенденция факапить и затягивать будет прогрессировать. Но бить, если исполнитель не проэскалировал при возникновении проблемы.
Задача руководителя — приучить оценивать свою работу. Не просто давать задачу и смотреть, как человек с криками «Бляха-муха!» бежит ее делать. А убедиться, что нужный объем работ проанализирован.
В чистом виде прогноз на основе прошлого опыта возможен только в типовых, часто повторяющихся и жестко регламентированных профессиях и операциях. Такие пока что еще существуют, но будут вытеснены роботами и процессорами за двадцать долларов. Оценки конвейерной работы можно получить из статистики прошлых периодов.
Опора на прошлое имеет ряд недостатков, которые влияют на точность оценки.
К тому же мы не в Японии и не в Германии. Мы — в России. А для нас характерно творческое отношение ко всему. В том числе к регламентам и правилам. Иногда это хорошо, но сильно вредит на конвейерном производстве.
Творческое отношение приводит к тому, что в какой-то момент делать однотипные вещи становится скучно. И, если мы вынуждены ими заниматься, пробуем делать их другим способом. А это значит, что качество работ и время, на них затраченное, изменятся. Возрастёт опасность ошибок и провала по срокам.
Нет ничего страшного, если это контролируемо: мы понимаем, что задача носит экспериментальный характер и закладываем время на эксперимент (а не внезапно узнаем, что вместо четкой и отлаженной работы сотрудник чисто-по-приколу начал экспериментировать и упоролся).
Наша подстраховка будет основана только на страхе и нежелании испытать негативные последствия. Пускай даже они заключались в том, что мы не уложились в свои же оценки, и нас за это даже не ругали. На страхе, но никак не на здравом смысле.
Экспериментируем, забываем, боимся. Поэтому грамотному руководителю важно оговаривать не только оценку сроков, но и способ, которым будет получен результат — иначе его ждут сюрпризы. Все, что может быть рационально автоматизированно и стандартизированно — должно быть автоматизированно и стандартизированно. А задачи, предполагающие эксперименты с новыми технологиями или способами работы, должны быть отдельно оговорены как экспериментальные (с отдельным резервом бюджета и сроков).
Итак, одного опыта для оценки недостаточно. Два других способа — экспертные оценки и интуиция.
Лучшее, что мы должны проделать — представить, как именно мы будем реализовывать задачу. Чем детальнее представим, тем точнее будут прогнозы. Тут важно говорить правду самому себе: если в мысленном эксперименте по ходу работы появились технологические нестыковки — они гарантированно выльются в дополнительное время.
Картина мира может быть неадекватной — тогда в процессе работы мы сталкиваемся с неожиданностями. Там, где мы не хотим разбираться в мелочах и вникать в детали, мы хотим просто закинуть много подстраховки. У программистов есть формула «Оцени, а затем умножь либо на π (3,14...), либо на e (2,71...). Немаленькие множители, да и разброс большой. Но в итоге факапим даже с ними. Всё дело в невнимательности к мелочам, лени разбираться или отсутствии адекватных ресурсов на изучение нюансов.
Да, оценка требует ресурсов, иногда — серьезных. Если задача новая, процесс оценки должен быть разбит на стадии.
Чем мы внимательнее к мелочам — тем точнее наши прогнозы. К сожалению, учить кого-то быть внимательным к мелочам трудно и долго. Но нужно, пусть даже через сопротивление. Если совсем никак — тогда расставаться.
В IT все сильно заморочены по поводу точности оценок, сроков и ресурсов. В других отраслях такой щепетильности не наблюдается. У IT-шников это возведено в культ. Впрочем, как и работа по фактически затраченному времени и фокусы с умножением на e и на π.
Многообразие методов говорит только о том, что IT-шники много думали, как решить проблему. Ниже — пара техник, которые помогают людям втянуться в оценки.
Человеку сложно оценивать абсолютные величины. А вот с относительным проблем меньше.
Какой размер у Юпитера? Руками не показать, словами не описать — цифры слишком большие для понимания маленьким земным
А теперь скажите, какой размер у Юпитера по сравнению с Землёй, используя аналогии. Здесь уже проще: Земля размером с горошину, а Юпитер — с арбуз. Земля носит маечку размера S, а Юпитер — XXXL.
В IT при правильно воспитанных заказчиках допустимо делать оценки задач не в абсолютных, а в относительных величинах. Новые задачи оцениваются относительно какой-то простой и всем известной. Кроме того, оценка в относительных величинах позволяет компенсировать естественные погрешности в самих оценках и в формулировках задач (т.к. на проекте количество корявых задач и кривых оценок будет примерно одинаковым от этапа к этапу).
К сожалению, автору неизвестно, применяется ли где либо еще на практике относительные оценки. Всем подавай точные сроки и деньги :)
Если маечки и прочие сравнения вам не подходят, переходите на Planning Poker. Это способ в игровой манере вытянуть из исполнителей все мелочи процесса и возможные проблемы. И в итоге получить оценку задачи, близкую к реальности. В колоде покера — карты с цифрами (вот это поворот!), которые обозначают часы: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Соберите команду исполнителей вместе, озвучьте задачу, попросите положить на стол карту со временем, которое потребуется для выполнения. Карты выкладываются рубашкой вверх — это позволяет снизить влияние авторитетов. После все одновременно вскрываются.
Если цифры одинаковые или немного различаются — записывайте в план общее арифметическое. Если есть значительная разница — уточните у отличившихся, почему они оценили задачу так. Кто-то не учёл длительную доставку деталей из другого города? Или забыл про инновационное ПО, которое установили на прошлой неделе? Всплывут новые подробности, и оценка станет точнее.
Не давите, чтобы в сроки, которые вы получили в покере, всё было сделано — закон Мёрфи никто не отменял. На этот случай менеджер должен закладывать подстраховку.
Если с помощью покера получить оценку невозможно (потому что для него нужен опыт) — добавьте стадию стартапа/ ресёрча. На ней исполнитель делает часть задачи, оценивает объём и сложность всей работы и может прикинуть, сколько времени ему понадобится, чтобы закончить.
Используйте декомпозицию — разбивайте абстрактную большую задачу на маленькие и конкретные, которые легко оценить.
Декомпозиции нужно обучать. Если рассматривать на примере IT — примерно так.
Сначала берется готовый проект, который разбирается на составляющие — чтобы человек, который должен дать оценку, понял, в чём суть и что от него хотят.
Постепенно задача усложняется: для декомпозиции дается проект, в котором есть только прототип. Затем — стандартное техническое задание, потом — плохое и сложное ТЗ.
Человек должен научиться готовый цельный проект или ТЗ делить на этапы и составляющие. И каждому давать оценку. Когда научится — его оценки станут адекватными, приближенными к идеальному проценту вероятности и без необъяснимых буферов.
Чтобы человек мог ставить оценки близкие к реальности, у него должны быть прокачаны требовательность к самому себе, честность перед собой и понимание технологического процесса.
Если эти скилы уже есть, далее воспитывайте его по схеме:
В нашей отрасли можно научить человека делать хорошие оценки за пару недель. Для тренировки нужно использовать типовые объекты и давать постоянную обратную связь. При такой работе зона, где человек сможет делать прогнозы, будет постоянно расширяться.
Автор: zevvssibirix
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/scrum/178728
Ссылки в тексте:
[1] закон Паркинсона: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9F%D0%B0%D1%80%D0%BA%D0%B8%D0%BD%D1%81%D0%BE%D0%BD%D0%B0
[2] мозгом: http://www.braintools.ru
[3] Источник: https://habrahabr.ru/post/308494/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.