Продолжаем цикл публикаций о Pulse Management — Управление проектной организацией (Метод Пульса). Мы уже разобрались с моделью организации, с основными принципами Метода. Теперь время рассказать о Правилах. Правила программируют организацию, а значит они должны быть определены. Метод определяет Правила исходя из предпосылок среды, если у вас ситуация схожая, то вы можете применять эти правила, иначе — адаптируйте под свою среду.
Первые основные правила: Правила Целей. Инженеры такие люди, которые могут достичь любую цель, однако если им цель не поставят, то они будут достигать свою цель. И она может не совсем соответствовать целям организации.
Управление целями
Цель в организации — это такая сущность, которую кому-то «надо достигнуть» и на её достижение тратятся время и ресурсы. Кроме целей существуют«Инициативы» или «Идеи» они отличаются от «Целей» тем, что они находятся в категории «желательно достигнуть». Обычно, если «желательно» — это значит что решения о финансировании достижения такой цели еще не принято, и в карте развития организации такая Инициатива может стоят совсем не на первом месте.
Принципы существования целей
- Мысль материальна. Чем более высокооплачиваемое лицо озвучивает мысль, тем выше вероятность, что озвученная мысль станет целью для сотрудников.
- Творческие люди склонны придумывать себе задачи интересней. Задача в общем виде решается проще, и для инженера самое интересное, это найти “общий вид”.
- Та работа, которая была придумана самостоятельно становится целью и выполняется охотнее.
- Мы никогда не знаем, сколько целей в организации.
- Не зафиксированная на бумаге (в документе) мысль тратит энергию на удержание её в голове.
- Множество Целей в организации приводят к многозадачности на уровне инженеров.
Правила управления целями
Исходя из принципов существования целей необходимо применять следующие правила управления целями:
- Договариваться о правилах запуска Инициативы в работу.
- Если Инициатива не утверждена, как цель к исполнению или в работе уже находятся другие Цели, то инженер обязан отказаться брать Инициативу в работу. (Однако бывают менеджеры с даром убеждения, поэтому инженеру сложно отказаться если не создать выгодную для него среду, например через систему бонусов)
- Договариваться о правилах работы с Инициативами. Делиться идеями руководству с инженерами можно, но должно быть чёткое понимание зачем это делать и какой результат хочется получить в результате озвучивания идеи.
- Есть идея – пиши в wiki. Идея будучи записанной, немного потеряет свой блеск, но будет пригодна для обсуждения.
- Цель коммерческой организации — создавать ценность для акционеров, клиентов, персонала компании и общества. Это значит, что любую Инициатива необходимо оценивать с точки влияния результата Инициативы на увеличение ценности приносимой организацией.
- При запуске Инициативы в работу при незавершённых других Целях стоит помнить, что на предыдущие цели уже потрачены ресурсы и нужно или признать их убытком или довести до конца перед запуском новой Инициативы.
- Озвучив идею и определив цель, дайте возможность инженерам самим придумать маршрут движения к цели. Помогайте им придумывать, задавая вопросы: А что будет если….? А как бы нам учесть ещё и этот фактор…. Что нужно сделать перед этим? Что нам мешает достигнуть цели?
Заключение части
Правила простые, но если вы о них еще не договорись, то вы можете внезапно обнаружить, что инженер «пилит» какой-то фреймворк вместо того, чтобы взять готовый или сделать задачу наиболее простым способом. Или вместо того, чтобы делать проект по которому есть внешние обязательства инженер занят реализацией идеи о которой вслух подумал владелец компании на планёрке.
Расскажите в комментариях ваши случаи появления «скрытых» целей в ваших организациях. Как они появляются у вас?
Продолжение следует.
P.S.: Но, если хочется всё и сразу, то есть методичка «Pulse Management: Управление проектной организацией»
0pauc0
Интересно. Особенно с учетом предыдущих публикаций.
Однако, полагаю, нужна формальная структура метода, его правил и инструментов (в Вашей терминологии), начиная с целеполагания и до оценки полученных результатов. Все таки речь идет не о постановке в детском театре, а о бизнесе с реальными доходами, зарплатами и риском получить убыток.
Кстати о рисках — думаю как пример структурирования, интересен весьма будет совсем свежий ГОСТ Р 57551-2017/ISO/TR .
Ну и в целом — давно придуманные ГОСТы в помощь (ГОСТ 3.ххх-хх — ЕСТД), а раз речь идет о проектировании и создании программных систем, то и:
ГОСТ 19.ххх-хх — ЕСПД
ГОСТ 34.ххх-хх — АС
sbase Автор
Все Правила Метода опубликованы на сайте pulsemanagement.org
Результат применения Метода один: Выполнение Организацией всех обязательств вовремя и в полном объеме. Если вы уже применили Метод и не получили этот результат, то нужно разбираться как вам это удалось. Статистика TOCICO — 90% проектов применяющих Критическую Цепь завершаются вовремя, Метод определяет правила игры с применением инструментов ТОС, Agile и проектного управления.
Границы применения Метода и его полнота опубликована в первой статье.
о ГОСТах: ГОСТы вещь хорошая, однако:
1. Они определяют правила, но не говорят «зачем так»
2. Их мало кто читает, если это не прописано в ТЗ к контракту.
Метод Пульса (Pulse Management) решает эти два препятствия за счёт компактности практик и цельного подхода для цикла PCDA
0pauc0
Полагаю, что выполнение все таки не любой ценой, а значит еще и в запланированном бюджете, без сверхнормативного износа основных фондов и переработки персонала?
А в целом, про теорию ограничений — если в производстве есть «узкие места» (являющиеся предметом для теории ограничений), то производственные технологические процессы спроектированы/разработаны плохо и соответственно их необходимо актуализировать, а не выбрать одно-два узких места и их решать.
В реальном производстве это приведет к тому, что например занимаясь только «большим» вопросом достижения заданной прочности турбины можно не заметить проблему точности изготовления ее маленького хвостовика.
Все требования к процессу изготовления изделий излагаются в технологических картах и маршрутах. Для крупно- и среднесерийных производств от указанных документов зависит все — и оборудование и персонал и логистика и достижение заданных характеристик продукта.
Для мелкосерийных производств и организаций разработки программных продуктов технологические карты можно и не разрабатывать — они в головах квалифицированного персонала, но технологические маршруты нужны — без них нет исходных данных для управления производством/разработкой.
Не знаю, где Вы взяли данные о том, что применение «критической цепи» в реализации проектов дает 90% своевременного разрешения, но если бы мне, как руководителю или акционеру сказали, что 1 из 10 заключенных договоров не будет реализован в сроки, или в ходе выполнения договора для выполнения их в срок будут потрачены ресурсы сверх плановой себестоимости, то наверное носителю такой черной вести была бы оторвана голова.
В производстве/разработке важно все, не только своевременность.
sbase Автор
1. ТОС — это не только про узкое место, это еще и системные инструменты анализа и решения ситуации.
2. >> Не знаю, где Вы взяли данные о том,
Статистика TOCICO, CCPM — это только один из инструментов общего процесса. В одной из компаний которую мы консультировали, сокращение одновременных исполняющихся проектов (проектов, но не контрактов) с 30 до 8 заняло полгода.
Если Ваша позиция в том чтобы отрывать головы вместо решения задачи о возвращении проекта в норму — это ваше право. Возможно у Вас неограниченные ресурсы и бюджет для таких действий, чтобы восполнить оторванную голову новой. Однако, моя практика показывает, что владелец компании меняет свои привычки для того, чтобы обеспечить выполнение всех обязательств организации вовремя и в полном объеме.