Начинай с тем что есть.
Этот принцип я нашел в Канбан-методе применительно к оптимизации бизнес-процессов. Однако он годится применительно и к развертыванию проектного управления (проект организационных изменений) и к запуску нового бизнеса (или нового Продукта).
Покажу на примерах:
Пример 1. Внедрение проектного управления.
Если не следовать принципу "Начинай с тем что есть", а перейти на другую сторону "Сначала ВСЁ хорошо с спланируем, а ПОТОМ по этим планам будем работать", то есть риск получить "паралич анализа":
- быстрый результат не будет достигнут
- из-за отсутствия быстрого эффекта заниматься планированием не захочется
- влетающие срочные задачи отобьют всё желание планировать
И, как результат будет такая ситуация:
- Ты что делаешь?
- Я планирую как мы будем работать
- И какой результат?
- Я еще в процессе
Вывод: Внедрение проектного управления начинается с учёта текущей работы и с постановки Оперативного Ритма, постепенно расширяя горизонт планирования при появлении препятствий.
Предостережение 1: То что сказано выше, не отменяет Планирование вообще! У вас ДОЛЖЕН БЫТЬ План преобразований, в идеале Дерево Стратегии и тактики, по которому вы идёте. Но не забывайте про правило: БЕЗ ФАНАТИЗМА!!
Предостережение 2: Вы должны БЫТЬ ГОТОВЫ к Планированию (Заглядыванию за горизонт). Иначе смысл самого мыслительного процесса Планирование будет ускользать и считаться лишней бюрократией. Если не готовы, то... Начинай с тем что есть.
Пример 2. Новый продукт.
Должен ли Продукт быть идеальным во всех всех смыслах? Если мы представим такую картинку, то за десятками "Если бы.." "Кабы.." может потеряться основной СМЫСЛ продукта, и его Цель. А с другой стороны в геометрической прогрессии вырастут плановые затраты на запуск Продукта.
Применяя принцип "Начинай с тем что есть" по отношению к новому Продукту (не важно ИТ или какому-либо другому) стоит задаться вопросами:
- Без ЧЕГО Продукт ТОЧНО будет продавабельным при сохранении его целевой функции?
- Что можно точно НЕ ДЕЛАТЬ при сохранении его целевой функции?
Другими словами, на запуске нового Продукта нужно целевой образ продукта нещадно резать для сокращения стартовых инвестиций.
Предостережение: БЕЗ ФАНАТИЗМА! Если форма, вкус, цвет, упаковка и тд Продукта важен для Потребителя, значит это ключевая его характеристика. Продукты - не всегда про "Мечту Клиента". Продукт - это то, за что Клиент платит.
Выводы:
1. Начиная новое начинай с тем что есть. Но без фанатизма!
2. Не нужно стоить ИДЕАЛЬНЫЕ планы, они должны быть ДОСТАТОЧНО хорошие, чтобы по ним можно было НАЧАТЬ работать.
3. Корректируйте планы в процессе работы, они ВСЕГДА не точные.
Рекомендации:
1. Следите за маркерами в разговорах: "Мы не можем сделать ЭТО, потому что у нас нету ТОГО, а это не появится пока мы не сделаем ВСЁ ДРУГОЕ". Если такая (похожая) фраза появляется, не в рамках процесса построения Дерева предпосылок, или Планирования проекта, значит это симптом к параличу анализа (paralysis by analysis).
2. Один из рецептов преодоления паралича анализа: Ограничьте время планирования.
Этот принцип я нашел в Канбан-методе применительно к оптимизации бизнес-процессов. Однако он годится применительно и к развертыванию проектного управления (проект организационных изменений) и к запуску нового бизнеса (или нового Продукта).
Покажу на примерах:
Пример 1. Внедрение проектного управления.
Если не следовать принципу "Начинай с тем что есть", а перейти на другую сторону "Сначала ВСЁ хорошо с спланируем, а ПОТОМ по этим планам будем работать", то есть риск получить "паралич анализа":
- быстрый результат не будет достигнут
- из-за отсутствия быстрого эффекта заниматься планированием не захочется
- влетающие срочные задачи отобьют всё желание планировать
И, как результат будет такая ситуация:
- Ты что делаешь?
- Я планирую как мы будем работать
- И какой результат?
- Я еще в процессе
Вывод: Внедрение проектного управления начинается с учёта текущей работы и с постановки Оперативного Ритма, постепенно расширяя горизонт планирования при появлении препятствий.
Предостережение 1: То что сказано выше, не отменяет Планирование вообще! У вас ДОЛЖЕН БЫТЬ План преобразований, в идеале Дерево Стратегии и тактики, по которому вы идёте. Но не забывайте про правило: БЕЗ ФАНАТИЗМА!!
Предостережение 2: Вы должны БЫТЬ ГОТОВЫ к Планированию (Заглядыванию за горизонт). Иначе смысл самого мыслительного процесса Планирование будет ускользать и считаться лишней бюрократией. Если не готовы, то... Начинай с тем что есть.
Пример 2. Новый продукт.
Должен ли Продукт быть идеальным во всех всех смыслах? Если мы представим такую картинку, то за десятками "Если бы.." "Кабы.." может потеряться основной СМЫСЛ продукта, и его Цель. А с другой стороны в геометрической прогрессии вырастут плановые затраты на запуск Продукта.
Применяя принцип "Начинай с тем что есть" по отношению к новому Продукту (не важно ИТ или какому-либо другому) стоит задаться вопросами:
- Без ЧЕГО Продукт ТОЧНО будет продавабельным при сохранении его целевой функции?
- Что можно точно НЕ ДЕЛАТЬ при сохранении его целевой функции?
Другими словами, на запуске нового Продукта нужно целевой образ продукта нещадно резать для сокращения стартовых инвестиций.
Предостережение: БЕЗ ФАНАТИЗМА! Если форма, вкус, цвет, упаковка и тд Продукта важен для Потребителя, значит это ключевая его характеристика. Продукты - не всегда про "Мечту Клиента". Продукт - это то, за что Клиент платит.
Выводы:
1. Начиная новое начинай с тем что есть. Но без фанатизма!
2. Не нужно стоить ИДЕАЛЬНЫЕ планы, они должны быть ДОСТАТОЧНО хорошие, чтобы по ним можно было НАЧАТЬ работать.
3. Корректируйте планы в процессе работы, они ВСЕГДА не точные.
Рекомендации:
1. Следите за маркерами в разговорах: "Мы не можем сделать ЭТО, потому что у нас нету ТОГО, а это не появится пока мы не сделаем ВСЁ ДРУГОЕ". Если такая (похожая) фраза появляется, не в рамках процесса построения Дерева предпосылок, или Планирования проекта, значит это симптом к параличу анализа (paralysis by analysis).
2. Один из рецептов преодоления паралича анализа: Ограничьте время планирования.
🔥2
Алгоритм 4-шагового делегирования задач.
Частая проблема руководителей - нехватка времени на выполнение всех дел, что на себя взяли. Но часто это связано с тем, что мы как руководители стараемся все делать самостоятельно. Оправдано ли такое? Не всегда!
Если вы находитесь в такой ситуации, то вот простое упражнение:
шаг 1. Выпишите все задачи по типам которыми занимаетесь в течении недели. Обычно принципиально уникальных задач нет, они похожие по типу выполняемой работы.
шаг 2. Отметьте ТРИ задачи которые вы должны делать ЛИЧНО, иначе вам оторвут голову ваш шеф или Клиенты.
шаг 3. Напротив каждой задачи из оставшихся поставьте инициалы того человека, кто будет её делать если вы сляжете в больницу в реанимацию, и не сможете даже позвонить.
шаг 4. Делегируйте! У вас есть план кому и что. Если есть сомнения в качестве, то обсудите с сотрудником особенности выполнения этой работы, или дайте сделать ему самому несколько раз и проверьте результат.
Предупреждение: Многозадачности не существует. Если сотруднику какая-то работа добавилось, значит другую работу он будет делать меньше.
Напоминание: Основная работа Руководителя - организовывать работу! А не бегать и постоянно решать проблемы. Хорошо организованная работа не требует вмешательства Руководителя и люди сами знают "Что им нужно делать", "Как нужно делать" и "Когда нужно делать".
#метод #метод_пульса #ответы_на_вопросы
Частая проблема руководителей - нехватка времени на выполнение всех дел, что на себя взяли. Но часто это связано с тем, что мы как руководители стараемся все делать самостоятельно. Оправдано ли такое? Не всегда!
Если вы находитесь в такой ситуации, то вот простое упражнение:
шаг 1. Выпишите все задачи по типам которыми занимаетесь в течении недели. Обычно принципиально уникальных задач нет, они похожие по типу выполняемой работы.
шаг 2. Отметьте ТРИ задачи которые вы должны делать ЛИЧНО, иначе вам оторвут голову ваш шеф или Клиенты.
шаг 3. Напротив каждой задачи из оставшихся поставьте инициалы того человека, кто будет её делать если вы сляжете в больницу в реанимацию, и не сможете даже позвонить.
шаг 4. Делегируйте! У вас есть план кому и что. Если есть сомнения в качестве, то обсудите с сотрудником особенности выполнения этой работы, или дайте сделать ему самому несколько раз и проверьте результат.
Предупреждение: Многозадачности не существует. Если сотруднику какая-то работа добавилось, значит другую работу он будет делать меньше.
Напоминание: Основная работа Руководителя - организовывать работу! А не бегать и постоянно решать проблемы. Хорошо организованная работа не требует вмешательства Руководителя и люди сами знают "Что им нужно делать", "Как нужно делать" и "Когда нужно делать".
#метод #метод_пульса #ответы_на_вопросы
👍1
В блоге BIPULSE вышла статья:
История методов управления проектами и производствами
Текущие способы управления производством и проектами берут свое начало в истории. Для понимания "Почему они такие, а не другие" и что на них повлияло нужно рассматривать историческую перспективу, Кто, Когда и Где придумал тот или иной подход. В этой статье рассмотрим линию времени методов управления.
Читать дальше
#статья
История методов управления проектами и производствами
Текущие способы управления производством и проектами берут свое начало в истории. Для понимания "Почему они такие, а не другие" и что на них повлияло нужно рассматривать историческую перспективу, Кто, Когда и Где придумал тот или иной подход. В этой статье рассмотрим линию времени методов управления.
Читать дальше
#статья
🔥2
Как управлять и-рисками на коленке стикерах?
Ответ: провести диверсионный анализ (от слова "диверсия", см ТРИЗ)
Алгоритм:
1. Определить что убьет проект или бизнес целиком?
2. Определить меры противодействия найденному в пункте 1.
3. Выполнить планирование проекта (по алгоритму планирования) с учётом результатов п 2.
4. Для промежуточных целей с большим разбросом оценок или отклонением от среднего определить "Что убьет достижение этой цели?", "Что поставит под угрозу этой цели?".
5. Определить меры противодействия найденному в пункте 4.
6. Определить буфер расписания и бюджета проекта
Всё! То что важное вы обработали, остальное не такое важное и закроется буфером проекта.
Границы применения:
1. У вас нет выделенного риск-менеджера
2. У вас не хватает внимания на всё.
3. Проекты длительностью до года.
4. Проекты не связанны с угрозой для жизни в случае аварий. (фарма, АЭС, ядовитые материалы)
Другими словами: там где события общей неопределенности не приведут к тяжелым последствиям.
#метод #метод_пульса
Ответ: провести диверсионный анализ (от слова "диверсия", см ТРИЗ)
Алгоритм:
1. Определить что убьет проект или бизнес целиком?
2. Определить меры противодействия найденному в пункте 1.
3. Выполнить планирование проекта (по алгоритму планирования) с учётом результатов п 2.
4. Для промежуточных целей с большим разбросом оценок или отклонением от среднего определить "Что убьет достижение этой цели?", "Что поставит под угрозу этой цели?".
5. Определить меры противодействия найденному в пункте 4.
6. Определить буфер расписания и бюджета проекта
Всё! То что важное вы обработали, остальное не такое важное и закроется буфером проекта.
Границы применения:
1. У вас нет выделенного риск-менеджера
2. У вас не хватает внимания на всё.
3. Проекты длительностью до года.
4. Проекты не связанны с угрозой для жизни в случае аварий. (фарма, АЭС, ядовитые материалы)
Другими словами: там где события общей неопределенности не приведут к тяжелым последствиям.
#метод #метод_пульса
Нам интересный вопрос задали: Можно ли использовать BIPULSE с методологией отличной от методики управления «Pulse Management» и Теории Ограничений Э.Голдратта.
Отвечаем:
Использовать можно. однако индикаторы проектов ("светофоры") будут работать именно в соответствии с этой методикой.
Ключевые отличия от обычной методики:
* Признание, что есть буфер расписания проекта (Если отклонения сроков проектов допускаются, то буфер точно есть, но его не всегда показывают).
* Признание, что оценки длительности работ не всегда точные. Поэтому нужно использовать диапазоны оценок.
* Признание, что ресурсы компании ограничены и нужно выстраивать проекты в очерёдность.
* Признание, каждый день просрочки проекта - это потери от не запуска результата проекта
в промышленную эксплуатацию, и компания каждый день теряет прогнозную дневную прибыль.
* Признание, каждый сэкономленный день времени реализации проекта - это прибыль в размере прогнозной дневной прибыли.
В целом это основные отличия не только BIPULSE, но и самого Метода управления проектным бизнесом "Pulse Management". Ведь как только вы признаете то что выше, ваша методика управления будет двигаться в сторону более полной реализации Метода.
#bipulse #метод #метод_пульса
Отвечаем:
Использовать можно. однако индикаторы проектов ("светофоры") будут работать именно в соответствии с этой методикой.
Ключевые отличия от обычной методики:
* Признание, что есть буфер расписания проекта (Если отклонения сроков проектов допускаются, то буфер точно есть, но его не всегда показывают).
* Признание, что оценки длительности работ не всегда точные. Поэтому нужно использовать диапазоны оценок.
* Признание, что ресурсы компании ограничены и нужно выстраивать проекты в очерёдность.
* Признание, каждый день просрочки проекта - это потери от не запуска результата проекта
в промышленную эксплуатацию, и компания каждый день теряет прогнозную дневную прибыль.
* Признание, каждый сэкономленный день времени реализации проекта - это прибыль в размере прогнозной дневной прибыли.
В целом это основные отличия не только BIPULSE, но и самого Метода управления проектным бизнесом "Pulse Management". Ведь как только вы признаете то что выше, ваша методика управления будет двигаться в сторону более полной реализации Метода.
#bipulse #метод #метод_пульса
👍1
Как зарабатывать больше на услугах (проектах)
Так как ограничение это наши мощности, а не рынок и вы уже достигли ситуации когда хотят ИМЕННО ВАШИ услуги (точно в вовремя, с отличным качеством) то можно начать управлять входящим потоком заказов через изменение цены:
Базовые показатели:
1. Минимальная стоимость заказов должна покрывать все операционные затраты в период выполнения заказов. (в месяц/год...)
2. Определяем срок контрактования от контакта до договора. - Длительность контрактования и конверсия в договор это "буфер запасов перед ограничением"
Дальше просто:
1. Если очередь заказов больше срока (буфер заказов уже голубой) - повышаем цену в заградительную (Но бойтесь если возьмут?)
2. Если очередь заказов в зеленой зоне буфера - делаем комфортную для себя
3. Если очередь заказов в желтой зоне буфера - понижаем цену.
4. Если очередь заказов в красной зоне буфера - понижаем цену в уровень окупаемости или ниже, если если есть запасы, у вас выбор "Платить из своего кармана всё " или "Платить из своего кармана часть"
И всё! Механизм простой но действенный.
см. по теме: Буфер запасов.
Так как ограничение это наши мощности, а не рынок и вы уже достигли ситуации когда хотят ИМЕННО ВАШИ услуги (точно в вовремя, с отличным качеством) то можно начать управлять входящим потоком заказов через изменение цены:
Базовые показатели:
1. Минимальная стоимость заказов должна покрывать все операционные затраты в период выполнения заказов. (в месяц/год...)
2. Определяем срок контрактования от контакта до договора. - Длительность контрактования и конверсия в договор это "буфер запасов перед ограничением"
Дальше просто:
1. Если очередь заказов больше срока (буфер заказов уже голубой) - повышаем цену в заградительную (Но бойтесь если возьмут?)
2. Если очередь заказов в зеленой зоне буфера - делаем комфортную для себя
3. Если очередь заказов в желтой зоне буфера - понижаем цену.
4. Если очередь заказов в красной зоне буфера - понижаем цену в уровень окупаемости или ниже, если если есть запасы, у вас выбор "Платить из своего кармана всё " или "Платить из своего кармана часть"
И всё! Механизм простой но действенный.
см. по теме: Буфер запасов.
🔥3👍1
Уведомление: 7 октября 2023 года с 5:00 до 6:00 по Московскому времени будут проводиться на сетевом оборудовании, BIPULSE будет недоступен до 30 мин.
#bipulse
#bipulse
Есть ли управление рисками в ИТ-проектах?
Часто (почти всегда), управления рисками в ИТ-проектах нет.
Потому что:
1. ИТ-проекты делают инженеры - им не интересно думать про и-риски.
2. ИТ-проектами ЧАСТО управляют инженеры - им нужно "пасти котов" а не заниматься и-рисками.
3. Заказчик ЧАСТО приходит с Решением, которое НЕ РЕШАЕТ его проблему.
4. Инженеры думают что, то что принёс Заказчик это о что ему НУЖНО.
5. Инженерам пофиг на цель Заказчика, интересней решать инженерную "вкусную" задачу.
Это характерно для всех знаниевых проектов. (могут быть вариации в зависимости от среды)
Из этих посылок я и свёл все в Метод Управления проектным бизнесом. Чтобы нормально управлять знаниевыми проекта.
(по следам одного из чатов)
@bipulse
Часто (почти всегда), управления рисками в ИТ-проектах нет.
Потому что:
1. ИТ-проекты делают инженеры - им не интересно думать про и-риски.
2. ИТ-проектами ЧАСТО управляют инженеры - им нужно "пасти котов" а не заниматься и-рисками.
3. Заказчик ЧАСТО приходит с Решением, которое НЕ РЕШАЕТ его проблему.
4. Инженеры думают что, то что принёс Заказчик это о что ему НУЖНО.
5. Инженерам пофиг на цель Заказчика, интересней решать инженерную "вкусную" задачу.
Это характерно для всех знаниевых проектов. (могут быть вариации в зависимости от среды)
Из этих посылок я и свёл все в Метод Управления проектным бизнесом. Чтобы нормально управлять знаниевыми проекта.
(по следам одного из чатов)
@bipulse
❤1
Можно ли получить устойчивый навык планирования проекта за 24 часа обучения
В одном чате возник спор про качество обучения навыками управления проектами. А так как мы (и я Алексей Васильев лично) проводим обучение управлению проектами, то мы можем утверждать что технология Метода и формат проводимого обучения действительно даёт начальные навыки управления для управления проектами на приемлемом уровне для последующей отработки и дальнейшего развития.
В качестве доказательства приведу пару примеров
Ситуация 1:
* Школьник, 14 лет, "вписался" управлять двумя проектами по созданию игр. Первая часть обоих проектов там это постановка цели и планирование достижения цели.
Начальные знания:
* Прочитал книгу "Управление проектным бизнесом"
* Послушал пару выпусков подкаста "Разговоры о Методе Управления проектным бизнесом" , где я про планирование рассказываю.
Итоги:
* Постановка цели проекта: 3 раунда для 2 проектов (2+1). - 1 корректировка по рекомендации. После 2 раундов по первому проекту, третий по второму уже прошел без ошибок.
* Планирование проекта - 2 корректировки. К 4 раунду планирования уже проводил планирование без ошибок.
И это при том, что он НЕ проходил моего системного обучения с практикой.
Ситуация 2.
Было:
Руководитель архитектурного бюро (самый главный архитектор). Задачи велись в Трелло.
Все проекты выполнялись с просрочкой.
Стало:
После объяснения как строить надежные планы (рекомендации Метода) и 3 корректировок самостоятельно начал планировать другие проекты и через 6 месяцев заполнил свой портфель проектов на 3 месяца вперед с успеваемостью всех вовремя.
Выводы:
* Навык постановки цели и планирования проекта отрабатывается за 24 часа обучения.
* Управлять планированием проекта можно даже зная контекста, потому что его знают владельцы экспертизы / исполнители / ГИПы.
* Нельзя путать качество планирования как процесса и содержание.
Бывает что в строительной среде есть выделенные планировщики проектов которые ДОЛЖНЫ понимать особенности строительства объектов, и они этого не понимают, это НЕ ТОЖЕ САМОЕ что навык планирования проекта.
Два примера выше показывают что технология планирования проекта одинаково работает и для опытного инженера и для школьника.
==
А 27 ноября стартует онлайн креш-курс "Выполнение проектов вовремя и с рамках бюджета" (по формуле 4 недели 8 занятий) , еще есть места но быстро заканчиваются. Когда будет следующий я не знаю (честно не знаю)
В одном чате возник спор про качество обучения навыками управления проектами. А так как мы (и я Алексей Васильев лично) проводим обучение управлению проектами, то мы можем утверждать что технология Метода и формат проводимого обучения действительно даёт начальные навыки управления для управления проектами на приемлемом уровне для последующей отработки и дальнейшего развития.
В качестве доказательства приведу пару примеров
Ситуация 1:
* Школьник, 14 лет, "вписался" управлять двумя проектами по созданию игр. Первая часть обоих проектов там это постановка цели и планирование достижения цели.
Начальные знания:
* Прочитал книгу "Управление проектным бизнесом"
* Послушал пару выпусков подкаста "Разговоры о Методе Управления проектным бизнесом" , где я про планирование рассказываю.
Итоги:
* Постановка цели проекта: 3 раунда для 2 проектов (2+1). - 1 корректировка по рекомендации. После 2 раундов по первому проекту, третий по второму уже прошел без ошибок.
* Планирование проекта - 2 корректировки. К 4 раунду планирования уже проводил планирование без ошибок.
И это при том, что он НЕ проходил моего системного обучения с практикой.
Ситуация 2.
Было:
Руководитель архитектурного бюро (самый главный архитектор). Задачи велись в Трелло.
Все проекты выполнялись с просрочкой.
Стало:
После объяснения как строить надежные планы (рекомендации Метода) и 3 корректировок самостоятельно начал планировать другие проекты и через 6 месяцев заполнил свой портфель проектов на 3 месяца вперед с успеваемостью всех вовремя.
Выводы:
* Навык постановки цели и планирования проекта отрабатывается за 24 часа обучения.
* Управлять планированием проекта можно даже зная контекста, потому что его знают владельцы экспертизы / исполнители / ГИПы.
* Нельзя путать качество планирования как процесса и содержание.
Бывает что в строительной среде есть выделенные планировщики проектов которые ДОЛЖНЫ понимать особенности строительства объектов, и они этого не понимают, это НЕ ТОЖЕ САМОЕ что навык планирования проекта.
Два примера выше показывают что технология планирования проекта одинаково работает и для опытного инженера и для школьника.
==
А 27 ноября стартует онлайн креш-курс "Выполнение проектов вовремя и с рамках бюджета" (по формуле 4 недели 8 занятий) , еще есть места но быстро заканчиваются. Когда будет следующий я не знаю (честно не знаю)
👍4🔥1
Вебинар буду проводить. 14 ноября , 11-00 МСК
Бесплатный вебинар "Как управлять проектом когда много изменений"
На вебинаре вы узнаете, как решать проблемы, которые возникают на проекте внезапно, но требуют немедленного решения. Расскажем, как обещать надежные сроки заказчикам, быть с ними на одной волне и преодолевать сопротивление.
Важные темы, рассматриваемые на вебинаре:
* Какие возможности есть для избегания встречи с «нежданчиком»
* Как обрабатывать «нежданчики»
* Как управлять заинтересованными сторонами, когда «нежданчик» всё-таки пришёл
* Как приоритизировать проекты когда их много
* Причём здесь Теория ограничений
Регистрация по ссылке:
https://pulsemanagement.timepad.ru/event/2666087/
Бесплатный вебинар "Как управлять проектом когда много изменений"
На вебинаре вы узнаете, как решать проблемы, которые возникают на проекте внезапно, но требуют немедленного решения. Расскажем, как обещать надежные сроки заказчикам, быть с ними на одной волне и преодолевать сопротивление.
Важные темы, рассматриваемые на вебинаре:
* Какие возможности есть для избегания встречи с «нежданчиком»
* Как обрабатывать «нежданчики»
* Как управлять заинтересованными сторонами, когда «нежданчик» всё-таки пришёл
* Как приоритизировать проекты когда их много
* Причём здесь Теория ограничений
Регистрация по ссылке:
https://pulsemanagement.timepad.ru/event/2666087/
pulsemanagement.timepad.ru
Бесплатный вебинар "Как управлять проектом когда много изменений" / События на TimePad.ru
На вебинаре вы узнаете, как решать проблемы, которые возникают на проекте внезапно, но требуют немедленного решения. Расскажем, как обещать надежные сроки заказчикам, быть с ними на одной волне и преодолевать сопротивление.
💯2❤1
Иногда я выступаю на конференциях. На этой конференции было сразу 2 доклада.
А по теме "Как ставить цель проекта так, чтобы её можно было достигнуть, а не как обычно" в этот четверг в 11-00 МСК будет вебинар:
https://pulsemanagement.timepad.ru/event/2680680/
А по теме "Как ставить цель проекта так, чтобы её можно было достигнуть, а не как обычно" в этот четверг в 11-00 МСК будет вебинар:
https://pulsemanagement.timepad.ru/event/2680680/
🔥2👍1
Правила программируют организацию, договаривайтесь о правилах!
Forwarded from Ivan Abashkin blog
Создание процессов и правил - это не просто бюрократическая забава, это фундаментальное основание любой организации. Но тут есть одно большое "но": эти правила и процессы должны быть не просто записаны, они должны быть живыми, дышащими договорённостями между людьми. Они должны быть чем-то большим, чем просто строки в инструкции, которую никто не читает.
Если процессы и правила взяты навязаны сверху, то люди будут следовать им лишь формально, и то, только под давлением. Но если эти процессы и правила рождаются из реального общения, из способности людей договариваться, решать проблемы и конфликты вместе, то это совершенно другая история. В этом случае формальная фиксация - это просто способ не забыть, но не более того.
Когда вы вводите правила и регламенты, даже если вы абсолютный гений в своем деле, вы рискуете унизить людей, для которых эти правила предназначены. Почему? Потому что вы своими действиями говорите: "Я знаю лучше". Но, черт возьми, откуда вы знаете, что действительно знаете лучше? Вы это доказали? Почему вы считаете, что имеете право решать за других?
Так вот, есть два пути. Первый - играть роль "большого папочки", кому все должны подчиняться. И да, люди могут подчиняться, но только потому, что они не имеют выбора. Второй путь - гораздо умнее. Это когда вы тонко подводите людей к тому, чтобы они сами пришли к нужным выводам. Вы не навязываете, а скорее направляете их мысли. Это искусство, требующее умения слушать, понимать и уважать других.
Помните, что в конечном итоге, самое важное в любой организации - это не процессы и правила, а люди, которые за ними стоят. Создавайте среду, где люди могут общаться, договариваться и решать проблемы вместе. Тогда процессы и правила будут не бременем, а естественным продолжением совместной работы и коллективной мудрости.
Если процессы и правила взяты навязаны сверху, то люди будут следовать им лишь формально, и то, только под давлением. Но если эти процессы и правила рождаются из реального общения, из способности людей договариваться, решать проблемы и конфликты вместе, то это совершенно другая история. В этом случае формальная фиксация - это просто способ не забыть, но не более того.
Когда вы вводите правила и регламенты, даже если вы абсолютный гений в своем деле, вы рискуете унизить людей, для которых эти правила предназначены. Почему? Потому что вы своими действиями говорите: "Я знаю лучше". Но, черт возьми, откуда вы знаете, что действительно знаете лучше? Вы это доказали? Почему вы считаете, что имеете право решать за других?
Так вот, есть два пути. Первый - играть роль "большого папочки", кому все должны подчиняться. И да, люди могут подчиняться, но только потому, что они не имеют выбора. Второй путь - гораздо умнее. Это когда вы тонко подводите людей к тому, чтобы они сами пришли к нужным выводам. Вы не навязываете, а скорее направляете их мысли. Это искусство, требующее умения слушать, понимать и уважать других.
Помните, что в конечном итоге, самое важное в любой организации - это не процессы и правила, а люди, которые за ними стоят. Создавайте среду, где люди могут общаться, договариваться и решать проблемы вместе. Тогда процессы и правила будут не бременем, а естественным продолжением совместной работы и коллективной мудрости.
🔥9
Про Винcтона Ройса, Agile и разработку программного обеспечения.
На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!
Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.
И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие.
И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!
То есть:
Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.
Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.
Отсюда вывод:
Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче.
#ответы_на_вопросы #TOC
На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!
Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.
И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие.
И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!
То есть:
Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.
Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.
Отсюда вывод:
Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче.
#ответы_на_вопросы #TOC
🔥7👍3