вторник, 24 января 2017 г.

Навигационная сессия по системному лидерству


Место системного лидера в предпринятии. На входе у него спроектированное инженером предпринятие (мультимодель), он уговаривает интеллекты занять спроектированные роли.

Вспоминаем закон Конвея - если структура коммуникаций обеспечивающей системы не соответствует структуре целевой системы, то как ни собирай, получится пулемет. Задача лидера - создать такую систему коммуникаций, чтобы получилось что надо.

Лидер в основном работает с альфой Команды, само является Технологией. Плюс, краем касается альфы Стейкхолдеров, чтобы они поддерживали Команду.

Целевой системой лидера является работа команды (4Д экстент всех Работ).
Основой лидерства являются коммуникации. Если вы не смогли донести архитектуру предпринятия до команды, шансов на то, что интеллекты заполнят оргместа нет никаких.
Коммуникации делятся на три части - информирование, влияние и ритуальное общение.

Вспомним бейсики системного лидерства.


Практики системного лидерства развертываются на жизненном цикле операций команды в следующей последовательности - вначале практики информирования, затем влияния. Практики лидерства тесно переплетены с практиками управления собой. Как говорил Мормонт Джону Сноу "Если ты хочешь вести за собой, научись следовать".
Изменения поведения могут произойти только изнутри интеллекта, навязать новое поведение невозможно.
Лидерство, таким образом - это практики детального дизайна, проверки и приемки.

Модель коммуникации с учетом классической пятикомпонентной схемы и теории перспектив.
Информирование и влияние влияют на разные компоненты функциональной схемы коммуникации интеллектов.
Неправильное ритуальное поведение вызывает чувство сродное Uncanny valley (зловещая долина), это нужно учитывать при попытках копировать сложные культурные коды.

Коммуникационные циклы. Главным является цикл рефлексии/самоконтроля/осознанности.
В коммуникационную модель добавляется миндалевидное тело, т.н. амигдала. Это центр эмоционального контроля, способный перехватывать управление поведением, т.н. захват миндалевидного тела. Контроль за амигдалой рассматривается в дисциплине эмоционального интеллекта.



Полная модель коммуникационного акта. Коммуникационный акт является стартовой точкой любого оргпроцесса-модуля обеспечивающей системы. Проверка и приемка - это тоже коммуникационные акты.


Расширение Эссенс. Подальфы команды и особенности циклов информирования и влияния при работе с этими альфами. Дополнительные состояния подальф. Подробности см. Тулган "Все начальники делают это" (27 правил менеджера).

Подальфы Стейкхолдеров и их Activity spaces.
Ключевая вещь, которую стоит понимать про управление изменениями (change management) - вначале вы информируете стейкхолдеров, предъявляя им частные описания с использованием частных методов описания, отвечающих на их интересы. Когда они поймут, они разделятся на три группы - те, кому нравится изменение/предпринятие, те, кому оно не нравится и те, кому не нравитесь вы. Используя ситуационное лидерство и эмоциональный интеллект, системный лидер обеспечивает поддержку команды стейкхолдерами.
Модель ситуационного лидерства Коулмана. Накладывается на модель четырех комнат (состояния подальфы "Сторонники изменений").











воскресенье, 15 января 2017 г.

Моделирование риск-ориентированных процессов в ArchiMate

Одно из типовых использований мотивационного расширения ArchiMate - моделирование рисков и обоснований проектов.

Пример такой модели:
Общий вид модели. Обратите внимание на трассировку требований стейкхолдера  элементам конструкции модуля-оргпроцесса.

Мотивационное расширение.Модель рисков процесса и проектное обоснование TO BE.

суббота, 14 января 2017 г.

Спираль развития проектного управления

Разнесу два понятия.
  1. “Стадия” жизненного цикла (ЖЦ) продукта (системы), характеризуется заметной сменой состояния описания либо воплощения системы. Находится в логическом времени.
  2. “Фаза” ЖЦ проекта (обеспечивающей системы) как временной промежуток, на котором команде проекта выделено целевое финансирование для выполнения определенных работ или реализации требований стейкхолдеров. Факт выполнения работ и удовлетворения требований демонстрируется в конце фазы. Находится в физическом времени.

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

Наиболее распространенное современное понимание проекта подразумевает, что он существует только в рамках программы или портфеля и его цель (продукт проекта) задаются вне проекта, приходят либо в рамках бизнес-кейса программы либо каскадируются от стратегии (описания портфеля активностей) предприятия.
В соответствии с законом Конвея, архитектурные решения по организации проекта, тоже задаются снаружи, см. Устав/Паспорт/Бриф  и т.п. и идут от описания проблемы и целевого состояния предприятия.
В соответствии с обратным законом Конвея, “жесткая инфраструктура проекта”, такие как ИТ-ландшафт предприятия, обязательные регламенты по комплаенс и т.д., будут диктовать как оргструктуру проекта и структуру его фаз и предметов поставки (результатов проекта, deliverables).

***
Вставка
Что почитать про закон Конвея?

Проекты в непроектных организациях предназначены для создания новой коммуникационной структуры, чтобы произвести что-то такое, чего стандартная оргструктура не может (об этом молчит ПМБОК и это одна из проблем).
В проектах оргразвития это чаще всего новый бизнес-процесс (на самом деле практика), со всеми поддерживающими его ИТ-решениями (технологией) и обученным персоналом (дисциплиной). Выглядит это так. Делается проект-оргмодуль, который после стабилизации архитектуры, модульного дизайна и интерфейсов становится процессом-оргмодулем. В реальности вместо процессного менеджмента используется кейс менеджмент и это тоже надо признать и переходить в адаптивный кейс-менеджмент. Часто проект оргразвития сопровождается реинжинирингом процессов-оргмодулей.

Системный менеджмент и инженерия предприятия объясняют, как спроектировать такую организацию, которая сможет произвести продукт, востребованный рынком и при этом соблюсти множественные интересы людей вокруг.

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

ПМБОК неявно подразумевает, что проектный менеджер является как инженером предпринятия, так и лидером.

В эту же копилку попадает т.н. “Ориентация на процесс” и “ориентация на результат”. Ориентация на процесс - это когда новый дизайн пытаются сделать в неподходящей коммуникационной структуре. Ориентация на результат часто трактуется как “достижение целевых показателей KPI” или “достижение целей организации”, так любимой другим популярным стандартом БАБОК.
Для меня есть лидерские практики, в которых гораздо важнее ориентация на процесс - риск-менеджмент, принятие решений, выявление требований. Они применяются к системам систем. И есть инженерные и управленческие практики, где применима логика и строятся алгоритмы достижения результата. Это и есть ориентированность на результат в моем понимании.
Отсюда вытекает объяснение, почему алгоритмы (проектные планы) неэффективны тогда, когда эффективны циклы (Шухарта, например). И здесь же пролегает еще одна граница между процессами и проектами, помимо стабильности модульной структуры и интерфейсов. Оргпроцессы-кейсы более эффективны с мягкими системами, чем проектно-алгоритмический подход. Отсюда все эти Эджайл проекты, которые своими итерациями крайне напоминают процессные циклы. Мягкие системы.
В общем и целом, границы размываются и надо уходить от всех этих проектных-процессных подходов в адаптивный кейс-менеджмент с холистической платформой как в части технологий, так и в части команды.
***

Это понимание не самое оптимальное с точки зрения организации работ и описательных схем. В этой заметке я кратко опишу как пришли к такой картине мире и какой следующий шаг.


Поколение ПУ
Проект
Программа
1-ое поколение.
ПМ приходят из инженеров, подразумевается отличное знание предметной области. Сшивка целевой и обеспечивающей системы происходит в голове ПМ. Смерть подхода связана с превышением размера проекта предела, когда он помещается в голове одного человека.
Ориентирован на достижение запланированного результата в рамках тройных ограничений.
Запланированный результат задается вне проекта, сам проект покрывает только стадию жизненного цикла “Производство/Поставка”. Речь идет только об организации работ, ведущая дисциплина - исследование операций.
Т.к. люди бизнеса не понимали внутренностей проекта, единственный способ контроля за инвестициями была модель “стадия-гейт”.
Это такой большой проект, разве что из-за величины гораздо более важными становятся такие вещи, как контроль изменений и управление информацией.
Гейты еще более строгие, еще более длительные (до нескольких месяцев), происходит сшивка и согласование многих целевых и обеспечивающих систем.
2-ое поколение. Расцвет методологий и проектных офисов (офисов управления проектами, project management office, не путайте с офисом проекта project office).
Связаны с массовой компьютеризацией и второй промышленной революцией. Открытие процессного подхода в области управления качеством и рисками (мягкими системами) позволило сделать прорыв сложности. Получилось создавать успешные сложные системы для массового производства - автомобили, компьютеры, самолеты, бытовая и офисная техника. Смерть подхода связана с насыщением рынка, см. Современный Китай, где выпуск промпроизводства падает который год подряд и норма прибыли около ноля.

По иронии, государство сейчас внедряет гибрид между первым и вторым поколением.
Возникает четкое разделение между проектом, который нацелен на получение продукта, и программой, которая отвечает за получение эффекта.
Бизнес-кейс и архитектура целевой системы в классике приходит от уровня программы, но есть варианты, см. например PRINCE2 и MSP.
Управление представителями стейкхолдеров происходит здесь, есть разделение работ между ПМ, который работает с представителями стейкхолдеров в разрезе системы и ограничений проекта и бизнес-аналитика, который работает с логической архитектурой, требованиями и дизайном целевой системы.
К трем стандартным viewpoint добавляются еще качество, риски и многие другие.
Появляется separation of concerns и управление интеграцией, единственное, что эти рассмотрения происходят скопом как для целевой системы, так и для обеспечивающей, из-за чего возникает много путаницы.
Вводится понятие ЖЦ системы и появляются проекты управления системой на всем ЖЦ, см., например CDC UP https://www2a.cdc.gov/cdcup/library/pmg/default.htm
Но чаще всего проект захватывает либо стадию ЖЦ системы, либо ее часть, редко выходя за границы стадии. Слабо стыкуется с ЖЦ 2.0 как набора практик.
Операционный менеджмент уходит из критического пути в  критическую цепь, идет переход оценок из “классического” бета-распределения в байесовскую статистику , поощряется их уточнение по ходу выполнения работ. Становление системы канбан и управления узким местом прохода системы.
Успехом проекта начинает считаться удовлетворенность заказчика, повышается роль бизнес-кейса при управлении изменениями.
В рамках программного менеджмента определяется логическая и физическая архитектура обеспечивающей системы, решаются вопросы модульности и интерфейсов (контракт + сервис) внутри программы для проектных команд и снаружи программы для стейкхолдеров программы. Управление стейкхолдерами в аспекте интересов и работа с viewpoints происходит здесь.
ЖЦ системы как правило эволюционный, система становится, а не проектируется, соответственно программный менеджер часто меняет обеспечивающую систему - открывает новые проекты и закрывает текущие, меняет скоуп. Системные инженеры обитают на уровне программы, обеспечивают склейку
3-е поколение, развивающееся.
Уход проектных офисов, массовое их отмирание, переход методологической функции на проектные команды (ситуационная инженерия методов, временные методологии, становление метода в проекте, см. Блог Эдисона).
Связано со смертью массового производства в пользу кастомизированных продуктов с гораздо более коротким ЖЦ.
Один из основных профитов проектных офисов 2-го поколения - базы знаний и оценок теряют в современных проектах свое значение, т.к. и знание и оценки в силу изменения технологий теряют смысл.
Проекты из набора процессов-оргмодулей становятся наборами кейсов-оргмодулей, для каждого кейса проектируется метод. Целевая система рассматривается как холархия подсистем, для каждой из которых есть свои ЖЦ и метод разработки и производства. Склейка ЖЦ подсистем происходит в PLM.
Микрокоманды работают по раздельности внутри своих систем. Пример - Spotify https://www.youtube.com/watch?v=Mpsn3WaI_4k

Проекты разбиваются на контрольные точки (КТ), которые являются требованиями стейкхолдеров, привязанными к сроку их реализации и приемки. Каждая такая КТ есть мини-проект, по отношению к ней применяется стандартное проектное управление.
Окончательный уход от гейтов, выделение ресурсов под реализацию требований, бюджет и сроки проекта постоянно уточняются по модели предпринятия на уровне программы.
Бизнес-кейс проекта направляет все работы.
На уровне программы определяется платформа целевой и обеспечивающей системы, с особым упором на модульность и стандарты интерфейсов, т.к. именно интерфейсы и их качество определяют успех системы и проекта.

На этом уровне существуют основные модели предпринятия.

Управление ресурсами проектов уходит на уровень программы, выделение динамическое, по Hyper Kanban или TameFlow.

Управление инфраструктурой проектов делится на две части - архитектурная (ERP, PLM, EAM и прочие ИТ-системы с высоким КАПЕКСом) остается на уровне программы, динамическая уходит в проекты и ее никто не контролирует.

3-е поколение вкратце и есть адаптивный кейс-менеджмент:
  1. Системный подход позволяет разбивать целевую систему на маленькие кусочки, которые можно отдать 2-pizza team и без проблем сшить итоговый результат
  2. Есть IT platform и people platform (я про нее писал недавно, пост про ПЛАС)
  3. Есть управленческая платформа - это архитектура предприятия и руководящие микропринципы (в моей терминологии это СОП, стандартные операционные процедуры, SOP, standard operating procedures).

А теперь перечитайте 100 правил руководителей проектов в НАСА, http://www.oliverlehmann.com/project-management-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf
Стало ли яснее, о чем они и что надо в них менять для современных проектов?


суббота, 7 января 2017 г.

Как улучшить майндмэп?

Добавь картинки. Это одна из ключевых проблем, которую делают при создании майндмэпов - не вставляют пиктограммы. Посмотрите, на пример:
В каждом крупном проекте нужно создавать визуальный словарь терминов. Частые слова должны иметь форму и образ. Его надо использовать во флип-чарт сессиях, на рабочих встречах, совещаниях и презентациях.

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

Перейти на визуальную грамматику непросто. Хорошо, если вы начнете с того, что будете ставить стандартные иконки в майндмэпах. Откройте их, посмотрите. Какая из них больше всего подходит под данный пункт? Что она напоминает? 

пятница, 6 января 2017 г.

Бриф Канемана "Думай медленно, решай быстро"

Книга на Озоне
1. Перегрузка информацией невыносима для мозга. Когда мы перегружаемся, мы фильтруем. Сильно фильтруем. И тогда шум становится сигналом.
2. Отсутствие смысла нас запутывает. И мы начинаем заполнять пробелы. Сигнал становится историей.
3. Нам нужно действовать быстро, иначе мы упустим шанс. И мы прыгаем к заключениям. Истории становятся решениями.
4. И тут все становится совсем сложно. Мы запоминаем только важные моменты. Решения определяют модели восприятия мира (mental models, cognitive framework).

Чтобы избежать информационной перегрузки, наш мозг строит схемы и фильтры. Так он может быстро обрабатывать большие объемы информации практически без затрат энергии. Так он решает, что из услышанного или увиденного на самом деле важно и вовремя вызвать в памяти нужный элемент схемы.

Чтобы найти смысл в отрывках информации, которые к нам приходят, мы заполняем пробелы и цепляем их к нашим моделям восприятия мира. И мы стараемся удержать целостность и стабильность этих моделей.

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

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

В чем проблемы?
1. Мы не видим всей картинки. Часть информации, которую мы фильтруем, имеет значение и важна.
2. Наши поиски смысла могут вызывать иллюзии. Иногда мы придумываем детали и предположения, которые создают несуществующий смысл.
3. Быстрые решения могут быть очень плохими.
4. Наша память усиливает ошибочное поведение. Некоторые вещи, которые мы помним, приводят только к большему отклонению от правильного поведения и ухудшают ситуацию.

https://en.wikipedia.org/wiki/Availability_heuristic
http://rationalwiki.org/wiki/Frequency_illusion

понедельник, 2 января 2017 г.

Дональд Трамп о системном лидерстве

Это вы. И ваши конкуренты. И рынок. Рынок постоянно движется. Вы должны быть быстрее конкурентов.
Это вы. А это ваши конкуренты. Много конкурентов.
Это ваш рынок. Много рынков. Ваши специалисты говорят, что быстро-качественно-дешево не бывает. Рынки уменьшаются и места для всех не хватает. Нужно постоянно искать свою нишу.

Как ее найти и как в ней удержаться? В этом помогает системный подход.

Почему он поможет? На самом деле вам не надо быстро-дешево качественно. Вам надо быстрее-дешевле-качественнее, чем у других.


И тогда вы сможете наслаждаться (почти) одиночеством.

Как к этому подойти?

Вчерашний подход к менеджменту говорил, что достаточно разбираться на один уровень внизСейчас уже надо владеть деталями. Всеми деталями. Абсолютно всеми деталями.
Что будет завтра?
Что по этому поводу думают инженеры?
Вчера у инженеров был постоянный конфликт с производством. Теперь у них конфликты со всеми. Проекты стали слишком сложными и слишком дорогими. Цена ошибки все время возрастает. Интересы специалистов, менеджеров, предпринимателей кажутся несовместимыми.
Но есть одна вещь, которая их объединяет - это продукт или услуга, которую бизнес оказывает клиенту
Системный подход позволяет вам смотреть на тысячи людей, их деятельность, оборудование и программы и четко понимать, как каждый кусочек этой головоломки участвует в создании продукта или услуги. 
И это доступно любому образованному человеку. Не хотите получить ярлык эффективного менеджера после непродуманной реорганизации или проекта по повышению эффективности? Не хотите стать инженером, который создал хайтек продукт, который не нужен никому?


Изучайте системный подход, приходите на тренинг
Меня зовут Турханов Саша и я эксперт :)