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

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

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

Вот — случай из жизни.

Тут я опустил или изменил кое-какие незначительные детали, чтобы сохранить анонимность команды и компании, о которых пойдёт речь. Этот рассказ публикуется с их разрешения.

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

Товарищам из отдела маркетинга хотелось знать о том, когда клиенты смогут воспользоваться новым софтом. Команда разработчиков подготовила план работ, который должен был привести её к созданию MVP (Minimum Viable Product, минимально жизнеспособный продукт), спланировала нагрузку на программистов и прикинула срок, необходимый для создания MVP: шесть месяцев.

Программа вышла только через два года.

Закон Хофштадтера (Hofstadter's Law): на выполнение любой задачи всегда уходит больше времени, чем ожидается — даже в тех случаях, когда принимают во внимание закон Хофштадтера.

— Дуглас Хофштадтер

Это, если выразиться весьма скромно, была огромнейшая проблема. Но проблема была не в том, что разработка заняла два года. У компании был стабильный доход, позволявший держаться на плаву, а долгосрочные выгоды от выхода на новый уровень технологий, в итоге, оправдали бы столь длительный период «выращивания» новой технологии.

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

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

Что пошло не так?

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

Если вы сталкивались с проектами, которые выбивались из графика, то вы, вероятно, подумаете, что тут речь идёт о так называемом «scope creep» — о неконтролируемом расширении масштаба проекта. Такое случается, когда в проект, во время его реализации, постоянно добавляют новые требования, что приводит к увеличению сроков его реализации и к их выходу за изначально установленные рамки. Соглашусь — такое, и правда, было. Это определённым образом повлияло на ситуацию, но я думаю, что точнее будет описать эту ситуацию, прибегнув к термину «scope discovery» — масштабы проекта становились понятными лишь в процессе работы над ним. Изначальная цель проекта была в том, чтобы сформировать основу для удовлетворения будущих потребностей. В ходе работы над ним команда постоянно узнавала что-то такое, о чём раньше и понятия не имела. Так всегда бывает в индустрии высоких технологий.

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

Обнаружение закономерностей

Если вы работаете в индустрии информационных технологий — эта история, скорее всего, хорошо вам знакома. Сроки, ранее приблизительно определённые, сдвигаются на [СЛИШКОМ_МНОГО], команда разработчиков оказывается во всём виноватой, а прибитые стрессом инженеры начинают работать сверхурочно, чтобы хоть как-то свести концы с концами.

Такое случается даже тогда, когда команды применяют всяческие хитроумные приёмы, нацеленные на улучшение достоверности оценок времени выполнения задач. Числа Фибоначчи. Сторипойнты. Цифровые карты. Диаграммы Ганта. Ретроспективные собрания. Ни один из этих методов не способен победить ужас закона Хофштадтера. Мне даже доводилось видеть, как некоторые команды вообще отказывались что-либо оценивать, считая это безнадёжным занятием в духе комиксов про Дилберта. Но не так всё плохо!

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

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

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

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

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

А если сделать то же самое для «5-часовых» задач, то получится примерно следующее:

А если, по чьей-то оценке, на задачу уйдёт 13 часов? Тогда получится вот что:

Заметили что-нибудь?

Первым, на что обратили внимание члены команды, было то, что для выполнения множества 2х-часовых задач понадобилось 10 часов. Оценки сроков, в среднем, оптимистично занижались примерно в 1,6 раза, из-за чего спринты постоянно выбивались из графика. Причём, этот «фактор оптимизма» остался таким же даже тогда, когда разработчики сознательно пытались скорректировать свои оценки с учётом закона Хофштадтера. Видеть то, как далеко их оценки отклонялись от реальности, было весьма неприятно, особенно учитывая то, что однажды они уже обожглись и теперь выкладывались по полной. Все надеялись увидеть то, как показатели реального времени, ушедшего на выполнение задачи, компактно распределяется вокруг оценки. В идеале — между ближайшими числами Фибоначчи.

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

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

Хотя здесь я и привожу гистограммы, показывая, как именно выглядели изначальные данные, не могу сказать, что предпочитаю использовать для визуализации произвольных данных именно такие графические структуры. Дело в том, что выбор ширины столбцов гистограмм (обычно произвольный) может сильно повлиять на восприятие результатов. Любую числовую гистограмму можно представить гораздо точнее — в виде накопительной функции распределения (Cumulative Distribution Function, CDF). Для этого надо отсортировать образцы данных и нанести на график их накопленную сумму. Выглядеть это будет примерно так:

Если нужно показать плотность вероятностей — это будет производная от CDF, то есть — возврат к исходным данным. Ну — почти к исходным данным, так как они слишком шумны (именно поэтому их изначально распределили по группам). А вместо того, чтобы распределять их по группам, из-за чего теряется часть информации, тут отлично подойдёт применение хорошо настроенного сглаживающего фильтра, что позволит чётче увидеть реальную картину.

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

Но это — далеко не всё…

Появляется дикое логнормальное распределение вероятностей! Страшно эффективная штука!

Эдвин Томпсон Джейнс говорит о том, что распределение вероятностей зависит от состояния наших знаний. Наше исследование выявило именно то, как выглядят знания квалифицированного разработчика о задаче, которую пока не начали выполнять. Это нечто такое, что даже сам разработчик не в состоянии осознанно сформулировать. И хотя перед нами — «длиннохвостое» распределение вероятностей, оно оказалось на удивление стабильным при оценивании сроков выполнения разных задач.

Существует множество распределений с длинными хвостами, которые похожи друг на друга. Но есть всего одно, которое подозрительно хорошо описывает данные, делая это с поразительно маленьким количеством параметров. Это — логнормальное распределение. И это — не любое подобное распределение. В нашем случае это — самая простая его разновидность. Его параметр формы равен 1, а параметр сдвига — 0. У этого логнормального распределения всего один настраиваемый параметр — параметр масштаба m, который соответствует медиане, а медиана — что весьма примечательно — в точности совпадает с оценочным временем выполнения задачи. И, кстати, среднее этого распределения, как оказалось, в 1,6 раза больше медианы.

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

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

Главная проблема в том, что никому нет никакого дела до медианных значений!

Не надо мне вероятностей! Дайте число!

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

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

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

Когда представитель отдела маркетинга просит меня оценить срок выполнения задачи — ему нужно что-то, чему можно доверять. А именно — срок, к которому, с вероятностью в 99%, продукт будет готов. Если дело будет сделано раньше — прекрасно. Но спрашивает он не об этом. Ему нужен 99-й перцентиль. И когда он слышит «четыре часа» — он полагает, что ему сообщают именно это значение. И это — не его вина — он просит одно число, и ему это число сообщают. Просто никто никогда не рисовал распределение вероятностей для того, чтобы разобраться в том, об одном и том же числе идёт речь, или нет.

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

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

Кстати, а почему коэффициент для нахождения медианы равен 1,6? Ваши обстоятельства могут отличаться, но если вам интересны математические выкладки, то дело тут в том, что среднее значение логнормального распределения больше его медианного значения на exp(1/2), то есть — примерно на 1,65.

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

Насколько хорошо всё это обобщается на другие команды и другие проекты?

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

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

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

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

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

Логнормальные распределения — это ещё и такой особый случай, когда, при их сложении, они очень медленно движутся в сторону нормального распределения. Они долго остаются «почти логнормальными» — до тех пор, пока не будет сложено достаточно большое их количество.

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

Редко увидишь, как хоть кто-нибудь включает в презентацию для управленцев такие слова: «… а потом нам, вероятно, понадобится попробовать ещё раз». Но существует один не очень популярный метод планирования проектов — GERT, в котором это допустимо.

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

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

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

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