Быстрая и точная оценка проекта

Быстрая оценка проекта — как фастфуд. Дешево, вредно, но порой необходимый атрибут профессиональной жизни.

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех).

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

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

Требования к оценке проекта

Дядя Бобсделал замечательное видео об эффективных оценках. И он подчеркнул 3 главных качества хорошей оценки проекта:

• честность;
• прецизионность;
• точность.

Честность

Как можно измерить честность оценки? Честность — что это вообще значит?

Честность в первую очередь перед самим собой.

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

Прецизионность

Прецизионность — это значит, что если вы оценивали 3 похожих проекта, то вы должны получить 3 похожие оценки. Если одна CMS-ка средней руки займет 1 человеко-год имплементации, то разработка другой CMS-ки схожего функционала никак не может занять 3 собако-недели или 5 рабо-лет.

Убедитесь, что ваши цифры не противоречат друг другу и не вызывают сомнений в вашем профессионализме и здравом уме. Страничка с контактами не может занять дольше, чем главная страница вашего сайта. Простой RESTFull сервис не должен занять больше, чем самообучаемый AI сервис аналитики.

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

Точность и условия оценивания проекта

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

И точность оценки — это очень крепкий орешек. В основном это вызвано:

• Временным ограничением. У вас обычно очень мало времени на оценку проекта. Особенно если вы работаете напрямую с сейлз-командой. Этим ребятам нужно все и сразу. Без исключений.
• Недостатком информации. У вас нет полной информации о списке функционала, целевой аудитории и т. д. Иногда все, что у вас есть, — это полпараграфа текста. А временами и исписанная вашим боссом салфетка из бара напротив. GoogleIT©может помочь. Но в основном вам придется работать в условиях крайне ограниченной информации о проекте.

А чтобы получить больше информации, вам нужно больше времени. Которого у вас нет.

Добавьте к этому следующее:

• Точность оценки в зависимости от трудозатрат растет логарифмически.
• Трудозатраты на повышение точности оценки проекта растут экспоненциально.

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

Вероятностная сущность оценки сроков проекта

Это приводит нас к вероятностной сущности оценки сроков проекта.

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

Оценка срока реализации проекта — величина вероятностная.

Честный, прецизионный и точный способ представления оценки проекта звучит примерно так: «Проект займет 6 недель с вероятностью успеха 95 %. Или он займет 4 недели с вероятностью уложиться в срок 65 %». Можно еще представлять оценку проекта в виде диапазона значений с учетом 95 % вероятности успеха: «Скорее всего, проект займет от 4 до 6 недель».

Единица измерений

Перед тем как идти дальше, давайте определимся с единицами измерений сроков проекта. Довольно часто используется человеко-день, то есть сколько дней один человек будет делать задачу.

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

Как следствие, в этой статье я буду использовать Average Working Day (AWD)как единицу измерения.

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

Вдобавок мы обычно не работаем в одиночку. Мы работаем в команде. И существует вековая проблема масштабирования команды согласно ожидаемого/желаемого срока разработки проекта. См. «9 женщин не могут родить ребенка за 1 месяц» и закон Брукса.

Но для простоты мы опустим эти детали и будем считать, что 2 человека могут справиться с задачей на 2 AWD за 1 день, 4 — за полдня и т. д.

Расчет диапазона срока выполнения проекта

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

Трехкратный метод

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

• B — best case (оптимистическая) оценка срока, 95 % вероятности не уложится в срок.
• N — nominal (номинальная) оценка срока, 50 % вероятности уложится в срок.
• W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложится в срок.

Считайте, что уложиться в оптимистичный срок можно, только если сам Один сядет за лэптоп и всей своей мудростью и силой затянет проект прямо в Вальхаллу. Оптимистичная оценка — это минимально необходимое время для реализации проекта при наилучших обстоятельствах. Задача наверняка будет выполняться дольше, чем рассчитано по best case. Также можете считать это вашей Big-Omegaоценки срока.

Номинальная оценка — наиболее реалистичный срок. Это самое важное значение, так как оно имеет наибольший вес в дальнейших расчетах. Эта оценка должна быть умеренно оптимистичной при ваших обычных условиях работы. Считайте, что у вас есть 50%-ная вероятность не уложиться в номинальный срок. Также можете считать это вашей Big-Thetaоценки срока.

Пессимистическая оценка дается исходя из того, что все пойдет не так. Ваш ноут утащила в нору офисная крыса. Ваш дизайнер оказался мартышкой-наркоманом. Вас призвали в армию за день до релиза. Это наихудшая оценка, которую вы можете дать задаче. И у вас только 5%-ный шанс не уложиться в этот срок. Также можете считать это вашей Big-Oоценки срока.

Очевидно, что

B < N < W

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

Давайте рассмотрим трехкратный метод на примере.

Пример требований к проекту

The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.

Предположим мы разбили требования на 3 задачи:

Пример трехкратной оценки задач

Расчет СКОи среднего арифметического взвешенного

Среднее значение срока выполнения задачи (mean) рассчитывается как:

M = (B + 4N + W)/6

Почему коэффициент 4 для номинальной оценки? Потому что она наиболее реалистичная. И мы хотим выделить ее по сравнению с другими оценками. Почему именно 4, а не 6 или 8? Потому что Rocket Science.

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

И получаем:

Теперь давайте рассчитаем СКО (Standard Deviation) для каждой задачи:

S = (W — B)/6

И общее СКО для всего проекта:

Project Standard Deviation = SQRT(SUM(S)^2)

Для нашего проекта имеем:

СКО показывает вариативность вашей оценки. Чем оно больше — тем больше будет диапазон вашей оценки. Не говорите об СКО проекта людям с гуманитарным образованием :)

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

Бета-распределение

Для получения вероятности успешного выполнения проекта в оцененный срок я использовал бета-распределение. Потому что его применяли в PERT.

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

В общем мы рассчитываем вероятность успеть в срок исходя из среднего значения и СКО проекта.

Для нашего проекта получаем следующую функцию распределения:

Читается график так: «Проект будет завершен за 177 AWD с 95 % вероятностью».

Вот небольшая табличка шансов проекта на успех:

Если вы сравните со средним значением продолжительности проекта (102 AWD), то поймете, почему не следует просто использовать среднее.

Вот мы и получили вероятностную оценку срока выполнения проекта.

Диапазон оценки

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

The 95 % confidence interval for the true project work time is approximately:Project Total Mean ± 2 × Project Standard Deviation

Коэффициент 2 основан на правиле 68-95-99.7.

Для нашего проекта получаем: «Проект займет от 21 до 183 дней».

Можем опустить нижнюю границу диапазона и сказать: «Проект займет от 102 до 183 дней».

Конечно, можно использовать коэффициент 1, получая:

Project Work Time = Total Mean ± 1 × Project Standard Deviation

Но следует учитывать, что в этом случае мы говорим о вероятности окончания проекта в срок, равной 68 %.

Excel Workbook для проекта

Здесьнаходится Excel Workbook с примером расчетов для нашего проекта. Юзайте с миром :)

Дополнительные требования

Постарайтесь разбивать проект на максимально независимые задачи. Рекомендуется использовать около 20 и более задач для получения более точного результата.

Вывод

Оценка проектов в мире IT далека от точной науки. И так будет продолжаться еще долго. Методология использования трехкратного метода с бета-распределением не идеальна. Но она может дать вам больше уверенности в ваших оценках. Уверенность поможет добиться доверия к вашим словам, а на доверии и держится весь процесс оценки проектов.

P. S.

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

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

Так как же оценивать проекты, чтобы получить верифицируемый результат? Хороший вопрос. Выше я описал несколько вариантов. Также здесьесть пару идей. Но для меня это все еще открытый вопрос.