Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать... Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.

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

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

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

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

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

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

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

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

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

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

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

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

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

Судя по всему, даже Бог подчиняется принципу неопределённости, и не может одновременно знать положение и скорость частицы.

Стивен Хокинг

Это вопрос философский, технического решения не имеет

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

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

• Подпись заказчика (кровью) под техническим заданием не гарантирует, что документ описывает именно тот объем работ, который реально нужен. Она даже не гарантирует, что заказчик читал ТЗ. Реальный объем работ вы узнаете только после приёмки проекта.

• Любая постановка задачи гарантированно содержит «дырки», которые можно трактовать двояко. Чем толще постановка — тем больше таких мест.

• Производительность людей (особенно программистов) может отличаться в РАЗЫ и зависит от столь большого числа факторов, что учесть влияние всех просто невозможно.

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

С определенной долей вероятности можно спрогнозировать дату завершения задачи или проекта, если:

• у вас стабильная, сработавшаяся команда исполнителей;

• работы выполняются для одного и того же клиента, который дает стабильную обратную связь (читай — генерирует прогнозируемое количество «правочек») и демонстрирует стабильные требования к качеству;

• команда уже работала с подобными задачами;

• рабочий процесс, технологический стек и окружающая среда — неизменны;

• сам проект укладывается в головах команды;

• устраивает оценка в относительных, а не в абсолютных величинах (никаких тебе рублей и часов!);

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

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

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

Итак, если возникает вопрос: «Какая там вероятность уложиться в оценку?» — можно ответить — «Нормальная» — и показать этот график.

Посредине колокола — наиболее вероятная трудоёмкость. Но поскольку мы работаем с величинами, подверженным случайностям — нам нужно делать допуск на величину рассеивания значений случайных величин (по-умному — отклонение или σ). Проблема в том, что если мы берем диапазон в +/- 1σ — вероятность, что мы уложимся в наш интервал оценки, всего 68%. В оставшейся трети случаев нас обвинят в некомпетентности и поставят в угол.

На величину 2σ — вероятность будет 95%, но сам интервал получится до неприличия большой. Тут уже ваш заказчик скажет: «Фу-фу, вы не можете мне сказать точные оценки, а конкуренты сказали. Вы — упыри. До свидания». Пять процентов — это не так то мало, если у вас много задач, и за срыв сроков по каждой из них мучительно бьют.

3σ — 99.7% вероятности попадания в нужный нам интервал. Если клиент спрашивает «К какому сроку вы гарантированно закончите проект» — ответ НИКОГДА будет математически правильный. Даже в этих синтетических условиях математика против вас.

Торги и манипуляции

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

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

Такое распределение вероятностей естественно, т.к. сделать задачу на час раньше реалистичного срока сложнее, чем затянуть на неделю. Работа занимает столько времени, сколько на неё отвели — закон Паркинсона. Поэтому раньше всё равно не получится.

А оптимисты не укладываются в сроки практически всегда.

Для нас важно иметь возможность давать вилки на проекты с разбросом от реалистичной оценки до наиболее вероятной, например, 80%.

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

Клиент может отреагировать на неё крайне резко (особенно если он — бывший программист). Ему не понятно, почему появилась вилка — задача ведь известна! Сказать клиенту в лоб, что «Вилка появилась потому, что мы еще не знаем, насколько ты адекватный» — конфликтный вариант. Проще объяснить, что вилка нужна для подстраховки.

Более веселые математические модели (PERT-анализ, логнормальное или устойчивое распределение) годятся только для изысканных понтов на конференциях. Но не особо помогают при общении с клиентом, который просит «не грузить этой фигней, а четко сказать, сколько стоит и когда будет».

Тем не менее, ознакомить своих сотрудников с азами этих моделей очень полезно. Ознакомить и попросить действовать адекватно, не грузить этой фигней и четко говорить, сколько стоит и когда будет готово.

Адекватная модель

Под адекватной моделью я понимаю такую, которая дает приемлемую для практической деятельности точность.

Я считаю, что нужно приучить людей жить с неопределенностью. Да, математика и бытие сильно против нас. Но нужно заставлять себя давать оценки с хорошей долей вероятности (скажем, 80% или 90% в зависимости от сферы), оставшиеся риски брать на себя. В случае, если они возникли — извиниться (перед клиентом), поулыбаться и замять конфликт или сделать профакапленное за свой счет (не уходя в отрицательную прибыль).

Про буферы, подстраховку и закон Мёрфи

Клиента нужно приучить к вилкам и к тому, что в них заложена подстраховка. Это не обман, а реальность. Мы можем быть уверенными только в одном: здесь работает закон Мёрфи. Если он бьёт часто, буферы должны быть больше. Проверить частоту Мёрфи можно итеративно.

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

Если буфер съеден на треть, а работа еще не готова — это повод начать экспедирование и проталкивание. В сфере веб-разработки мы используем burndown chart, чтобы визуализировать расход.

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

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

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

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

• опираясь на свою картину мира в прошлом (свой опыт и исторические данные);

• продлевая свою картину мира в будущее (экспертные оценки и интуиция).

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

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

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

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

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

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

К тому же, мы не в Японии и не в Германии. Мы — в России. А для нас характерно творческое отношение ко всему. В том числе к регламентам и правилам. Иногда это хорошо, но сильно вредит на конвейерном производстве.

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

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

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

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

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

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

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

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

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

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

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

1. Постановка задачи, анализ и предварительная оценка (оценивается срок получения сроков).

2. Фаза ресерча.

3. Уточненная оценка, начало работы, фиксация оценки (именно после ресерча и небольшого куска реальной работы).

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

Чем мы внимательнее к мелочам — тем точнее наши прогнозы. К сожалению, научить кого-то быть внимательным к мелочам трудно и долго. Но учить нужно, пусть даже через сопротивление. Если совсем никак — тогда расставаться.

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

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

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

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

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

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

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

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

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

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

Planning Poker

Если маечки и прочие сравнения вам не подходят, переходите на Planning Poker. Это способ в игровой манере вытянуть из исполнителей все мелочи процесса и возможные проблемы. И в итоге получить оценку задачи, близкую к реальности. В колоде покера — карты с цифрами (вот это поворот!), которые обозначают часы: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

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

Если цифры одинаковые или немного различаются — записывайте в план общее арифметическое. Если есть значительная разница — уточните у отличившихся, почему они оценили задачу так. Кто-то не учёл длительную доставку деталей из другого города? Или забыл про инновационное ПО, которое установили на прошлой неделе? Всплывут новые подробности, и оценка станет точнее.

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

Если с помощью покера получить оценку невозможно (потому что для него нужен опыт) — добавьте стадию стартапа/ ресёрча. На ней исполнитель делает часть задачи, оценивает объём и сложность всей работы и может прикинуть, сколько времени ему понадобится, чтобы закончить.

Декомпозиция

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

Декомпозиции нужно обучать. Если рассматривать на примере IT — примерно так.

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

Постепенно задача усложняется: для декомпозиции дается проект, в котором есть только прототип. Затем — стандартное техническое задание, потом — плохое и сложное ТЗ.

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

Как научить людей делать оценки

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

Если эти скилы уже есть, далее воспитывайте его по схеме:

1. Покажите математические модели распределений и объясните, что слиться с оценок не получится.

2. Расскажите, что понимается под адекватной оценкой, как она будет использоваться и почему вам нужна именно она. Расскажите, что вам нужна оценка без перезаложенных в 100500 раз подстраховок.

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

4. Приучите к принципам «уперся — сообщи» и «любая задача должна быть проанализирована и оценена».

5. Заставьте оценивать людей все свои задачи самостоятельно.

6. Дайте изучить статистику организации (сметы и реальные расходы по проектам).

7. Приучите к принципу «не знаешь, что делать — декомпозируй». Дайте несколько проектов на декомпозицию. Проверяйте и ищите дыры и нестыковки. Долго и нудно беседуйте по поводу найденных нестыковок.

8. Дайте оценивать реальные ТЗ. Проходитесь по итоговой оценке строчка за строчкой, спрашивайте, как пришел к ней. Проверяйте на полноту и непротиворечивость. Показывайте дыры в оценках, куда может улетать время.

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

Тем, кто дочитал, дарим наш регламент по оценке средне-типовых проектов (будет интересен коллегам из веб-разработки) и сказочку про Мышу и дедлайн.

Сказка про Мышу и дедлайн

Дед, генеральный директор ООО «Семья Голёнкиных», запустил проект по созданию пареной репы. Его внутренности уже поуркивали от голода, поэтому Деду нужна была точная оценка — когда будет готово? Задачу принести пареную репу поставил Бабке, директору департамента по подаче продовольствия на стол. И вопросом про сроки тоже её озадачил.

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

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

Жучка тянуть репку не собиралась. Она не какая-нибудь гавкалка из породы «принеси-подай», а главная по двору — охраняет сарай, лает на калитку, подпирает стены. На неё работает кошка Мурка, которая отвечает за огородную территорию — ей Жучка и поручила тянуть репку.

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

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

Мыша по опыту знала, что за провал дедлайна ей прилетит когтистой лапой Мурки по ушам. Поэтому подстраховалась и от души накинула 2 часа на риски — итого 6 часов на добычу репки.

Мурка, зная, что Мыша способна на факап, добавила к оценке 3 часа. Итого 9 часов.

У Жучки репутация работника, который всегда укладывается в сроки. Её главный секрет — ко времени на выполнение задачи прибавлять 30% от того, что заявил исполнитель. Итого получилось 12 часов на вытягивание репки.

Внучку эти данные расстроили, но спорить она не стала. Жучке виднее — она не одну репку принесла, Внучка ей доверяла.

По регламенту приготовление пареной репы занимает столько же времени, сколько и вытягивание. Внучка управилась бы за 2 часа, но испугалась обвинений в некомпетентности и поставила задачу на 12. Итого 24 часа.

На Бабке лежала главная задача — презентовать Деду пареную репу. Поэтому к 24 часам она добавила 5 на сервировку и 3 на возможные ЧП. Итого 32 часа.

От озвученных сроков Дед умер с голоду на месте. Проект пареной репы до сих пор не завершён.

Оригинал: http://blog.sibirix.ru/2016/08/30/deadline-miracle/