#метод 19
На рисунке: проекты А, Б, В, Г выровнены по зелёному ресурсу - ограничению. Этот ресурс - ограничение потому, что выполняет больше всего работы в этом наборе проектов. При таком планировании, важно чтобы к началу работы зелёного ресурса всё, что нужно для выполнений работы, было подгтовленно максимально качественно.
На рисунке: проекты А, Б, В, Г выровнены по зелёному ресурсу - ограничению. Этот ресурс - ограничение потому, что выполняет больше всего работы в этом наборе проектов. При таком планировании, важно чтобы к началу работы зелёного ресурса всё, что нужно для выполнений работы, было подгтовленно максимально качественно.
#метод 20
=== Правила построения расписания проектов ===
1. Проекты обеспечивающие начало получения прибыли от Продукта до завершения проекта разбиваются на несколько отдельных проектов со своими финансовыми показателями и объединить их в Программу проектов. В этом случае, все проекты имеют единые критерии для оценки.
2. Все проекты имеют единые критерии для оценки и выставления приоритета.
3. Все задачи в каждом проекте выровнены по ресурсам. В расписании каждого проекта отсутствует многозадачность. Самая длинная цепочка работ называется - критическая цепь.
4. При построении расписания проекта учитывается только оптимистичная оценка длительности задач.
5. Каждый проект имеет резерв времени не менее 50% оптимистичной длительности проекта или критической цепи для защиты от непредвиденных рисков. Резерв времени называется - Буфер Расписания
(продолжение следует)
=== Правила построения расписания проектов ===
1. Проекты обеспечивающие начало получения прибыли от Продукта до завершения проекта разбиваются на несколько отдельных проектов со своими финансовыми показателями и объединить их в Программу проектов. В этом случае, все проекты имеют единые критерии для оценки.
2. Все проекты имеют единые критерии для оценки и выставления приоритета.
3. Все задачи в каждом проекте выровнены по ресурсам. В расписании каждого проекта отсутствует многозадачность. Самая длинная цепочка работ называется - критическая цепь.
4. При построении расписания проекта учитывается только оптимистичная оценка длительности задач.
5. Каждый проект имеет резерв времени не менее 50% оптимистичной длительности проекта или критической цепи для защиты от непредвиденных рисков. Резерв времени называется - Буфер Расписания
(продолжение следует)
#метод 21
(продолжение)
6. Каждая задача имеет две оценки длительности: оптимистичную и пессимистичную. Для более точного определения размера Буфера Расписания
6.1. Оптимистичная оценка - оценка с вероятностью завершения в срок 50%,
6.2. Пессимистичная оценка - оценка с вероятностью завершения в срок 90%. Другими словами - в случае, если возникнут проблемы.
6.3. Размер буфера расписания может быть увеличен, если суммарная разница оптимистичной и пессимистичной оценки больше 50% цели. В этом случае размер буфера расписания равен полученной суммарной разнице.
Пример:
7. Очерёдность начала проектов определяется едиными правилами и выбранной стратегией. Стратегия планирования - единая на всю Организацию.
8. При каскадировании проектов, ресурс-ограничение следующего проекта защищается «буфером доступности» ресурса. Это необходимо для того, чтобы работа по проекту на ресурсе-ограничении началась точно в срок. Буфер доступности ресурса вычисляется по тем же правилам как и буфер критической цепи, учётом того что цепь - вся цепочка работ по всем проектам перед ресурсом-ограничением.
9. Срок начала проекта выбирается так, чтобы не разрывался контекст проекта. Для работ выполняющихся перед ресурсом-ограничением, следует начинать задачи, как можно позже но так, чтобы завершить их до того, как начнет работу ресурс-ограничение.
(продолжение)
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. Расписание проекта строится «обратным проходом» начиная с конечной цели проекта - ввод Продукта в эксплуатацию или получение денег от Заказчика. В этом случае, вы не пропустите никаких важных шагов.
(продолжение)
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. Хотите по быстрому оценить работу? - оценка в размерах.
= В каких единицах оценивать задачи? =
Если не учитывать сам способ оценки, кои рассмотрены в 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. Повторите пункты 2-4 до тех пор, пока не дойдёте до текущего состояния.
Пример:
1. Цель (Чем завершается проект?): У нас запущен сервис заказа такси.
2. Препятствие (Что мешает достигнуть цели?): Мы не договоримся с таксопарками
3. Новая цель (Какая цель чтобы преодолеть препятствие?): Мы договорились таксопарками
4. Шаг (Что сделать перед этим?): Получить список таксопарков в регионе.
5. (повторяем)#метод 23
== Правила приоритизации проектов ==
Для достижения максимальной продуктивности сотрудников при работе над проектом, в один момент времени ресурс (сотрудник или команда проекта) должен работать над одним проектом. Но необходимо выбрать, над каким именно проектом они должны работать.
Определение стратегии установки приоритета определяется исключительно Организацией, но Метод рекомендует одну из трех:
1. Приоритет на основе Прохода
2. Приоритет на основе Деньго-Дня-Прохода
3. Приоритет на основе потребления Буфера расписания
=== Приоритет на основе Прохода ===
Проход (Throughput) - скорость генерации дохода. Вся прямая и косвенная прибыль полученная после реализации проекта делённая на длительность проекта.
1. При определение приоритета проекта в первую очередь необходимо выполнять проект имеющий выше показатель Прохода.
== Правила приоритизации проектов ==
Для достижения максимальной продуктивности сотрудников при работе над проектом, в один момент времени ресурс (сотрудник или команда проекта) должен работать над одним проектом. Но необходимо выбрать, над каким именно проектом они должны работать.
Определение стратегии установки приоритета определяется исключительно Организацией, но Метод рекомендует одну из трех:
1. Приоритет на основе Прохода
2. Приоритет на основе Деньго-Дня-Прохода
3. Приоритет на основе потребления Буфера расписания
=== Приоритет на основе Прохода ===
Проход (Throughput) - скорость генерации дохода. Вся прямая и косвенная прибыль полученная после реализации проекта делённая на длительность проекта.
T = ΔV / ΔtПравило приоритета:
ΔV - Изменение дохода компании - вся прямая и косвенная прибыль от реализации проекта
Δt - Длительность проекта
1. При определение приоритета проекта в первую очередь необходимо выполнять проект имеющий выше показатель Прохода.
#метод 24
=== Приоритет на основе Деньго-Дня-Прохода ===
Деньго-День-Прохода (Throughput-Dollar-Day) - показатель, сколько денег Организация не заработает в сценарии, что при задержке проекта Организация не сможет взять новый проект с такими же показателями прямого и косвенного дохода.
=== Приоритет на основе Деньго-Дня-Прохода ===
Деньго-День-Прохода (Throughput-Dollar-Day) - показатель, сколько денег Организация не заработает в сценарии, что при задержке проекта Организация не сможет взять новый проект с такими же показателями прямого и косвенного дохода.
#метод 24 (продолжение)
ΔV - Вся прямая и косвенная прибыль от реализации проекта
Δd - Количество дней задержки проекта
Δ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, так как ценность для просрочки выше.
Пример: Реализация проекта принесёт прямого дохода 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: Вы можете выработать собственные правила приоритизации проектов с учётом потребления буфера и прогресса проекта.
=== Приоритет на основе потребления буфера расписания ===
Индикатор потребления буфера показывает степень отставания проекта от сроков завершения проекта с 50% вероятностью. В случае если проекты имеют примерно одинаковый Проход и длительность, то правила приоритета должны быть следующие (в порядке применения):
1. Если есть проекты в красной зоне: приоритет у проекта из красной зоны, у которого прогресс выше.
2. Если есть проекты в жёлтой зоне: Приоритет у проекта из жёлтой зоны.
3. Приоритет у проекта у которого прогресс выше.
Примечание 1: В таком подходе, может показаться что вы постоянно “тушите пожары” бросая ресурсы на проекты в красной зоне. Однако, в процессе изменения подхода, вы начнёте планировать запуск нового проекта позже и выполнять его быстрее. В идеальном случае, в работе должен находиться только один проект на ресурс.
Примечание 2: Вы можете выработать собственные правила приоритизации проектов с учётом потребления буфера и прогресса проекта.
#метод 25 (продолжение)
Пример: на рисунке, приоритет проектов:
1. Проект B - потому что в красной зоне
2. Проект C - потому что в жёлтой зоне
3. Проект A
Пример: на рисунке, приоритет проектов:
1. Проект B - потому что в красной зоне
2. Проект C - потому что в жёлтой зоне
3. Проект A
#метод 26
== Планирование спринтов ==
=== Правила планирования задач ===
1. Для каждой задачи НЕ может быть задан срок начала и конца завершения задачи. Это приводит к микроменеджменту и не имеет смысла, так, как нарушение сроков предыдущей задачи, сразу делает неактуальными сроки текущей.
2. Задача может быть оценена в идеальных человеко-днях. Где «идеальный человеко-день» это максимально продуктивный день, когда никто и ничто не отвлекает исполнителя от основного занятия.
3. При оценке задачи задаются оптимистичные и пессимистичные оценки длительности выполнения.
4. Сроки могут быть заданы только для проектов.
5. В объем проекта выполняемого уже заложен буфер расписания и буфер содержания.
6. Все задачи выполняются исполнителем последовательно и не могут быть остановлены.
Примечание:
При оценке задачи в “единицах сложности” - у вас не будет аргументации в случае если время выполнения задачи превысит ожидаемое. Ибо нельзя сравнивать “попугаев” с днями.
=== Правила планирования спринта ===
Спринт, итерация – минимальный квант времени (ритм) контроля выполнения проекта, синхронизации проектов и поставки результата. Планирование спринта - это планирование работ каждой команды в спринте и определение коротких, тактических, целей.
При планировании объёма работ в спринте необходимо решить несколько задач:
1. Определить, какие именно задачи необходимо делать
2. Определить, сколько задач сможет сделать команда за спринт.
3. Определить общую, понятную цель которую должна достигнуть команда в рамках спринта.
== Планирование спринтов ==
=== Правила планирования задач ===
1. Для каждой задачи НЕ может быть задан срок начала и конца завершения задачи. Это приводит к микроменеджменту и не имеет смысла, так, как нарушение сроков предыдущей задачи, сразу делает неактуальными сроки текущей.
2. Задача может быть оценена в идеальных человеко-днях. Где «идеальный человеко-день» это максимально продуктивный день, когда никто и ничто не отвлекает исполнителя от основного занятия.
3. При оценке задачи задаются оптимистичные и пессимистичные оценки длительности выполнения.
4. Сроки могут быть заданы только для проектов.
5. В объем проекта выполняемого уже заложен буфер расписания и буфер содержания.
6. Все задачи выполняются исполнителем последовательно и не могут быть остановлены.
Примечание:
При оценке задачи в “единицах сложности” - у вас не будет аргументации в случае если время выполнения задачи превысит ожидаемое. Ибо нельзя сравнивать “попугаев” с днями.
=== Правила планирования спринта ===
Спринт, итерация – минимальный квант времени (ритм) контроля выполнения проекта, синхронизации проектов и поставки результата. Планирование спринта - это планирование работ каждой команды в спринте и определение коротких, тактических, целей.
При планировании объёма работ в спринте необходимо решить несколько задач:
1. Определить, какие именно задачи необходимо делать
2. Определить, сколько задач сможет сделать команда за спринт.
3. Определить общую, понятную цель которую должна достигнуть команда в рамках спринта.
#дао_agile
Планирование загрузки ресурсов
Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.
==
§ 11
Тридцать спиц собираются в одной втулке, но использование повозки зависит от пустоты между ними. Форму и глину применяют при изготовлении сосуда, но использование сосуда зависит от пустоты внутри. Делают дверные проемы и створки дверей, чтобы построить помещение, но использование помещения зависит от внутреннего пространства. Получается, что оплачивают то, что есть, пользуются же тем, чего нет.
==
В применении к ИТ-проектам означает: Мы не должны планировать рабочее время инженера на 100%, и должны учитывать его свободное время. Эти пустоты дадут возможность Инженеру самому решить как улучшить Продукт с инженерной точки зрения. И этим мы сэкономим время проекта. Хороший инженер создает Продукт только тогда, когда ничего не делает руками. Инженер оценивая трудозатраты на выполнение работы, оценивает лишь то время, которое он планирует потратить на работу руками. но очень сложно оценить то время, когда он не должен работать руками.
Планирование загрузки ресурсов
Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.
==
§ 11
Тридцать спиц собираются в одной втулке, но использование повозки зависит от пустоты между ними. Форму и глину применяют при изготовлении сосуда, но использование сосуда зависит от пустоты внутри. Делают дверные проемы и створки дверей, чтобы построить помещение, но использование помещения зависит от внутреннего пространства. Получается, что оплачивают то, что есть, пользуются же тем, чего нет.
==
В применении к ИТ-проектам означает: Мы не должны планировать рабочее время инженера на 100%, и должны учитывать его свободное время. Эти пустоты дадут возможность Инженеру самому решить как улучшить Продукт с инженерной точки зрения. И этим мы сэкономим время проекта. Хороший инженер создает Продукт только тогда, когда ничего не делает руками. Инженер оценивая трудозатраты на выполнение работы, оценивает лишь то время, которое он планирует потратить на работу руками. но очень сложно оценить то время, когда он не должен работать руками.
#дао_agile
Внедрение Agile-подходов
Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.
==
§ 71
Знание собственного незнания—это прекрасно. Ужасно же «знание» невежды. Потому что знающий, что он болен,— на пути к выздоровлению. Таков мудрец—выздоравливает потому, что сознает что болен. Только поэтому.
==
В любой деятельности есть любимые инструменты. Это не хорошо и не плохо. Так устроен мозг, он ищет простые пути. Но не всякая ситуация подходит до известное решение. Часто бывает так, что две ситуации с похожими симптомами могут иметь совершенно разные решения. Это происходит так, потому, что причины приведшие к известным симптомам совершенно разные.
Не стоит применять Scrum и другие популярные методы, пока вы не убедились, что рекомендуемые решения действительно исправляют корневую причину возникшей ситуации.
Внедрение Agile-подходов
Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.
==
§ 71
Знание собственного незнания—это прекрасно. Ужасно же «знание» невежды. Потому что знающий, что он болен,— на пути к выздоровлению. Таков мудрец—выздоравливает потому, что сознает что болен. Только поэтому.
==
В любой деятельности есть любимые инструменты. Это не хорошо и не плохо. Так устроен мозг, он ищет простые пути. Но не всякая ситуация подходит до известное решение. Часто бывает так, что две ситуации с похожими симптомами могут иметь совершенно разные решения. Это происходит так, потому, что причины приведшие к известным симптомам совершенно разные.
Не стоит применять Scrum и другие популярные методы, пока вы не убедились, что рекомендуемые решения действительно исправляют корневую причину возникшей ситуации.
#дао_agile
Управление изменениями
Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.
==
§ 36
Кто желает вдохнуть, непременно должен сначала выдохнуть. Кто желает ослабить, непременно должен сначала укрепить. Кто желает избавиться от чего-либо, непременно должен сначала это возвысить. Кто желает что-либо захватить, непременно должен сначала от этого отказаться. Это и называется тончайшим знанием: гибкое берет верх над жестким; слабое— над сильным. Рыба должна держаться на глубине. Так и в государстве: его самое острое оружие должно быть скрыто от людских взоров.
==
1. Прежде чем делегировать в инженерные команды свободу принятия решений, необходимо определить жесткие Правила. Правила должны быть обязательными к исполнению. Только в этом случае можно быть уверенным в качественном результате. Свобода построена на уважении. Уважение строится на Законе. Правила - это Закон внутри организации.
Отсутствие Закона - Анархия. Отсутствие Правил - неопределенность. Инженеры не любят неопределенность (Предприниматели в ней живут). В неопределенности теряется производительность.
2. Перед тем как менять правила, необходимо снизить требования по скорости поставки результатов. Боязнь ошибки и страх увольнения самое большое препятствие на пути внедрения изменений. Только бесстрашные камикадзе могут преодолеть эти страхи и вывести Продукт на новый уровень. Обычно таких мало.
Управление изменениями
Трактовка Дао (Дао Де Цзин) в применении к управлению проектами и людьми.
NB: Будучи трактованным, смысл Дао может измениться. Но не будучи трактованным смысл может вовсе ускользнуть.
==
§ 36
Кто желает вдохнуть, непременно должен сначала выдохнуть. Кто желает ослабить, непременно должен сначала укрепить. Кто желает избавиться от чего-либо, непременно должен сначала это возвысить. Кто желает что-либо захватить, непременно должен сначала от этого отказаться. Это и называется тончайшим знанием: гибкое берет верх над жестким; слабое— над сильным. Рыба должна держаться на глубине. Так и в государстве: его самое острое оружие должно быть скрыто от людских взоров.
==
1. Прежде чем делегировать в инженерные команды свободу принятия решений, необходимо определить жесткие Правила. Правила должны быть обязательными к исполнению. Только в этом случае можно быть уверенным в качественном результате. Свобода построена на уважении. Уважение строится на Законе. Правила - это Закон внутри организации.
Отсутствие Закона - Анархия. Отсутствие Правил - неопределенность. Инженеры не любят неопределенность (Предприниматели в ней живут). В неопределенности теряется производительность.
2. Перед тем как менять правила, необходимо снизить требования по скорости поставки результатов. Боязнь ошибки и страх увольнения самое большое препятствие на пути внедрения изменений. Только бесстрашные камикадзе могут преодолеть эти страхи и вывести Продукт на новый уровень. Обычно таких мало.