Как разработчику оценить время на задачу

Оценка проектов в IT — больная тема. Кто не давал невыполнимых обещаний, а потом не сидел в овертайме, чтобы уложиться в тот срок, что сам и озвучил?

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

С тех пор прошло 17 лет. За это время я участвовал в оценке более чем 200 проектов, получил немало уроков и хочу поделиться с вами своими мыслями об оценке проектов.

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

Зачем давать оценки?

Процент «успешных» проектов не превышает 29% (Исследование The Standish Group за 2015 год). Остальные 71% либо провалились, либо вышли за рамки тройного ограничения — сроков, функционала и бюджета.

Из этой статистики делаем вывод, что оценка проектов часто не соответствует действительности. Значит ли это, что давать оценки вообще не имеет смысла? На просторах интернета даже появилось движение за то, чтобы не давать никаких оценок, а просто писать код — и быть, что будет. Что успеем, то успеем (поищите по тегу #noestimates).

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

Или, например, вариант в стиле Agile: «Ну, мы поедем, а ты будешь платить мне каждые 10 минут в пути — и так, пока деньги не закончатся. Как только они кончатся — высажу. Но, возможно, мы уже доедем или окажемся рядом. А если нет — это уже твои проблемы, просто не повезло».

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

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

Лезть в машину, не зная, чего ожидать, — не то, что делают в здравом уме.

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

Причины недооценивания

Игнорирование теории вероятности

Давайте представим, что менеджер спрашивает разработчика, за сколько он сделает задачу. Разработчик уже делал подобное ранее и даёт «наиболее вероятную» оценку — 10 дней. Конечно, есть шанс, что задача займёт 12 дней, но он меньше, чем вероятность выполнения за 10 дней. То же самое с 8 днями — вероятность ниже.

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

Ось X соответствует оценке, а ось Y — вероятности того, что эта оценка окажется точной и задача займёт именно столько времени (ни больше, ни меньше). В центре — точка с наибольшей вероятностью, то есть наиболее вероятная оценка. Эта вероятность соответствует нашей оценке в 10 дней.

Площадь под кривой соответствует полной вероятности — 100%. Это значит, что если мы дадим наиболее вероятную оценку, проект или задача будут выполнены в срок или раньше с вероятностью 50% (площадь под графиком до отметки в 10 часов составляет половину всей фигуры и равна 50%). То есть, руководствуясь этим принципом и давая наиболее вероятную оценку, мы будем срывать сроки примерно в половине случаев.

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

Если принять это предположение, получим следующее распределение:

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

Получается, что если взять «наиболее вероятную» оценку в 10 дней, то вероятность того, что задача будет готова в этот срок или раньше — меньше 50%.

Игнорирование текущего уровня неопределённости

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

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

Исследования Луиса Ларанхейра (PhD, Associate Professor at The University of Brasilia) также показывают, что точность оценки программного проекта зависит от степени проработанности требований (Luiz Laranjeira 1990). Чем лучше определены требования, тем точнее оценка. Оценка оказывается неточной в первую очередь потому, что неопределённость заложена в самой задаче. Единственный способ уменьшить неопределённость в оценке — это снизить её в самом проекте или задаче.

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

Данный график приведён для наглядности. В реальности наиболее вероятная оценка может меняться по мере сокращения неопределённости.

Итак, основные причины недооценивания — неопределённость и игнорирование теории вероятностей.

Зависимость точности оценки от стадии проекта

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

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

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

Так, на стадии исходной концепции наиболее вероятная оценка может отличаться от оптимистичной в 4 раза. На стадии готового UI разброс оценки уже составляет от 0,8 до 1,25 относительно наиболее вероятной оценки.

Для удобства привожу эти же данные в виде таблицы:

Очень важная деталь — конус не сужается автоматически с течением времени. Чтобы он сужался, нужно реально управлять проектом и предпринимать конкретные действия, направленные на снижение неопределённости. Если вы целенаправленно не снижаете неопределённость в процессе выполнения проекта, ваши дела будут выглядеть примерно так:

Область, выделенная голубым, называется облаком неопределённости. На протяжении всего проекта оценка может сильно меняться — до самого завершения работ.

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

Данную модель используют во многих компаниях, в том числе в NASA. Некоторые адаптируют её, чтобы учесть нестабильность требований. Подробнее об этом можно прочитать в книге «Software Estimation: Demystifying the Black Art».

Что считать хорошей оценкой?

Есть много версий ответа на этот вопрос, но на практике, если оценка отклоняется от цели проекта более чем на 20%, у руководителя проекта не остаётся пространства для манёвра. Если же отклонение укладывается в 20%, проект можно успешно завершить, управляя функциональностью, сроками, размером команды и другими параметрами. Это звучит разумно, поэтому возьмём это определение хорошей оценки за основу (на уровне организации такое решение должно приниматься отдельно — кому-то допустимо отклонение в 40–50%, а кому-то и 10% слишком много).

Итак, для нас хорошей оценкой будет считаться та, что отличается от фактического результата не более чем на 20%.

Практика. Оцениваем проект на разных стадиях

Давайте представим, что к вам пришёл менеджер проекта и попросил оценить какую-то функцию или проект.

Первым делом нужно изучить доступные требования и понять, на каком этапе жизненного цикла находится описание задачи или проекта (Исходная концепция, Согласованное определение, Завершённые требования, Готов UI, Спроектирована архитектура).

Дальнейшие действия зависят от того, на каком этапе мы находимся:

Стадия 1. Исходная концепция

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

Когда имеет смысл давать оценку на данном этапе?

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

Что нужно, чтобы дать оценку на данном этапе?

Нужно иметь данные о реальных трудозатратах по похожему завершённому проекту.

Какие инструменты лучше всего подходят на данном этапе?

• Оценка по аналогии

Алгоритм оценки

На самом деле, оценить проект на данном этапе невозможно. Можно лишь сказать, сколько времени занял похожий проект.

Например, оценку можно озвучить так: «Я не могу точно сказать, сколько времени займёт этот проект, потому что данных недостаточно. Но похожий на него проект Х занял Y времени. Чтобы дать хотя бы приблизительную оценку, нужно уточнить требования».

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

Как перейти на следующий этап?

Для этого нужно чётко определить требования — понять, зачем нужно приложение и какие функции оно будет выполнять.

В идеале нужно уметь собирать и анализировать требования.

Для того, чтобы повысить свои навыки в сборе и анализе требований, неплохо прочитать «Разработка требований к программному обеспечению» Карл И. Вигерс, Джой Битти

Для сбора первичных требований вы можете воспользоваться следующим опросником:

• Для чего нужно приложение? Какие проблемы оно будет решать?
• Какие типы пользователей будут пользоваться приложением? (для задачи, озвученной выше — это, скорее всего, Врач, Пациент, Администратор)
• Какие проблемы каждый тип пользователей сможет решать в приложении?
• На каких платформах будет работать приложение?

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

Стадия 2. Согласованное определение продукта

На данном этапе уже понятно, что приложение будет делать, а что — нет. При этом детали пока не проработаны.

Когда имеет смысл давать оценку на данном этапе?

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

Что нужно, чтобы оценить ситуацию на данном этапе?

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

Какие инструменты лучше всего подходят на данном этапе?

• Оценка по аналогии
• Оценка сверху вниз

Алгоритм оценки

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

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

Так, например, в случае приложения «где доктора будут консультировать пациентов» у нас могло бы получиться следующее:

• Регистрация
• Система записи на приём
• Система уведомлений
• Видеоконсультации
• Система отзывов
• Система оплаты

И для оценки блока «Регистрация» можно использовать оценку с одного проекта, а для блока «Система отзывов» — с другого.

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

Так, например, модуль «Система отзывов» может показаться в два раза сложнее модуля «Регистрация». Соответственно, для него можно взять оценку, в два раза превышающую оценку модуля «Регистрация».

Этот метод (оценка одного блока относительно другого) очень неточный, и его стоит применять только в том случае, если количество блоков, которые ещё не реализовывались, не превышает 20% от общего числа блоков с историческими данными. В противном случае это будет чистой воды угадывание.

После этой процедуры оценки по всем блокам складываются — получается наиболее вероятная оценка. Пессимистичную и оптимистичную оценки можно рассчитать, умножив её на коэффициенты, соответствующие текущему этапу — 0,5 и 2 (см. таблицу коэффициентов).

В идеале это уже можно сообщить менеджеру — он должен разобраться, что с этим делать.

Если менеджер не может разобраться и просит одно число — есть способы его дать.

Как из трёх оценок (пессимистичная, оптимистичная и наиболее вероятная) сделать одну, я расскажу позже в разделе «Как из трёх оценок получить одну?».

Как перейти на следующий этап?

Чтобы перейти на следующий этап, нужно составить полный список требований. Существует множество способов их документирования, но мы рассмотрим распространённый вариант — User Story.

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

Так, например, для блока «Система отзывов» после сбора и анализа требований мы можем получить следующее:

• Пациент может просмотреть все отзывы о выбранном докторе
• Пациент может оставить отзыв врачу после видеоконсультации
• Доктор может видеть список отзывов, которые оставили ему пациенты
• Доктор может оставить комментарий к отзыву о своей консультации
• Администратор может просматривать все отзывы на сайте
• Администратор может редактировать выбранный отзыв на сайте
• Администратор может удалить выбранный отзыв на сайте

Также нужно собрать и записать все нефункциональные требования к проекту. Чтобы собрать их, можно воспользоваться следующим чек-листом:

• На каких платформах должно работать?
• Какие операционные системы нужно поддерживать?
• С чем нужно интегрироваться?
• Как быстро должно работать?
• Сколько пользователей должно поддерживать одновременно?

Прояснение этого будет означать переход на следующий этап.

Стадия 3. Требования собраны и проанализированы

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

Когда имеет смысл давать оценку на данном этапе?

Когда нужно дать предварительную оценку проекта перед началом работы по модели T&M. Оценки задач на этом этапе можно использовать для приоритизации задач, планирования даты релиза и общего бюджета проекта. Также они помогают контролировать производительность команды и оценивать её эффективность.

Что нужно, чтобы оценить ситуацию на данном этапе?

• Список функциональных требований
• Список нефункциональных требований

Какие инструменты лучше всего подходят на этом этапе?

• Оценка снизу вверх
• Оценка по аналогии

Алгоритм оценки

Нужно разбить каждую задачу на части (провести декомпозицию). Чем мельче вы разобьёте задачу, тем точнее будет оценка.

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

Например, для нашей User Story «Пациент может просмотреть все отзывы о выбранном докторе» могла бы получиться следующая картина (иллюстрации ниже специально сделаны от руки, чтобы показать, как процесс оценки может выглядеть на практике):

Тут мы разделили задачу на 3 составляющие:

• Создать инфраструктуру в базе данных
• Сделать уровень DAL для выборки данных
• Сделать UI, где будут отображаться сами отзывы

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

Если вы хотите повысить навыки проектирования интерфейсов, стоит прочитать «Интерфейс» Джефа Раскина и «Об интерфейсе. Основы проектирования взаимодействия» Алана Купера.

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

Если задача занимает больше 8 часов, её нужно разбить на подзадачи.

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

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

• Тестирование
• Дизайн
• Создание тестовых данных
• Поддержка разных разрешений экрана
• …

Один из возможных вариантов такого чек-листа вы можете посмотреть здесь.

После прохода по этому списку нужно добавить в список задач то, что могло быть пропущено:

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

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

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

Оставшиеся две оценки можно рассчитать, используя коэффициенты, соответствующие текущему этапу — х0,67 и х1,5 (см. таблицу коэффициентов).

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

• Оптимистическая оценка — 14 часов
• Наиболее вероятная — 20 часов
• Пессимистическая — 31 час

Как перейти на следующий этап?

Чтобы перейти к следующему этапу, нужно спроектировать интерфейс пользователя. Лучший способ — создать wireframes.

Для этого есть множество программ, но я бы порекомендовал обратить внимание на Balsamiq и Axure RP.

Прототипирование — отдельная обширная тема, выходящая за рамки данной статьи.

Наличие wireframe будет означать переход на следующий этап.

Стадия 4. Интерфейс спроектирован

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

Когда имеет смысл давать оценку на данном этапе?

Для подготовки точной оценки по модели Fixed Price, а также для всего, что было перечислено на предыдущем этапе.

Что нужно, чтобы оценить ситуацию на данном этапе?

• Готовые wireframes
• Список функциональных требований
• Список нефункциональных требований

Какие инструменты лучше всего подходят на данном этапе?

• Оценка снизу вверх
• Оценка по аналогии

Алгоритм оценки

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

Как перейти на следующий этап?

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

Получаем одну оценку из диапазона

Если у вас уже есть наиболее вероятная, пессимистическая и оптимистическая оценки, то для того, чтобы получить одну оценку, можно использовать наработки Тома ДеМарко, который в своей книге «Вальсируя с медведями» поднял идею, что абсолютная вероятность может быть вычислена путём интегрирования площади под кривой (того самого графика асимметричного распределения вероятностей, что мы рисовали ранее). Оригинальный шаблон для подсчета можно скачать тут (также доступен без регистрации тут). В шаблон нужно просто подставить 3 числа и получить результат в виде списка оценок с соответствующими им вероятностями.

Например, для оценок 14, 20 и 31 получим следующий результат (скрин с шаблона excel):

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

Не знаем, как оценить — говорим

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

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

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

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

Сомневаемся — не обещаем

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

Эффективные организации и разработчики не берут на себя обязательства, пока не завершат работу по сужению конуса.

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

Ниже приведена иллюстрация улучшения качества оценок в проектах ВВС США при переходе на более высокий уровень зрелости CMM (Lawlis, Flowe and Thodahl, 1995).

Думаю, тут есть над чем задуматься. Статистика по другим компаниям подтверждает эту связь.

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

Выводы

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

Полезные книги

На тему оценки трудозатрат написано много литературы, но я выделю две книги, которые просто необходимо прочитать:

• «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения» Том деМарко и Тимоти Листер

• «Software Estimation: Demystifying the Black Art» Steve McConnell