×Закрыть

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

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

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 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 задачи:

Work Item Name
1User Login
2Purchase Commodity
3Purchase History

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

Work Item NameBNW
1User Login1030100
2Purchase Commodity1540150
3Purchase History21020
Все величины приведены в AWD


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

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

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

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

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

И получаем:

Work Item NameBNWM
1User Login103010038
2Purchase Commodity154015054
3Purchase History2102010
Project Total Mean102
Все величины приведены в AWD, округлены до целых

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

S = (W — B)/6

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

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

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

Work Item NameBNWM
1User Login103010038
2Purchase Commodity154015054
3Purchase History2102010
Project Total Mean102
Project Standard Deviation40.5

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

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

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

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

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

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

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

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

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

Chance of SuccessEffort (AWD)
95 %177
70 %122
50 %98

Если вы сравните со средним значением продолжительности проекта (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.

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

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

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

21 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хорошая статья, спасибо.

Минорное замечание: Мне кажется в Excel-файле автора в разделе «Chance of Success» формулы в клетках R4 и R5 перепутаны местами (точнее коэффициенты в них перепутаны)

не пробовали читать „Software Estimation: Demystifying the Black Art” ? помагает

Занимался оценками проектов несколько лет. Мы использовали следующий подход:

1. Получение базовых пожеланий о проекте от заказчика
2. Построение mind карты требований
3. Написание вопросов (общий, по дизайну, технических и других) заказчику, и получение от него дополнительных данных. Если нужно проведение скайпколов.
4. Систематизация полученных данных
5. Построение mindmap карты проекта
6. Установка взаимосвязей между задачами, и последовательность выполнения задач
7. Выставление сроков по каждой задаче (если нужно консультации с профильными спецами)
8. Учет рисков
9. Построение gantt чарта
10. Формирование Excel таблицы с конкретными часами
11. Выдача полного пакета сейлзам.

Сравнивали разные методы оценок, этот метод давал достаточно высокую точность, до 95%, в том числе и в сравнении, когда проект выполнялся с командой.

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

— сколько стоит разработка?
— какая именно разработка?
— ну нормальная такая разработка.
— ну нормально так стоит.
(к)

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

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

Идея известная (я её использую давно и уже не помню, откуда взял). Но вот конкретные значения пределов вероятности выглядят странно. 95% это чуть меньше чем две сигмы в обе стороны. Почему именно так? Почему не, например, 25-50-75, или 10-50-90?

Я уточню вопрос.
1. Насколько есть уверенность, что описанная математика универсально годится для качественной аппроксимации времени исполнения с учётом иерархии задач? Все числа, похоже, рассчитаны из какой-то фиксированной модели, типа ровно 1 этапа деления на подзадачи.
2. Насколько можно доверять авторам оценок элементарных задач на настолько крайних уровнях вероятности (5, 95%)?

Хорошее начало для цикла статей. Пишите еще)

К гадалке не пробовали сходить?)

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да.
Что-то, что вы можете предоставить вашему сейлз-менеджеру быстро
Для нашего проекта получаем: «Проект займет от 21 до 183 дней».

Так много написано о паре простых вещей. Оценивать должен человек с опытом. Оценивать стоит оптимистичный ход событий и пессимистичный, а клиенту называть стоит средний прогноз, чуть ближе к пессимистичному. В статье не написано об очень важной штуке — оценку нужно сопровождать предположениями assumptions — и чем их больше, тем ближе вы к написанию полного ТЗ, но защититься себя хотя бы простыми штуками нужно. Например, оценка User Login не включает себя 2-factor, sms и SSO авторизацию, только работа с логинами и паролями в БД самого приложения.

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

Однажды одна коллега-пилот, еще только обучаясь, задала вопрос — на каком расстоянии надо задержать штурвал, чтобы создать посадочное положение для самолёта и сесть? Вопрос поставил всех инструкторов и опытных в ступор, потому что нет простого ответа: всё зависит от mass & balance самолёта, скорости, направления и силы ветра, плотности воздуха, превышения аэродрома ....

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

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

Дядя Боб сделал замечательное видео об эффективных оценках.

Оно настолько же замечательное, как замечательны его знания булей?

Cм. func isWin(_ board: BoardState,_ player: Player) -> Bool в github.com/...​/Gomoku/GomokuRules.swift

Более приближенные к реальности примеры есть? User Login от 10 до 100 дней — это выглядит как-то странно.

почему? или вы не видели систем окроме стандартной form authentication, сколько по вашему займет разработка к примеру SSO

Отсюда и начинаются самые интересные истории «в проекте записано user login а на самом деле там sso».

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

Хороший опис методу оцінки по трьох точках. Хороший тим що досить просто написано. Є багато теорії за ним, і нові наукові праці пропонують інші коефіцієнти, але то вже деталі. В нашій компанії всі менеджери проектів мусять знати цей метод, і використовувати його (у трохи іншій варіації) де можливо — оскільки він самий точний, хоч і не швидкий.
Самий швидкий — метод аналогії і експертна оцінка.

Подписаться на комментарии