Как выполнять оценку по трём точкам?

Вам стоит научиться выполнять оценку сроков задач по трём точкам, так как это, безусловно, лучшая техника для оценивания продолжительности работ совместно с участниками вашей проектной команды. Техника называется «оценка по трём точкам» потому, что участники команды дают пессимистичную, оптимистичную и наиболее вероятную оценки сроков завершения работ. Данная техника является одним из лучших подходов, так как позволяет менеджеру проектов достичь следующего:
  1. Повысить точность по сравнению с оценкой по одной точке.
  2. Улучшить обязательства, получаемые от команды, потому что оценка принимает во внимание риски.
  3. Получить полезную информацию о рисках в каждой задаче.


Оценка по трём точкам — это процесс в три шага


  1. Мы работаем с членом команды, который будет выполнять задачу, чтобы определить как позитивные так и негативные риски, связанные с его задачей. Негативные риски — те, что могут увеличить срок выполнения задачи, позитивные — уменьшить.
  2. Затем мы просим члена команды назвать три оценки. Первая — это наиболее вероятная (BG), которая является средней продолжительностью работы над задачей, если работник сделает её 100 раз. Вторая оценка — пессимистичная (P) — продолжительность работы над задачей, если сработают все негативные факторы, которые мы выявили. И наконец мы просим дать оптимистичную оценку (O) в которой учтены все определённые ранее позитивные факторы.
  3. Теперь мы проводим несложные вычисления с тремя полученными оценками. Мы рассчитываем значение и стандартное отклонение, используя формулы для оценки по трем точкам: (O + 4 * BG + P) / 6 = взвешенное значение, а (P-O) / 6 = стандартное отклонение (используемое для вычисления вероятностей). Взвешенное значение по трем оценкам, которые дал нам член команды, это та оценка, которую мы используем для его задачи. Она учитывает риски в задаче и последствия воздействия позитивных и негативных рисков.


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

Когда мы оцениваем по трем точкам, мы записываем все три оценки в соответствующие документы, так же как и позитивные и негативные риски, выявленные для задачи. Мы открыто сообщаем команде и заказчикам проекта, что оценки не на 100% точны. Что существуют риски, которые мы рассмотрели и которые могут повлиять на время выполнения задачи. Такой подход устраняет некоторые сомнения членов команды относительно процесса оценки задач.

Итог


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

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

Автор: Dick Billows
Оригинальная статья: How to do 3-point Estimating
Дополнительные материалы: PERT

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 25

    +1
    Спасибо, возьму на заметку.
    К сожалению у нас не принимают никаких оценок сроков, которые выше дедлайна. Но все равно спасибо.
      +1
      Вместо одной случайной величины берется три, к ним добавляют случайные веса и — вуаля, мы повысили точность. Пассаж про «увеличивает вероятность хороших рисков и уменьшает вероятность плохих» тоже неплох.
        0
        Ну, я бы не назвал оценку даже по одной точке совсем случайной. Зависит от многих факторов — да, но регулярно тренируясь можно достичь неплохих результатов. На счет «к ним добавляют случайные веса» тоже не согласен. Основное, на мой взгляд, в данном подходе то, что мы
        1. Заранее продумываем возможные риски, которые могут возникнуть в ходе работы над задачей.
        2. Привлекаем к оценке риска того, кто будет выполнять задачу, то есть более компетентен, чем менеджер.
        0
        Переводную статью надо бы в категорию «Переводы».
          0
          Согласен, но не могу найти как поместить в «переводы» уже опубликованную статью. Буду признателен, если кто-то подскажет.
          • UFO just landed and posted this here
          +2
          Оценка по трём точкам — это процесс в три шага

          Кто источник этой методики? К ней есть несколько вопросов. Например, оценка BG считается как «среднее время при решении задачи 100 раз». Но часто задачу требуется решить ровно один раз. Как решить творческую задачу 100 раз? Каждый раз время будет разное. Как оценить время выполнения задачи, которую ты никогда не решал?
            0
            Кто источник этой методики?
            Автор описывает упрощенный подход PERT.

            Как решить творческую задачу 100 раз?
            Тут не предлагается решить задачу 100 раз, тут предлагается прикинуть сколько займет времени решение задачи в среднем, если решить её 100 раз. Можно же написать одну и ту же картину сто раз? Вот и надо оценить сколько это займет времени.

            Как оценить время выполнения задачи, которую ты никогда не решал?
            Никак. Но если работаете длительное время в одной и той же области, то накапливается опыт, который позволяет примерно оценить сколько займет та или иная задача.
              +2
              Хорошо, попробуем на примере? Требуется оценить задачу «Сделать авторизацию на сайте через Вконтакте». Как оценить её BG? По методике, я должен представить, что я делаю задачу «Авторизация через ВК» сто раз. Я как честный интерпретатор вычисляю: первый раз я её буду делать хз сколько, примерно 20 часов. Причем 18 из них будет чтение документации, разбор OAuth, поиск подводных граблей и т.д. Второй раз я сделаю эту же задачу за 2 часа. Третий раз за 1.5 часа. Четвертый — за 1.5 часа. Сотый раз — за 1.5 часа. Среднее время выполнения задачи — 1.7 часа. Это и есть оптимальная оценка? На мой взгляд, это хрень какая-то. Где ошибка?

              Здесь есть ещё один забавный нюанс: пока я не сделаю задачу в первый раз, я не смогу сказать, сколько времени займет решение этой задачи в пятый и десятый разы. А пятый и десятый не нужны, нужен только первый.
                0
                Кстати, это красивая иллюстрация того, насколько круче опытный разработчик. Он не только прошёл первый шаг в большом количестве задач (20 часов --> 2 часа), но также может делать аналогии незнакомых задач с ранее сделанными подобными задачами (Авторизация ВК ~~ Авторизация ФБ --> 2-4 часа). И сроки меньше, и оценки точнее.
                  0
                  Хм. Примерно 20 часов, 18 из них на чтение документации — остается 2. Судя по дальнейшим предположениям, на написание кода будет потрачено 1.5 часа. Таким образом, на «разбор OAuth, поиск подводных граблей и т.д.» + проверка работоспособности остается 0.5 часа. Точно всё правильно?

                  Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?
                    0
                    Прошу прощения — неправильно прочитал — первый пункт больше не актуален.
                      0
                      Второй момент: сколько примерно займет времени разработка, если всё пойдет не так? То есть если документация окажется отвратительной и придется общаться с поддержкой для её уточнения (встречалось в моей практике), если OAuth не будет поддаваться разбору и лес подводных граблей окажется особенно густым?
                      Документация может совсем отсутствовать, авторизация может оказаться вовсе не OAuth, а выполняться с помощью микроконтроллера без дата-шитов, код приложения написан на самодельном языке программирования (естественно, без документации), а предыдущие разработчики вымерли чуть раньше мамонтов. Часов миллион, не меньше. Стёб, конечно, но идея ясна.
                        0
                        Тогда, вероятно, данный метод оценивания Вам не подходит.

                        А как Вы проводите оценку задач на своих проектах?
                          0
                          Декомпозиция задач, оценка по аналогии, задачи вида «исследовать задачу», обсуждение с коллегами. Всё сводится к тому, чтобы снизить неопределённость в оценке. Конечно, остаются ещё внешние факторы, которые нельзя изучить заранее, в этом случае как раз подойдёт описанный выше метод. Но по моему опыту, таких факторов в разработке ПО довольно мало, и они скорее организационные, нежели технические.
                      0
                      Возможно тут будет работать такой подход:
                      Разбиваем задачу на две подзадачи — «Разобраться в новой схеме авторизации» и «Реализовать известную схему авторизации». Каждая оценивается отдельно, потом оценки складываются. 1,5 часа будет относиться только ко второй задаче и средняя оценка не исказится.
                        0
                        Часто это единственно возможный выход. Но декомпозировать задачу тоже нужно уметь. Вобщем, опыт рулит.
                  0
                  В изложении метода (кстати, неплохо бы упомянуть, что он происходит из PERT) есть некоторые неточности.

                  Замечание по теории: Пессимистическая и оптимистическая оценка выставляются исходя не из 100% случаев, а из 99%. Это зафиксировано в формуле, где знаменатель 6 — это «три сигма» в обе стороны.

                  Замечание по практике менеджмента: практического смысла спрашивать у исполнителя все три точки нет никакого. Это связано с тем, что обычно исполнитель не понимает, к чему его, например, обязывает вынесение точной оптимистической оценки (и что он получит, если назовет малое число). Реальная практика обычно такая: либо спрашивается «одна» оценка (которая рассматривается, например, как 70% — где-то по середине между BG и P), либо спрашивается две (реалистичная и пессимистичная, которые используются как BG и P). Что же касается оптимистической оценки, то её (как и вообще все корректировки в оптимистичную сторону) может сделать только менеджер или тим-лид, т.е. человек, ответственный за проект в целом и за риски по срокам в частности. Либо её можно принять равной BG, т.е. вообще не учитывать «положительные» риски в планировании.

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

                  P.S. Всё вышенаписанное, конечно, относится к программным проектам (где, в отличии от например строительных, нет устоявшихся нормативов). Как я понял, мы говорим про программные проекты)
                    0
                    Статья, по сути, — это адаптация PERT для начинающих (таких как я, например). Не подскажете, кстати: в оригинале написано «P-O/6 = the standard deviation», правильно ли я понял, что должно быть (P-O)/6 и каков вообще смысл этой величины?
                      0
                      случайно ответил ниже (не в цепочку)
                    +1
                    Я чего-то не понимаю.
                    Мы, артель, в составе трех плотников и одного менеджера, ваяем лодки.
                    Лодка делается за неделю.
                    Если совсем хорошо — за четыре дня.

                    Приходит менеджер, говорит — предпроектный этап, надо посчитать трудозатраты. Вот, министерство обороны предлагает контракт на постройку. Требования — чтобы держалась на воде. и было оснащено флагштоками для гюйса и флага.
                    Я прикидываю. Если все складывается привычно — то трудозатраты — неделя. А вот ТЗ нет, его разработка входит в контракт. И по текущим условиям от нас могут требовать хоть авианосец.
                    Я прикидываю, что нам троим делать авианосец примерно сто лет, и выдал эту оценку вместе с неделей и четырьмя днями менеджеру.
                    Что дальше? И почему он скрипит зубами?
                      0
                      Есть такое понятие, как «предпроектные показатели». Например, договариваетесь о водоизмещении не более 1 м^3 — и у вас заведомо не получится авианосец :)
                      Договоритесь что из дерева и без мотора — и всё станет совсем хорошо) А дальше оценка на основе исторических данных / аналогий, по предпроектным показателям, вполне работает)

                      Обсуждаемая статья в общем-то не про это. Не про оценку проекта, а про cоставление плана проекта, когда цель более-менее ясна. Хотя бы цель текущей итерации.

                      0
                      Подскажу (благо 'матмех finished'...)
                      Вот картинка «нормального распределения» (представьте, что по оси X — срок, за который будет выполнен план целиком, а по оси Y — вероятность такого исхода):
                      image
                      Естественно распределение вероятных сроков по одной конкретной задаче — не такое, однако в статистике есть теорема, согласно которой сумма множества случайных величин (одного порядка) стремится к нормальному распределению.

                      Вот на графике: точка, которая помечена «Mean» — это ваш BG (Best Guess), т.е. оценка которая выполнится (или не выполнится) с вероятностью 50%. Точка "-3 sd" — это O, а "+3 sd" — это P. Cам же sd — это среднеквадратичное отклонение от мат.ожидания (показан на графике полоской).

                      Формула (1O + 4BG + 1P)/6 призвана дать гипотезу о средне-арифметическом сроке выполнения одной задачи (это не то же самое, что оценка 50%). В методе PERT вы потом складываете Mean всех задач по критическому пути проекта, и прибавляете к ним корень из суммы квадратов SD по тому же пути, умноженный скажем на 3 — и получаете 99% дидлайн общего срока выполнения.

                      Понятно, что это всё теория, которая применима ограничено (например, если все риски по всем задачам выстрелят одновременно, вы улетите далеко за вычисленный по PERT план). Но сама практика учета рисков отдельно от «ожидаемых» сроков всё же улучшает планирование, так что можно и PERT считать :)
                        0
                        Давайте я немного проясню, откуда именно, на мой взгляд, берутся коэффициенты 1, 4, 1, и что значит словосочетание «по трём точкам».
                        Будем считать, что вероятность не попасть в границы оптимистичной и пессимистичной оценок равна нулю, а так же, что с вероятностью 50% мы выполним оценку Best Guess. Тогда наша случайная величина (потраченное время) ограничена. Для такой случайной величины можно предложить следующий способ подсчёта математического ожидания: это интеграл от нуля до единицы квантили распределения.
                        Квантиль уровня альфа это значение случайной величины, которое ограничивает её с вероятностью ровно альфа.
                        Согласно нашим предположениям, мы знаем всего лишь три значения этой квантили, обозначу её за Q(x):
                        Q(0) = P
                        Q(1/2) = BG
                        Q(1) = O
                        Для подсчёта интеграла проведем интерполяционный многочлен через эти три точки (параболу) и проинтегрируем его. Получим формулу Симпсона, дающую указанные коэффициенты.

                        Отличие от комментария выше в том, что нормальность распределения не нужна, нужно только предположение о том, что BG это 50%, а оценки O и P действительно оптимистична и пессимистична.
                        0

                        Only users with full accounts can post comments. Log in, please.