Posts tagged оценка

Воздушная атака на неопределнность оценок

0

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

Вот что по этому поводу советует из своего опыта руководитель проектов Киевстар Евгений Петров:

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

Что сделали:
1) Разделили мигрируемые данные на 3 категории (простой, средний, сложный);
2) Провели пилот. Несколько специалистов проводили миграцию разной сложности контента, скажем по 2 единицы каждой сложности. Данные усреднили по исполнителям. Получились оценки длительности миграции каждого типа сложности контента. Например Простой 1 день, средний – 2, Сложный – 5 дней.
3) Умножив оценку на количество, получили общий объем трудозатрат
4) Назначаем ресурсы, получаем длительность
5) Закладываем резерв после оценки рисков:
- переменная загрузка специалистов
- больничные
- инструменты миграции могут сбоить
- и т.д.
6) Коммуницируем спонсору и заказчику риски, договариваемся, что будем делать в случае их наступления
7) Начинаем работать!”

Из своего опыта работы по аналогичному сценарий могу добавить что после пункта (2) был сделан вывод что мы можем рассмотреть варианты

  • Отправить задачу на outsource менее квалифицированным ресурсам (смогли найти в части задач ресурсы, провели обучения и задача была выполнена)
  • Купить инструмент для миграции (рассмотрели, оказалось очень дорого по сравнению с бюджетом всего проекта)
  • Написать инструмент для миграции которые делает ее полностью автоматически или существенно облегчает ряд рутинных операций (разработали несколько утилит которые сократили на четверть время и отбили с лихвой время потраченное на их разработку)

Хорошо управляемый объем работ

0

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

Если мы определим в структуре работ много элементов с объемом в 4-6 часов которые будут включать по несколько задач на час-два – мы упремся в микроменеджмент. И он похоронит руководителя проекта и проект вместе с ним.

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

Оптимальным являются элементы работ которые содержат около 5 задач (плюс-минус 1-2), в среднем по 6-12 часов каждая. То есть задачи на выполнение которых надо 1-2 дня. Т.е. от 30 до 100 часов.

Про правильное измерение прогресса проекта

0

The measures of progress using the passage of time and the consumption of resources is simply Bad Management.

Herding Cats

Погадаем?

0

Очень интересный метод оценки кусков работы (историй, вариантов использования, задач) предлагается в Mike Cohn про “Agile Estimating and Planning”. Метод решает проблему когда кто-то один дает оценку и все без обсуждения ее принимают (это часто может быть авторитет).

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

Подробнее о методе:

Неправильные 8 часов в день

0

По умолчанию доступность ресурса участника проекта в день 8 часов. Однако можем ли мы оставить данную оценку по умолчанию? Я думаю нет. И тому есть ряд причин.

Эффективная сосредоточенная работа среднего офисного специалиста – за вычетом рабочих совещаний, звоноков телефона, прочтения почты, шуток коллег, отвлечений в Интернете, после обеденной дремы – я не думаю что превыщает 4 часа. Можно накинуть максимум 2 часа на “тупую” работу за чашкой кофе + в наушнкиках после обеда. Все.

Далее надо по любому оставлять время сотруднику на выполнение его операционных задач – это еще минус час. Возможно он участвует еще в одном проекте – не забудьте правильно распределить нагрузку на члена проекта и согласовать ее с другим менеджером проекта и его начальником.

Следовательно что правильно сделать – заложить во все ресурсы что у них есть в проекте НЕ БОЛЕЕ 6 ЧАСОВ В ДЕНЬ. И это в идеале – когда нет другой операционной работы и других проектов.

Т.е. закладываю 8 часов в день мы себя обманываем на 30% минимум!

Пример EVA анализа

0

Давайте на примере абстрактного проекта проведем EVA анализ.

Исходные данные проекта: 4 месяца длительность, бюджет 100`000 грн. Менеджер проекта отчитывается на конец 3-го месяца проекта. Потрачено 85`000 грн., сделано 50% объема работ. Для упрощения считаем что объем работ был запланирован равномерно – на конец третьего месяца должно было быть выполнено 75% объема работ.

PV (Planned Value, сколько мы планировали выполнить объема работ) = Запланированный процент выполнения x Бюджет проекта = 75% х 100`000 = 75`000 грн.

EV (Earned Value, что фактически сделали, по исходному плану проекта) = Актуальный процент выполнения x Бюджет проекта = 50% х 100`000 = 50`000 грн.

AC (Actual Cost, сколько фактически потратили) = 85`000 грн.

CV (Cost Variance, отклонение по стоимости) = EV- AC = 50`000 – 85`000 = -35`000 грн.

SV (Shedule Variance, отклонение по графику) = EV – PV = 50`000 – 75`000 = -25`000 грн.

После того как мыс посчитали абсолютные отклонения рассчитаем индексы для стоимости (CPI) и графика (SPI) соответственно.

CPI (Cost Performance Index) = EV/AC = 50`000 / 85`000 = 0,59

SPI (Schedule Performance Index) = EV/PV = 50`000 / 75`000 = 0,66

А теперь давайте оценим что нам “светит” в конце проекта

EAC (Estimate at Completion) =  BAC (Budget at Completion, исходный бюджет проект) / CPI = 100`000 / 0,59 = 169,5

А вот и весь EVA анализ в простом виде!

Как часто воспринимается оценка начинающими менеджерами проектов

0

Менеджер проекта приходит к сотруднику и спрашивает – сколько времени у тебя уйдет на эту задачу. Сотрудник отвечает – 5 дней (часто 5-10-15 – бывалые сотрудники любят мыслить неделями, округляя задачу). Менеджер проекта говорит “ok”, делает пометочку и уходит. Через 5 дней он спрашивает сотрудника о задаче и может услышать чащего все в ответ

  • Задачу не начинал – были другие приоритетные вопросы
  • Задача готова на 90% но еще нужно пару дней
  • Ну еще пять дней (без оценки готовности, или где-то половину сделал)
  • Задачу сделал 3 дня назад (реже всего – но тоже нечему радоваться – в плане провисло 3 свободных дня)

Какую ошибку допустил менеджер проекта? Возможные варианты – что менеджер проекта не уточнил, что не спросил:

  • 5 дней – это длительность или объем работ
  • это оптимистическая, пессимистическая или некая средняя оценка? это оценка на основе ранее сделанных замеров?
  • что может пойти не так при выполнении задачи, какая вероятность этого, как это повлияет на объем работ задачи
  • не согласовал выделение нужного ресурса времени с руководителем данного сотрудника
  • какова текущая загрузка
  • это операционная или проектная задача
  • делал ли такую задачу ранее сотрудник, насколько хорошо он умеет решать подобные задачи, какие ранее были оценки времени и за сколько реально сделали
  • интересная ли ему такая задача? насколько он внутренне мотивирован ее выполнять
  • чем можно помочь сотруднику в выполнении поставленной задачи (обеспечить более лучшим компьютером, поставить ПО, снять с него пару рутинных задач по операционной деятельности и т.п.)

Кроме оценки следует обратить внимание на следующие моменты:

  • проговорить еще раз требования к результату и попросить сотрудника своими словами повторить это, выслать ему это письменно
  • тем или иным способом зафиксировать время и назначение по задаче – то ли в плане проекта, то ли в списке задач, то ли письмом.

В процессе выполнения задачи периодически надо:

  • Уточнять статус выполнения задачи
  • Идентифицировать возможные проблемы с ее выполнением (технические, организационные)
  • Пытаться посмотреть на промежуточный результат

Осторожно – fixed price

0

Стоит обратить внимамние на статью в блоге Дениса Журавлева “Fixed-price со скрытым конфликтом” – http://pm.by/toc/fixed-price-so-skrytym-konfliktom/. В статье озвучена проблема в проектах где зафиксирована цена. Решение не предложено. Какие ваши соображения?

Go to Top