#метод 12

== Ритм внедрения улучшений ==

Мероприятия ритма улучшений задают дисциплину непрерывных улучшений в организации. Мероприятия в этом ритме должны быть синхронизированы с ритмами стратегирования и планирования, так как охватывают разные периоды для анализа.
Мероприятие по анализу прошлого опыта и выработке плана улучшений называется “Ретроспектива”

Цикл описания базовых инструментов Метода завершен.
Далее на канале: Правила

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

то есть, пойдет пратическая часть "бери и делай"

#метод

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

=== Принципы планирования ===

1. Всякая работа займёт ровно столько времени сколько на неё отведено или больше. (Закон Паркинсона).
2. Люди откладывают всякую работу на последний момент времени. (Синдром студента).
3. Люди склонны давать оптимистичные прогнозы относительно трудоёмкости небольших работ. Исключая случаи когда их лишали премии за нарушение оценок, в этих случаях оценка пессимистичная и завышенная.
4. Люди дают пессимистичные прогнозы относительно трудоёмкости больших работ. Потому, что хотят успеть «наверняка» и провести «победоносную войну».
5. Люди никогда не начинают работу именно в то время, когда работа запланирована и никогда не заканчивают выполнение задачи вовремя.
6. Все проекты связаны с неопределенностью. (Закон Мёрфи — если что-то может пойти не так, именно это и произойдёт. Мы никогда не знаем, когда закон Мёрфи себя проявит).
7. Реальность никогда не будет соответствовать плану. Как бы хорошо мы не планировали наш план не будет охватывать всё.
8. Объем работы по проекту не постоянен.
9. Люди никогда не делают ровно то, что написано в техническом задании. Они делают больше или меньше или другим способом.
10. Люди могут эффективно выполнять только одну задачу в один момент времени.

#метод 14

=== Два уровня планирования ===
Исходя из принципов планирования и внешних обязательств Организации необходимо применять два уровня планирования:

* Первый уровень - стратегическое планирование, крупноблочное планирование проектов на основе Правил планирования проектов.
* Второй уровень - тактическое планирование спринтов и определение коротких целей.

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

Уровень планирования проектов обеспечивает планирование очередности выполнения работ Организацией, задает понятные фокусирующие цели и обеспечивает контроль исполнения обязательств. Уровень тактического планирования спринтов обеспечивает короткие и понятные цели для сотрудников реализующих проект и учитывает высокую неопределенность способа реализации.

=== Планирование это процесс ===

Планирование, как процесс, не должен ограничиваться сессиями в формате “сделал и забыл”. Это процесс требующий столько же усилий, как и проектирование Продукта. Планирование и выбор приоритетов будущих работ должно происходить в то время, пока текущие работы еще не завершены. Планированием можно заниматься только выйдя из "создающего потока" - Потока Реализации в Поток Управления.

Правила:
1. Планирование будущих проектов и развития Продуктов выполняется регулярно.
2. Сессии планирования “вшиты” в рабочий процесс.
3. В планировании может принять участие любой сотрудник если видит в нем свою пользу.
4. Совещания по планированию собираются регулярно для синхронизации всех планов и видения решений.

#метод 16
=== Планирование проектов ===

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

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

#метод 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 - Количество дней задержки проекта