Как организовать совещание с помощью OARRS

Objective/Outcome - Задача (в случае рабочей встречи) или Результат (в случае собрания)
Agenda - Повестка, пункты обсуждения
Roles - Роли участников
Rules - Правила проведения, полномочия участников, разрешение конфликтов и интермедиация
Structure - Структура, хронометраж, регламент пунктов повестки

Разберу пример с подготовкой к рабочей встрече (воркшоп, workshop). Допустим, к вам пришло письмо, что детский конструктор известной марки у вас в магазине стоит дороже, чем у конкурентов. Вы проверили ряд других позиций и обнаружили, что ситуация не единичная, и нужно решить эту проблему.

Шаг 1. Постановка задачи.
Если есть подходящая business motivation model (BMM), открываете ее, если нет, то разрабатываете/дорабатываете диаграмму под ситуацию. Ниже приведен небольшой кусок модели интересов:

Перечитываем внимательно письмо и вытаскиваем в отдельное описание затронутые интересы.Получаем:

Но все не так просто, поэтому заходим в "Анализ" каждого элемента модели, входящей в это описание и вытаскиваем связанные с ним интересы.

Получаем примерно это.

Приводим в порядок.

Из этого описания ясно, что для продуктивного обсуждения вопроса нам нужно не забыть учесть 15 интересов.

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

Для типовой организации в ритейле это будут:
1) Специалист по закупкам в данной товарной группе или категории, также выполняет роль категорийного менеджера
2) Бизнес-аналитик
3) ATL маркетолог
4) Специалист по обеспечению качества
5) Специалист по складской логистике
6) Менеджер контрольно-ревизионного отдела
7) Специалист по ценообразованию, выполняет роль ценового мониторинга

Определив стейкхолдеров, пишите им всем письмо. Вопрос, что писать? Есть два варианта корневой причины возникновения ситуации.
1) Что-то не то с целевой системой
2) Что-то не то с обеспечивающей системой

В случае варианта 1 смотрите на холон, см. недавний пост, идите вниз по холархиям.
В случае варианта 2 смотрите на архитектуру предприятия, что же в жизненном цикле не так.

Фактически, здесь происходит выявление требований к целевой системе (товару как части ассортимента) либо стратегирование (требования к практикам ценообразования и контрактации как части жизненного цикла).

Допустим, что в ходе предварительной переписки стейкхолдеры скорее сходятся в том, что проблема в ассортименте и надо его разводить с конкурентами, т.е. делать товарные позиции несравнимыми. Вы понимаете, что выявленные требования гармонизированы, а альфа стейкхолдеров плавно переходит в состояние "В согласии".

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

Шаг 2. Повестка
Возвращаемся к диаграмме интересов и стейкхолдерам. Озвучиваем тему обсуждения и спрашиваем, какие данные необходимы для продуктивного обсуждения вопроса. Запрошенный список отчетов должен быть готов и разослан за 1 день до встречи. Участники сообщают, что они хотят обсудить, эти пункты формируют повестку.

Второй способ разработки повестки - использовать любой стандартный подход.

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

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

Шаг 3. Роли
Здесь все просто, надо ознакомить участников с их границей ответственности, которая идет от интересов и полномочиями, которые идут от должности. Участники должны иметь очень конкретные ожидания от встречи. Рекомендую прямо спрашивать, а что же конкретно они будут делать в следующие 20 минут после этой встречи. На следующий день? Если конкретики нет, то ваше собрания под серьезным риском срыва.
Еще раз - все ожидания высказываются вслух, публично, до начала обсуждения. Как говорят финны "положите кошку на стол".
Бывают случаи, когда при обсуждении ролей, а чаще полномочий, появляются несогласные. Это хорошо, договоритесь о правах и обязанностях до старта обсуждения. Получите согласие стейкхолдеров по распределению ролей. Альфа "Стейкхолдеры" до старта совещания должна быть "В согласии".
По сложным вопросам должен быть фасилитатор или председатель собрания. Роль выделенная, человек не участвует в обсуждении плюс следит за исполнением правил, см. Шаг 4.

Шаг 4. Правила
Два важных раздела.
1) Механизм принятия решения. Демократический, авторитарный, авторитарно-консультативный, 2/3, простое большинство, двухступенчатая схема и т.д.
2) Правила ведения обсуждения. Можно или нельзя перебивать, задавать вопросы по ходу, дискутировать, нарушать регламент. Какие права у фасилитатора? В удаленных собраниях надо уточнять за что можно выключить микрофон и отключить от собрания, какие резервные каналы связи и протокол перехода на них, что делается при выходе участников из собрания (ждем или нет). Всегда обсуждается кто ведет протокол, будет ли стенографическая запись, будет ли видео и аудио запись, допускается ли особое мнение, будет ли оно протоколироваться. В какие сроки будет готов протокол, процедура внесения правок и дата окончательной готовности, порядок утверждения.

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

"Блин, да они все с разных планет"!

Шаг 5. Структура
Самое простое. Это хронометраж повестки. Председатель или протоколист следит за временем. Крайне, крайне рекомендую пользоваться

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

OARRS - Objective, Agenda, Roles, Rules, Structure. Ваш надежный чек-лист для проведения успешного собрания или встречи.

Архитектурная диаграмма подхода ПрОф2020

Новости по проекту Strategy Delivery Unit.

Разработал архитектуру метода, на выходных постараюсь написать эссе на тему. Т.к. во многом вдохновляюсь P2M и MSP, но чтение этих стандартов еще не завершил, архитектура может меняться.

Трекер для управления проходом или управления выживанием проекта?

Пост родился из обсуждения:

Victor Erukhimovich Не уверен, что не офф-топ... если я правильно понимаю, о чем вообще тут речь, конечно. А насколько в принципе освещена тема трекинга задач с плавающей постановкой?

Like · Reply · 1 · 8 hrs

Alex Turkhanov На всяких ивентах, посвященных адаптивному кейс менеджменту вполне себе тема обсуждается несколько лет и проработана. Плюс, Эджайл. Alexey Deryushkin есть, что на эту тему?

Like · Reply · 1 · 8 hrs

Alexey Deryushkin Alex Turkhanov, где задачи не меняются, там и word сойдет. :) Я вообще плохо представляю , как в условиях неопределенности или нестабильности управлять чем бы то ни было без трекера.

Есть примеры применения оного, например, в банках НЕ в ИТ, а в ритэйле.

Like · Reply · 1 · 8 hrs

Alex Turkhanov Так а теория в виде книжек и статей есть? Или все в устной традиции только?

Like · Reply · 8 hrs

Victor Erukhimovich Alex Turkhanov Аджайл, кстати, тоже не отвечает на этот вопрос. Вернее, отвечает не идеально. Пример (из жизни) - разработка ИТ-решения на новой платформе, по которой еще нет статистики, для бизнес-процессов, по которым еще никто не работал. Соответственно, начинается все с прототипа. Изначальное допущение - что прототип будет сделан в результате последовательности задач 1 и 2, каждая размером в один тайм-бокс. Но по завершении первого таймбокса становится ясно, что задача 1 на самом деле состоит из 5 подзадач по таймбоксу каждая, то есть прогресс из 100% сползает в 20%. Или вообще случай (Андрей знает) - проект по бизнес -оптимизации, когда в стратегической фазе определили ряд инициатив, а потом на фазе внедрения заявленный эффект был достигнут, но с помощью почти непересекающегося списка альтернативных инициатив. То есть - прогресс по проекту - 100%, хотя прогресс по большинству задач - 0%. То есть, когда мы треким прогресс, мы треким задачи, про которые мы еще не знаем, что они не релевантны, про которые мы уже знаем, что они не релевантны, про которые мы еще не знаем, что оценка эффорта не соответствует действительности, и про которые мы уже знаем это. И в эту картину мира еще добавить зависимости от смежных проектов и субподрядчиков :) Мой скудный опыт пока не придумал ничего лучше, чем трекить относительно текущего снапшота плана/оценок, а снапшот обновлять по-возможности каждую неделю (что, в принципе, относительно легко встраивается в еженедельную агенду по управлению RAID). Что остается за кадром пока - оценка процента, на который можно доверять собственно текущему снапшоту, и управление ожиданиями стейкхолдеров, которые норовят каждый снапшот воспринять как истину в последней инстанции... вот если есть какие-то техники, адресуюшие этот букет проблем - было бы очень интересно послушать! Или почитать :)

Like · Reply · 6 hrs · Edited

Alexey Deryushkin Alex Turkhanov, не знаю, книжек-статей именно по применению трекеров вне ИТ не искал. JIRA в Райффайзенбанке не для ИТ ставилась, знаю. Свечку не держал.

Like · Reply · 6 hrs

Alexey Deryushkin Victor Erukhimovich, нормальная такая ситуация, жизненная. :) Звучит так, как будто по задачам definition of done был не очень корректно сформулирован, или декомпозиция неверно проведена. 

Если DoD определен хорошо, и декомпозиция задач по модели invest, то можно вполне предсказуемо работать с метриками kanban или вообще банальным burn-down chart. В ситуации "все с нуля" стартовую точку надо будет тщательно выбрать, чтобы не 5-6 итераций набирать статистику, а 3-4.Like · Reply · 6 hrs

Alex Turkhanov Наблюдаю путаницу с throughput management и project progress tracking. Это разные темы. Похоже, надо написать вечером про OMG Essence и alpha states tracking.

***

Разберем ситуацию с позиций OMG Essence kernel http://www.omg.org/spec/Essence/1.1/

Kernel – это функциональная (т.е. не привязанная к конкретным методам и практикам) системная схема проекта, описывающая целевую, использующую, обеспечивающую систему и пару стейкхолдеры-требования.

В kernel есть всего три основных понятия:

Alphas – representations of the essential things to work with. The Alphas provide descriptions of the kind of things that a team will manage, produce, and use in the process of developing, maintaining, and supporting software and, as such, are relevant to assessing the progress and health of a software endeavor. They also act as the anchor for any additional sub-alphas and work products required by the software engineering practices.

Activity Spaces – representations of the essential things to do. The Activity Spaces provide descriptions of the challenges a team faces when developing, maintaining, and supporting software systems, and the kinds of things that the team will do to meet them.

Competencies – representations of the key capabilities required to carry out the work of software engineering.

Каждый из семи основных функциональных элементов схемы называется альфой, и у него есть поведение – он перемещается по Activity spaces.

Для продвижения альф по состояниям activity spaces в каждой области нужны определенные компетенции.

Состояние альфы определяется чек-листом.

По разному распределяя состояние альф между стадиями проекта, можно получать различные модели жизненного цикла:

***
Трекер, как технология, используется в двух практиках:
1) Управление проходом, наиболее часто используемая, это то, о чем пишут в исходном обсуждении

• "по которой еще нет статистики, для бизнес-процессов, по которым еще никто не работал. Соответственно, начинается все с прототипа. Изначальное допущение - что прототип будет сделан в результате последовательности задач 1 и 2, каждая размером в один тайм-бокс. Но по завершении первого таймбокса становится ясно, что задача 1 на самом деле состоит из 5 подзадач по таймбоксу каждая, то есть прогресс из 100% сползает в 20%. " 
• "То есть, когда мы треким прогресс, мы треким задачи, про которые мы еще не знаем, что они не релевантны, про которые мы уже знаем, что они не релевантны, про которые мы еще не знаем, что оценка эффорта не соответствует действительности, и про которые мы уже знаем это. " 
• "Если DoD определен хорошо, и декомпозиция задач по модели invest, то можно вполне предсказуемо работать с метриками kanban или вообще банальным burn-down chart. В ситуации "все с нуля" стартовую точку надо будет тщательно выбрать, чтобы не 5-6 итераций набирать статистику, а 3-4"

2) Управление выживанием проекта (это как раз очень условно и ограничено соответствие снапшота или, в традиционном ПМ БОК изложении "базового плана" реальному положению дел). Другими словами, насколько текущее состояние проекта соответствует плановому состоянию дел, с использованием заявленного на старте проекта метода.

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

Ответ на поднятую проблему "как без процентов оценить прогресс проекта?" - использовать kernel. Прогресс проекта - это продвижение альф по activity spaces, а не процентное выражение выполненных работ по сравнению с запланированным.

Конкретика будет позже, но пример чек-листа на прохождение контрольной точки могу дать прямо сейчас:
Контрольная точка КТ1 «Проект запущен»
(подальфа "Архитектура работ" Работ, состояние "Архитектура предопределена")
Подзадачи:
1) Спонсор согласовал цели по SMART, задачи и продукт проекта.
2) Заказчики проекта определены, их требования и ожидания собраны и согласованы со спонсором.
3) Проект разбиты на фазы, основные контрольные точки проекта, текущие и целевые значения проектных KPI определены и согласованы со спонсором и заказчиками.
4) Компетенции и ресурсы, необходимые для начала реализации проекта, определены, спонсор и заказчики подтвердили выделение этих ресурсов на проект.
5) Проект согласован заинтересованными сторонами.

• Презентация на совещание по запуску проекта готова, согласована со спонсором и заказчиками
• Ресурсы согласны со своими обязанностями и сроками выполнения задач в своей зоне ответственности.

6) Кик-оф организован.

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

7) Лидер проекта поставил проект на контроль.

• Внес контрольные точки проекта в трекер и календари команды, 
• Добавил выделенные на проект ресурсы в трекер, назначил им первые задачи из плана работ
• Организовал еженедельное собрание с командой по обзору хода проектных работ.

8) Лидер проекта регулярно отчитывается спонсору и проектному офису о ходе работ проекта, используя трекер и чек-листы контроля проекта.
9) Лидер проекта организовал детальное планирование проекта. В результат планирования входят:

• структура результата проекта 
• диаграмма создания результата
• сетевой график
• детальный бюджет по статьям с подтверждением расходов бюджетодержателями
• план по рискам. 

10)Сроки контрольных точек уточняются, работа систематически ведется и отслеживается в трекере.
11)Подготовить план коммуникаций проекта.

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

Здесь, конечно, уже есть элементы метода, т.к. для функциональных компонент заданы модули-оргпроцессы, но какое-то представление получить можно.

Фактически, для отслеживания здоровья проекта надо создать в трекере workflows и загнать туда альфы и граф состояний с чек-листами с выводом индикации на панель. Тогда он будет с одной стороны отслеживать проход (throughput), а с другой будет доступна оценка прогресса командой всех ключевых аспектов проекта.

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

Про компоненты-модули-размещения. Просто.

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

Все часы устроены одинаково. У них есть задающий элемент, который отсчитывает одинаковые промежутки времени, допустим, секунды, есть счетный элемент, который из 60 секунд считает минуту, из минут считает часы, дни, недели, месяцы и годы. Так, один раз задав правильное время, можно всегда иметь его с собой. Постойте, ведь это правильное время надо задать, значит, у нас должен быть элемент, который регулирует точку отсчета – это будет установочный регулятор. Отлично, теперь мы имеем всегда точное время. Осталась лишь небольшая проблема, мы его не видим, нам нужно табло, индикатор, который покажет, сколько сейчас минус, секунд, часов, какой сейчас день недели и месяц-год. Все прекрасно, почему же часы не ходят? Нужен источник энергии, что система заработала. И защитный элемент, чтобы с этими часами можно было выходить за стены часовой мастерской или лаборатории.

Посмотрим, что у нас получилось:

Это функциональное разбиение системы «Часы».

И если нас спросят, как работают часы, мы легко нарисуем:

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

Задача. Какой компонент пропущен на функциональной схеме? Как он должен быть соединен с другими компонентами?

Теперь мы понимаем, как работают часы вообще, но это всего лишь схема, которую надо реализовать на практике. Часы бывают разные – электронные, механические, кварцевые. В чем их отличие? Правильно, в конструкции. В часах всех типов есть указанные выше компоненты, но практическая реализация функциональной схемы будет каждый раз разной. В механических часах источником энергии является взведенная пружина, в кварцевых и электронных – батарейка. Задающий элемент может быть маятником, а может быть кварцевым генератором, время мы можем посмотреть на циферблате с часовой и минутной стрелками либо на жидкокристаллическом экране или OLED. Элементы конструкции, которые реализуют функцию, называются модули. Часто бывает, что одному компоненту соответствует один модуль, но не всегда. Допустим, в телефонах экран состоит из множества модулей (в нем есть защитное стекло, тачскрин, сигнальные разъемы и многое другого), а выполняют они всего одну функцию – показывают изображение. И наоборот, в том же телефоне есть процессор, который является одним модулем, но выполняет множество функций, то есть выполняет роль многих компонентов.

Конструкция показывает, как мы реализуем функцию системы, и хотя в системе нас интересует в первую очередь функция, потому что какая разница, как устроен телефон, если по нему нельзя звонить и какая разница, какой конструкции часы, если они не показывают правильное время, конструкция все же очень важна.

Теперь представим ситуацию, когда мы взяли и в механических часах чуть-чуть, на какую-то долю миллиметра сместили шестеренку. Что будет? Часы перестанут ходить. В чем дело? Ведь функциональная схема и конструкция не изменилась – все модули присутствуют. Мы изменили расположение. Оказывается, в системе модули могут исполнять свои функции только в определенных расположениях. Батарейка, например, должна быть вставлена в телефон и между клеммами батареи и контактами телефона не должно быть зазора. Даже обычные скрипы и люфты при сборке телефона обычно приводят к тому, что мы считаем такой телефон непригодным, хотя звонить по нему можно. Это третий кит, на котором держится система – расположение. К расположениям также относятся и место работы системы. Согласитесь, телефон, который должен работать на Северном полюсе или в глухой тайге, будет совсем-совсем другим, чем тот, с которым можно посидеть дома с вай-фай и поиграть в Plants vs Zombies.

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

Холон розничной сети и его использование для ситуационной инженерии метода программного и проектного управления

Релиз 0.9:

Вся эта деятельность с выделением холона была не просто так. Холон является точкой отсчета для целеполагания программ и проектов. Учитывая, что моей целью является создание метода программного и проектного управления, не требующей профессиональных проектных управляющих, этот метод должен создаваться и подстраиваться под конкретный бизнес. Тогда в нем могут ориентироваться "обычные" менеджеры.
Как пользоваться этой схемой?
1) Определяетесь, какой проект вам нужен.
2) Выбираете нужные части.
3) Выявляете, каких стейкхолдеров затрагивает изменение этих частей (справочник стейкхолдеров и интересов на подходе).
4) Прописываете для каждого элемента состояния "Как сейчас" - "Как потом", пишите обоснования каждого изменения либо с помощью методов целеориентированной инженерии требований (примеры будут) либо с помощью дерева будущей реальности.
5) Дальше все как обычно - сбор требований, определение подхода к планированию и т.п.
6) Параллельно адаптация типовой схемы Ритейл Эссенс (частично выложу на днях) под конкретные потребности этого проекта.
7) Кик-офф и полетели. Проектный менеджмент используется для управления границами проектных фаз (управление выделениями ресурсов) и прогнозирования business case feasibility and realization, Ритейл Эссенс для оценки прогресса проекта и его рисков.

И это пока безо всяких наворотов типа байесовских сетей и даже без адаптивного кейс-менеджмента, хотя уже и с заходом на него.

Как вы хОлон зададите, так и бизнес поплывет

Рассмотрю очень упрощенный пример безликого ритейла с оптовым каналом продаж и простым сервисом «Заплати и забери» (Click and collect).

Купивший у нас клиент – это главное. Чем больше покупка, средний чек, конверсия или коэффициент обслуживания, чем больше пенетрация дестинейшен категории в чеки, тем лучше. Вся классика ритейла ориентирует организацию на продажи товара. Совершившаяся продажа или закрытая сделка это та ось, вокруг которой все крутится. Если посмотреть на типовые отчеты, на которые смотрят менеджеры, то все они будут указывать на покупки клиентов. Давайте взглянем:

• товарооборот по магазинам, по регионам и в целом по сети
• продажи по товарным группам в денежном и штучном выражении
• маржинальность продаж по магазинам и по товарным группам
• средний чек
• количество позиций в чеке

и т.д.

А для кого это делается? Простой вопрос с простым ответом – для клиентов. Они высказывают свои потребности, например «хочу стильную зимнюю одежду и чтобы не очень дорого», выдают требования «куртка до 15 тыс., чтобы не пачкалась, защищала от дождя и не пропускала ветер». Иногда даже задают ограничения «только гортекс и только последний модельный год». И мы, поискав на стеллажах, находим решение и поставляем его клиенту. Он производит проверку, покупает, и потом уже, дома или на горном склоне производит приемку. Иногда они возвращаются и это может быть как фильмом ужасов, так и прекрасной французской комедией. В конце концов, товар становится непригодным, и выбрасывается, система прекращает свое существование.

На базе этого холона строим модель жизненного цикла:

В PDF

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

Что делать? - Менять точку зрения на бизнес, парадигму мышления, как это ни назови, но меняй холон!

Продолжение следует.
Update по результатам обсуждения в ФБ:

Что такое системное мышление и зачем оно нужно?

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

Например, для того, чтобы построить самолет, нужна скоординированная работа 400,000 людей тысяч разных специальностей. Даже обычный телефон - это плод труда тысяч и тысяч инженеров, менеджеров, бухгалтеров и рабочих на фабриках. И самолетами и телефонами пользуются сотни миллионов людей и подавляющее большинство довольны. Это и есть работа системных инженеров.
Есть много разных школ системной инженерии, но в основе любой из них лежит системное мышление. Системное мышление - это ядро, основа любого системного метода.
Самолеты и атомные станции делали и раньше, что такого в системном мышлении? - Сейчас мало сделать сложную работу, надо, чтобы в ходе выполнения были учтены сотни противоречивых интересов. Приведу пример. Построенная автомобильная дорога должна устраивать по качеству государственную инспекцию, автомобилистов и водителей фур. При этом автомобилисты не должны ругаться на высокую стоимость транспортного налога и цен на бензин, из которых наполняются дорожные фонды, из которых строится эта дорога. Работу в системно организованных проектах принимает не только "Представитель Заказчика", но и сотни и тысячи других людей, на которых совсем никак нельзя повлиять. Именно поэтому у нас и появились дешевые и качественные автомобили и телефоны. А не у нас еще и дороги и медицина.

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

Как конкретно системное мышление помогает организовать людей? - Системные инженеры используют для организации деятельности мега-модель. Это компьютерное описание предмета коллективной работы, рассматривающее все аспекты всех работ. Да, вы не ошиблись, для самолета эту будет 400 тысяч описаний и скорее даже 40 миллионов. Именно поэтому это называется мега-модель, она очень большая.
Ну хорошо, есть у вас мега-модель, и что? - Теперь все 400 тысяч людей могут договариваться, работая с описаниями из этой модели. Им не надо строить самолет или телефон, чтобы понять, что разные части их работы сошлись и смогут успешно работать вместе, это видно из мега-модели. Находить и устранять ошибки в мега-моделях намного дешевле ,чем в реальных системах. В проекте за 10 миллиардов долларов 3 миллиарда потратят на создание и работу в мега-модели.

Ничего не понял. - Все знают, что слона едят по частям. Для выполнения сложной работы ее надо разбить на маленькие куски и раздать ее людям. Это называется разбиением. Инженеры разбивают на части продукт, и получают структуру продукта или структуру изделия, менеджеры разбивают на части работы или капитал, и получают иерархическую структуру работ (WBS, work breakdown structure) или бюджеты. Долгое время люди обходились небольшим количеством разбиений в своих проектах, но по мере роста сложности проектов классические устоявшиеся методы работы, которым учили и до сих пор учат в бизнес-школах, создавали все больше проблем. Например, структура бюджета и разбивка работ во время разработки проекта электростанции совсем не подходит для структуры бюджета и разбивки работ при эксплуатации и обслуживании этой же самой электростанции во время ее работы. Это приводило к взрывному росту так называемой проблемы "конструктор против технолога" или "белые воротнички и синие воротнички". Самая частая фраза "напроектировали тут такое, что сделать невозможно". Добавлю, что не только сделать, но дальше и ездить на этом, и ремонтировать тоже удовольствия мало.

А что вы хотели, так устроена жизнь, нет единственно верного взгляда! - Конечно нет, о чем и говорят в системном мышлении. Все взгляды всех участников тщательно выявляются, записываются, а интересы учитываются во время проектирования и создания системы. В этом отличие современного системного мышления от других управленческих систем - счастья для всех, задешево и чтобы никто не ушел обиженным.
Подождите, как можно учесть мнение 400 тысяч людей, которые все это будут делать, да еще и 400 миллионов, которые будут всем этим пользоваться? Единственный способ - это делать и пробовать. - Вы же пользуетесь айФон или другим телефоном? Вы ездите на автомобилях, летаете на самолетах, читаете сейчас этот текст с компьютеров. Вас же все устраивает, по большей части? Так что это возможно, хотя и совсем не просто. А пробовать надо в мега-модели, это намного быстрее и дешевле.
Мне эти мега-модели не потребуются, я бухгалтер/юрист/строитель/придумайте сами. - Возьмите бумагу с ручкой и опишите, какой была ваша работа 15 лет назад. Что вы делали и какие инструменты использовали. Сравните с тем, что и как вы делаете сейчас. Даже если вы работаете охранником на автомобильной стоянке, в вашей работе многое изменилось. А если вы инженер, то изменилось много раз. Сейчас уже нельзя игнорировать того, что хотят другие люди, нельзя просто приказать, что "автомобиль будет черного цвета", у вас его просто не купят. Надо уметь работать в больших коллективах, надо уметь быстро переключаться между проектами и задачами. Наши текущие приемы мышления просто не приспособлены для этих задач. Пока системное мышление наиболее дешевый из имеющихся у цивилизации способ ответа на все эти вызовы.
Универсальных знаний нет, деньги платят только за реальный опыт. - Математика и хорошая разговорная и письменная речь - типичные примеры универсальных навыков. Что бы ни случилось, где бы вы не работали, они вам пригодятся. Им долго учиться, вспомните себя или знакомых детей, их невозможно "взять из жизни", но они пригодятся вам на любой работе. Системное мышление и есть такая новая грамотность, которая пригодится везде.
Хорошо, убедили, надо делать мега-модели. Где этому учат? - Приготовьтесь к длительной учебе. Это особый вид мышления, сильно отличающийся от обычного, бытового мышления. Ему надо долго и целенаправленно учиться, но после этого вы сможете применять этот инструмент к большинству жизненных ситуаций, в какой бы компании, учреждении или проекте вы не оказались и какие бы технологии не использовали.
Если вы хотите стать системным инженером, то можно поехать в УрФУ
http://urfu.ru/priem/magister/instituty/hes/sistemnaja-inzhenerija/
Либо ехать за рубеж, в большинстве крупных университетов есть такая специальность, и зачастую не одна.
Конкретно системному мышлению учат в Школе системного менеджмента http://system-school.ru/

А можно начать с производственного романа про жизнь системных инженеров.