#метод 17
=== Стратегия планирования проектов ===

При планировании выполнения проектов следует учитывать несколько факторов:
1. Длительность проекта
2. Прямая прибыль от реализованного проекта.
3. Косвенная прибыль от реализованного проекта, или сумма изменения дохода компании за 12 месяцев при внедрении продукта созданного в рамках проекта. Экономия ресурсов на выполнении работы - тоже прибыль Организации.
4. Стоимость задержки поставки результата в обещанный срок.
5. Возможность получения прибыли от разрабатываемого Продукта до завершения всего проекта по созданию Продукта.
Исходя из этих факторов необходимо выбрать стратегию реализации всего портфеля проектов.

Варианты стратегий:
1. Все ресурсы организации фокусируются на одном прибыльном проекте для сокращения времени его исполнения.
2. Проекты каскадируются (выравниваются) по ресурсу-ограничению.

#метод 18

==== Стратегия фокуса на одном проекте ====

Фокус на одном проекте обеспечивает высокий уровень взаимодействия всех участников проекта и взаимопомощь. Даже, когда сотрудник не занят никакой работой он может помогать другим её выполнять. За счёт этого сокращается время выполнения проекта.
Минусы такого подхода в том, что создаётся иллюзия “простоя ресурсов”. Особенно когда некоторые ресурсы нужны только вначале проекта, а потом не требуются. Но это тоже иллюзия. Например:

1. В ИТ-проекте есть фазы: анализ, разработка, тестирование. Анализ выполняют аналитики, разработку - разработчики, тестирование - тестировщики. Если вся работа по анализу выполнена вначале проекта, то есть иллюзия, что аналитики будет простаивать. Но на самом деле, они постоянно требуются для разъяснения требований в Изделию или их уточнения. Конечно не в полном объёме, но требуются.

2. В строительном проекте на фазе “реализация” есть “авторский надзор” от проектировщиков сооружения. То есть регулярная проверка соответствия результата техническому заданию и проектной документации.

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

#метод 18
Последовательное выполнение проектов

На рисунке: проекты А, Б, В, Г выполняются последовательно. Зелёный ресурс - ограничение вынужден ждать пока отработает красный и голубой ресурс.

#метод 19

==== Стратегия выравнивания по ресурсу-ограничению ====

Ресурс-ограничение - ресурс Организации, конкретный сотрудник или команда, или материальный ресурс ограничивающий способность Организации зарабатывать деньги.

Стратегия выравнивания по ресурсу-ограничению позволяет сократить время выполнения всех проектов. За счёт такого планирования, самый дорогой ресурс Организации будет работать со 100% занятостью.


Помните: стоимость времени ресурса-ограничения - это доход Организации за этот период.
Минусы этого подхода в том, что проекты Б, В, Г имеют высокую неопределённость срока начала проекта. Это происходит из-за того, что мы не знаем точно «когда завершит работу ресурс-ограничение».

#метод 19
На рисунке: проекты А, Б, В, Г выровнены по зелёному ресурсу - ограничению. Этот ресурс - ограничение потому, что выполняет больше всего работы в этом наборе проектов. При таком планировании, важно чтобы к началу работы зелёного ресурса всё, что нужно для выполнений работы, было подгтовленно максимально качественно.

#метод 20

=== Правила построения расписания проектов ===
1. Проекты обеспечивающие начало получения прибыли от Продукта до завершения проекта разбиваются на несколько отдельных проектов со своими финансовыми показателями и объединить их в Программу проектов. В этом случае, все проекты имеют единые критерии для оценки.
2. Все проекты имеют единые критерии для оценки и выставления приоритета.
3. Все задачи в каждом проекте выровнены по ресурсам. В расписании каждого проекта отсутствует многозадачность. Самая длинная цепочка работ называется - критическая цепь.
4. При построении расписания проекта учитывается только оптимистичная оценка длительности задач.
5. Каждый проект имеет резерв времени не менее 50% оптимистичной длительности проекта или критической цепи для защиты от непредвиденных рисков. Резерв времени называется - Буфер Расписания

(продолжение следует)

#метод 20

#метод 21
(продолжение)

6. Каждая задача имеет две оценки длительности: оптимистичную и пессимистичную. Для более точного определения размера Буфера Расписания
6.1. Оптимистичная оценка - оценка с вероятностью завершения в срок 50%,
6.2. Пессимистичная оценка - оценка с вероятностью завершения в срок 90%. Другими словами - в случае, если возникнут проблемы.
6.3. Размер буфера расписания может быть увеличен, если суммарная разница оптимистичной и пессимистичной оценки больше 50% цели. В этом случае размер буфера расписания равен полученной суммарной разнице.

Пример:

Суммарная оптимистичная оценка длительности = 100 дней, 
Суммарная пессимистичная оценка длительности = 200 дней, 

50% длительности проекта (критической цепи) = 50 дней.

Разница между оценками = 100 дней. Это больше чем 50% длительности проекта(цели)

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


7. Очерёдность начала проектов определяется едиными правилами и выбранной стратегией. Стратегия планирования - единая на всю Организацию.
8. При каскадировании проектов, ресурс-ограничение следующего проекта защищается «буфером доступности» ресурса. Это необходимо для того, чтобы работа по проекту на ресурсе-ограничении началась точно в срок. Буфер доступности ресурса вычисляется по тем же правилам как и буфер критической цепи, учётом того что цепь - вся цепочка работ по всем проектам перед ресурсом-ограничением.
9. Срок начала проекта выбирается так, чтобы не разрывался контекст проекта. Для работ выполняющихся перед ресурсом-ограничением, следует начинать задачи, как можно позже но так, чтобы завершить их до того, как начнет работу ресурс-ограничение.

#метод 21

На рисунке, фиолетовый - буфер доступности ресурса-ограничения, буфер после А - включает только работы проекта, буфер после проекта Б включает работы проектов А, Б и так далее. При отсутствии буфера доступности ресурса - буфер проекта не сможет защитить проект от отставания из-за задержки предыдущего проекта.

#метод 21
(продолжение)

10. Расписание проекта строится только для крупных работ с длительностью не менее, чем 2% от длительности проекта. Простым планом проще управлять, чем сложным.
11. Структура работ проекта включает все работы которые необходимы, с той детализацией которой нужно.
12. Расписание проекта строится «обратным проходом» начиная с конечной цели проекта - ввод Продукта в эксплуатацию или получение денег от Заказчика. В этом случае, вы не пропустите никаких важных шагов.

#ответы_на_вопросы

= В каких единицах оценивать задачи? =

Если не учитывать сам способ оценки, кои рассмотрены в PMBoK , с фокусироваться на самих единицах то есть несколько вариантов:

1. Оценка длительности задачи в днях - никогда не точная, но её всегда хотят услышать. Отвечает на вопрос: "Сколько времени примерно займет выполнение работы по достижению цели указанной в задаче приданными ресурсами?".

Плюсы: всегда можно сравнить: сколько времени уже прошло и сколько планировали потратить. Если итог не понравился то можно или включить обвинение "Ну вот, обещал и не сделал" или устранить причины "Что мешает завершить прямо сейчас? "

Минусы: иллюзия что всё под контролем.

2. Оценка трудозатрат в человеко-днях(часах). Отвечает на вопрос: "Сколько человеко-часов (человеко-дней) нужно потратить на достижение указанной в задаче цели?". Иными словами, этот показатель напрямую конвертируется в оценку стоимости работ. Длительность у задачи может быть 5 дней, а вот трудозатраты могут быть 20 человеко-дней. То есть на задаче может быть задействовано 4 человека. Как правило это оценка присуща для пакетов работ: "эту пользовательскую историю наша команда из 5 человек реализует за неделю" , внутри "история" может дробиться на задачи реализации.

Плюсы: мы можем конвертировать оценку в ожидаемые прямые затраты и отслеживать инвестиции.

Минусы: оценка все-равно не точная, но есть иллюзия контроля. И если не предпринимать мер по реальному контролю (типа метода освоенного объема) это остается иллюзией.

3. Оценка в размерах работы. Отвечает на вопрос: "Насколько одна работа больше другой?", то есть тут вообще дней никаких нету. Но зато можно мерять работу в метрах (Уложить 1000 метров кабеля), в квадратных метрах (Мне нужно уложить 5 кв.м плитки), в кубических метрах (Разгрузить 5 кубометров дров), или в просто в пунктах (Это сложная работа на 5 пунктов)

Минусы: (1). Это очень не линейный параметр. Разница между размером 4 и 5 работы, совсем не 1 размер работы, это может быть и 3 размера. Например привезти 5 кубометра дров - 1 камаз, а 6 кубометров -уже 2 камаза, то есть в 2 раза дороже. Для интеллектуальной работы тоже самое, там расхождение оценок размера в 2 раза может привести к 4 кратной разнице в трудозатратах и/или времени выполнения. (2) Нельзя использовать для для рычага: " мы оценили задачу в 2 единицы, а уже прошло 4 дня" - и что? Единицы размера работы не пересчитываются в дни никак. Можно вывести коэффициент для прогноза, но он будет не точный.

Плюсы: очень быстрая оценка (буквально "больше или меньше"), очень неточная оценка поэтому иллюзии контроля ситуации нет.

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

Важно: Для интеллектуальной работы, оценка в относительных размерах должна строиться на основе самой маленькой задачи у которой размер = 1. То есть это именно "размер" задачи, или уровень сложности. (ага, на 1 уровень у нас 1 монстр на минуту игры , а на уровне 2 - 10 монстров)

== Какой же подход выбрать? ==

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

Как выбрать: (алгоритм)
1. Хотите рычаг для ускорения работы? - оценка длительности в днях
2. Хотите прогноз затрат и если в задачах вовлечено больше одного исполнителя? - оценка в трудозатратах
3. Хотите просто видеть прогноз срока завершения? - оценка в размерах.
4. Хотите по быстрому оценить работу? - оценка в размерах.

#метод 22

=== Алгоритм построения расписания проекта ===

1. Определите конечную цель проекта, как свершившийся факт. (Чем проект завершается?)
2. Определите препятствия, мешающие достигнуть этой цели. (Что мешает достигнуть этой цели?)
3. Для каждого препятствия выпишите цель, которую нужно достигнуть для преодоления этого препятствия.
4. Если вы не видите препятствий, определите шаг - предшествующий цели. (Что должно быть сделано , перед тем как мы достигнем цели? А что ещё?)
5. Повторите пункты 2-4 до тех пор, пока не дойдёте до текущего состояния.


Пример:
1. Цель (Чем завершается проект?): У нас запущен сервис заказа такси.
2. Препятствие (Что мешает достигнуть цели?): Мы не договоримся с таксопарками
3. Новая цель (Какая цель чтобы преодолеть препятствие?): Мы договорились таксопарками
4. Шаг (Что сделать перед этим?): Получить список таксопарков в регионе.
5. (повторяем)

#метод 23

== Правила приоритизации проектов ==

Для достижения максимальной продуктивности сотрудников при работе над проектом, в один момент времени ресурс (сотрудник или команда проекта) должен работать над одним проектом. Но необходимо выбрать, над каким именно проектом они должны работать.
Определение стратегии установки приоритета определяется исключительно Организацией, но Метод рекомендует одну из трех:
1. Приоритет на основе Прохода
2. Приоритет на основе Деньго-Дня-Прохода
3. Приоритет на основе потребления Буфера расписания

=== Приоритет на основе Прохода ===

Проход (Throughput) - скорость генерации дохода. Вся прямая и косвенная прибыль полученная после реализации проекта делённая на длительность проекта.

T  =  ΔV  / Δt

ΔV - Изменение дохода компании - вся прямая и косвенная прибыль от реализации проекта

Δt - Длительность проекта

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

#метод 24

=== Приоритет на основе Деньго-Дня-Прохода ===

Деньго-День-Прохода (Throughput-Dollar-Day) - показатель, сколько денег Организация не заработает в сценарии, что при задержке проекта Организация не сможет взять новый проект с такими же показателями прямого и косвенного дохода.

#метод 24 (продолжение)

ΔV - Вся прямая и косвенная прибыль от реализации проекта

Δd - Количество дней задержки проекта

#метод 24 (продолжение)

Пример: Реализация проекта принесёт прямого дохода 100.000 и косвенного 500.000 за счёт повышения репутации новых контрактов. И проект отстаёт на 2 дня. Таким образом:

(100.000+500.000) * 2 = 1.200.0000

Если мы имеем другой проект, который принесёт прямой доход: 200.000 и не имеет косвенного дохода, и он отстаёт на 5 дней то:

(200.000+0) * 5 = 1.000.0000

Показатель TDD второго проекта будет ниже.

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

#метод 25

=== Приоритет на основе потребления буфера расписания ===

Индикатор потребления буфера показывает степень отставания проекта от сроков завершения проекта с 50% вероятностью. В случае если проекты имеют примерно одинаковый Проход и длительность, то правила приоритета должны быть следующие (в порядке применения):
1. Если есть проекты в красной зоне: приоритет у проекта из красной зоны, у которого прогресс выше.
2. Если есть проекты в жёлтой зоне: Приоритет у проекта из жёлтой зоны.
3. Приоритет у проекта у которого прогресс выше.

Примечание 1: В таком подходе, может показаться что вы постоянно “тушите пожары” бросая ресурсы на проекты в красной зоне. Однако, в процессе изменения подхода, вы начнёте планировать запуск нового проекта позже и выполнять его быстрее. В идеальном случае, в работе должен находиться только один проект на ресурс.

Примечание 2: Вы можете выработать собственные правила приоритизации проектов с учётом потребления буфера и прогресса проекта.

#метод 25 (продолжение)

Пример: на рисунке, приоритет проектов:
1. Проект B - потому что в красной зоне
2. Проект C - потому что в жёлтой зоне
3. Проект A

#метод 26

== Планирование спринтов ==
=== Правила планирования задач ===

1. Для каждой задачи НЕ может быть задан срок начала и конца завершения задачи. Это приводит к микроменеджменту и не имеет смысла, так, как нарушение сроков предыдущей задачи, сразу делает неактуальными сроки текущей.
2. Задача может быть оценена в идеальных человеко-днях. Где «идеальный человеко-день» это максимально продуктивный день, когда никто и ничто не отвлекает исполнителя от основного занятия.
3. При оценке задачи задаются оптимистичные и пессимистичные оценки длительности выполнения.
4. Сроки могут быть заданы только для проектов.
5. В объем проекта выполняемого уже заложен буфер расписания и буфер содержания.
6. Все задачи выполняются исполнителем последовательно и не могут быть остановлены.

Примечание:
При оценке задачи в “единицах сложности” - у вас не будет аргументации в случае если время выполнения задачи превысит ожидаемое. Ибо нельзя сравнивать “попугаев” с днями.

=== Правила планирования спринта ===

Спринт, итерация – минимальный квант времени (ритм) контроля выполнения проекта, синхронизации проектов и поставки результата. Планирование спринта - это планирование работ каждой команды в спринте и определение коротких, тактических, целей.
При планировании объёма работ в спринте необходимо решить несколько задач:
1. Определить, какие именно задачи необходимо делать
2. Определить, сколько задач сможет сделать команда за спринт.
3. Определить общую, понятную цель которую должна достигнуть команда в рамках спринта.

#дао_agile

Планирование загрузки ресурсов

Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.

==
§ 11
Тридцать спиц собираются в одной втулке, но использование повозки зависит от пустоты между ними. Форму и глину применяют при изготовлении сосуда, но использование сосуда зависит от пустоты внутри. Делают дверные проемы и створки дверей, чтобы построить помещение, но использование помещения зависит от внутреннего пространства. Получается, что оплачивают то, что есть, пользуются же тем, чего нет.
==

В применении к ИТ-проектам означает: Мы не должны планировать рабочее время инженера на 100%, и должны учитывать его свободное время. Эти пустоты дадут возможность Инженеру самому решить как улучшить Продукт с инженерной точки зрения. И этим мы сэкономим время проекта. Хороший инженер создает Продукт только тогда, когда ничего не делает руками. Инженер оценивая трудозатраты на выполнение работы, оценивает лишь то время, которое он планирует потратить на работу руками. но очень сложно оценить то время, когда он не должен работать руками.