Давайте поговорим о практическом применении одной очень интересной темы – системного мышления.
В системном мышлении существует множество принципов и методов; Очень рекомендую прочитать соответствующую литературу.
Например, просто и интересно.
книга .
Сегодня мы коснемся лишь одного принципа – эмерджентности, или возникающих свойств систем.
Расскажу о теории и самое главное о практических аспектах применения.
В нашей жизни — программисты, разработчики, архитекторы, аналитики и менеджеры проектов.
Однако сначала немного теории.
Системы и свойства
На работе мы почти всегда имеем дело с системами — сложными совокупностями людей, процессов, отношений (формальных и неформальных), видимых и скрытых лидеров, физических объектов, информационных систем, клиентов, поставщиков, оборудования и т. д., до бесконечности.Если перед вами все элементы, вы их знаете или даже видите - например, собрали все это в одном месте - то перед вами не система, а набор элементов.
.
Просто много деталей.
Как из этой кучи сделать систему? Вам необходимо расставить элементы на свои места и включить их – запустить систему в работу.
Это хорошо понимают обычные программисты или инженеры.
Вот код программы, вот компьютер или сервер, вот входные данные для обработки.
Нажимаешь ON и система работает. Ну или не сработало, если в нем была ошибка.
В системах, состоящих из людей, обычно все наоборот, и это различие является ключевым.
Системы, состоящие из людей, работали до вас и будут работать после вас.
Но они не будут работать с тобой , в вашем присутствии.
Фактически в вашем присутствии они перестают быть системами и вновь превращаются в набор элементов.
Возвращаясь к примеру выше, когда вы собрали всё и все элементы системы в одном месте.
Что вы наделали? Ты выключен система.
В чем разница между включенной и выключенной системой? Люди вроде те же, должности те же, процессы те же, руководитель тот же – все на месте.
Разница заключается в свойствах системы, которые проявляются только тогда, когда она «включена», т.е.
когда система работает. Примеры таких свойств систем есть повсюду, вы легко их найдете.
Телевизор без электричества – это выключенная система, которая не демонстрирует нам своей основной функции – показывать изображение.
Включите телевизор – увидите изображение, появится функция.
Если вы плеснете воду на работающий телевизор, вы увидите новое свойство системы, о котором, возможно, даже не подозревали.
Такие свойства системы называются возникающий , или возникающий .
Они возникают, когда система собирается из набора элементов и включается.
Важны оба условия – и он собран, и он включен.
В нашем случае - когда не выключается.
Итак, наша задача — понять систему, чтобы впоследствии изменить ее.
Как понять систему?
Не выключай
Это очень просто – смотрите, не выключая.Точно так же, как мы отлаживаем код — мы включаем его и смотрим, что происходит. В принципе, глазами можно отладить код, но на распечатке — помните, в институте «листинг программ»? Но, похоже, мало кто так делает. Системы, которые мы создаем, слишком сложны.
Есть масса зависимостей, которые не то чтобы находятся вне нашего контроля, но возиться с ними при отладке — дело неблагодарное.
С обычными, некомпьютерными системами дела обстоят еще сложнее.
Никакого "перечня" нет. Представьте, как весело было бы работать с «человечными» системами, если бы был флажок «Пауза при обнаружении исключений»? Как мы обычно выключаем систему:
- Мы общаемся с сотрудниками индивидуально
- Мы общаемся со всеми сотрудниками сразу
- Приглашаем всех на неформальное мероприятие
- Делаем запрос сотрудникам, ставим задачу, просим отчет
- Опишите, пожалуйста, их деятельность, или напишите бизнес-процесс.
- Сбор менеджеров на встречу
- Спрашиваем бывших сотрудников, как работает система
- И т. д.
Шерлок Холмс прекрасно справился с такого рода работой; он назвал это дедукцией — понять картину по отдельным деталям.
Правда, другого выхода у него не было — нельзя было просить преступника повторить преступление в присутствии гения сыщика.
У нас ситуация проще, и мы имеем возможность наблюдать работающие, неизмененные системы.
Лучший метод, конечно, — постоянно присутствовать в системе, быть ее частью и в то же время наблюдать за ней на расстоянии.
Это, например, путь Скрам-мастера.
И, по определению, роль непосредственного руководителя.
Если, конечно, он вместо работы не бегает на встречи.
Похожий пример – тренер, например, футбольной команды.
Там наблюдение за системой в действии во всей ее мощи является частью работы.
Что делать нам, офисным работникам, разделенным перегородками, офисами, а иногда и континентами? Осуществлять скрытое наблюдение лично или с использованием технических средств.
Наблюдение
Личное наблюдение не всегда возможно; все зависит от вашего положения относительно наблюдаемой системы.Если вы работаете в организации, вы можете просто разместить свое рабочее пространство там, где находится система — люди, взаимодействие которых вы хотите понять.
Поначалу вы будете посторонним элементом, отключающим систему.
Но постепенно они привыкнут к вам и перестанут обращать на вас внимание.
Чтобы быстрее к вам привыкнуть, сделайте вид, что вас не особо интересует то, что происходит вокруг вас.
Вы можете сделать вид, что увлеченно работаете за компьютером, надеть наушники и включить музыку – но тихо, чтобы слышать, что происходит вокруг вас.
Не делайте вид, что слушаете разговоры.
Точнее, сделайте вид, что вы не слушаете разговоры.
Я думаю, ты поймешь, как вписаться в себя.
Если в вашей команде есть люди, которым было бы проще присоединиться к системе, то вы можете отправить их, дав четкую инструкцию.
Вы можете использовать различные инструменты для отслеживания действий людей в системах .
Вы не увидите всю систему таким образом, но, по крайней мере, узнаете, используют ли люди ваши инструменты или нет. На словах говорят одно, а на деле другое.
Практика показывает, что 2-5 дней обычно достаточно, чтобы получить представление о системе.
Это будет не предельно точная картина, а набросок, дающий общее, целостное видение системы.
Эскиз впоследствии можно будет дополнять деталями, без использования наблюдения.
Например, дополнить данными проверки гипотез, данными контролирующих систем и т. д. Интересно то, что наблюдение помогает развивать способности к прогнозированию.
Прогнозирование помогает на основе опыта и знаний о поведении систем быстро понять, какие методы и изменения будут работать и приносить результат, а какие нет. Это еще одно применение системного мышления и эмерджентных свойств систем, которые мы обсудим ниже.
В результате мониторинг работающей, не выключенной системы — отличный метод, который сложно чем-либо заменить.
Наблюдение помогает увидеть систему максимально точно, беспристрастно и объективно, без интерпретаций.
Любой другой вариант - интерпретация , или проекция в определенной системе координат. Особенно, если вы спросите о системе у ее менеджера (как чаще всего и происходит).
Это касается не только работы программиста, но и повседневной рутины управления.
На самом деле в этом подходе нет ничего нового; он часто используется в определенных областях.
Например, в сфере розничной торговли и услуг используются тайные покупатели — люди, которых целенаправленно отправляют в магазин, гостиницу и т. д., чтобы они могли увидеть систему в действии такой, какая она есть.
Новым в этом подходе является его использование в работе обычного предприятия, обычно не связанного с розничной торговлей – производства, например.
Берем старый известный метод и находим новое применение.
Прогнозирование
Теперь о прогнозировании.В работе программиста часто возникает ситуация, когда нужно спрогнозировать успех того или иного проекта.
Обычно речь идет о проектах внутреннего организационного развития компании.
Проще говоря, о проектах изменений.
Обычно спрашивают о чужих проектах — тех, в которых бизнес-программист не участвует. Те.
о проектах, выполняемых не по правилам бизнес-программирования, а по правилу «как могу».
Бизнес-программист, бегло изучив информацию о планируемом проекте, обычно говорит, что ничего полезного из этого не выйдет. Или вообще ничего не получится.
Разница очевидна – проект может быть выполнен успешно, в срок и в рамках бюджета, но не принесет компании никакой пользы.
Высказанное мнение, т. е.
прогноз бизнес-программиста, обычно вызывает негативные реакции – депрессию, гнев, неприятие, «кто тыЭ», «актерство».
Бог на Земле, что лиЭ» и т. д. Негативная реакция усиливается, когда прогноз сбывается, и сбывается он очень часто.
Однако не все так печально, и постепенно люди начинают привыкать к этой «сверхспособности» бизнес-программиста и даже адекватно использовать ее на благо компании, либо своей собственной.
Некоторые даже записывают свои прогнозы – блокнот, в котором отмечают галочкой «он был прав».
Например, у двух моих коллег-менеджеров был такой блокнот. Я не знаю, правда это, виртуально или реально.
Теперь давайте разберемся, как бизнес-программист делает такие прогнозы.
Откуда берутся прогнозы?
Все дело в использовании знаний о поведении систем.Проект изменений всегда содержит как минимум две системы: изменяемую и изменяемую.
Сменный - что мы собираемся улучшить .
Бизнес-процесс, работа отдела, взаимодействие функций и т. д. Назовем ее изменить объект .
Изменение - тот, кто придумывает, внедряет и внедряет изменения .
Проще говоря, команда внедрения изменений.
Давай позвоним ей предмет изменения .
Обе системы состоят из набора элементов и связей между ними.
Это люди, информационные системы, цели, формальные и неформальные отношения, модель управления, подходы к управлению, силы влияния и т. д. В предмете, т.е.
проекте и команде изменений, есть конкретные элементы – алгоритм выбора реализуемых методов, цель и мотивация руководителя проекта и команды, методология внедрения, принципы управления проектом, управленческие подходы к оценке хода и результатов проекта.
проект, планы команды на жизнь после проекта, выбор решаемой проблемы и т.д. Никто, даже самый опытный бизнес-программист, не может достоверно увидеть все элементы и связи.
Но каждый видит определенную часть — руководителя проекта внедрения, руководителя компании и всех окружающих коллег.
Однако именно бизнес-программист дает наиболее точный прогноз.
Все смотрят на одно и то же.
Они видят объект, они видят предмет, план проекта, ресурсы, окружающую среду.
Но прогноз радикально иной.
Почему? Ответ очень простой и даже скучный: бизнес-программист учитывает историческая информация .
Историческая и статистическая информация о поведении подобных систем.
Результатом проекта внедрения изменений является комбинации две системы - объект и субъект. Если системы совмещены неправильно, результат будет отрицательным.
Если начат новый проект изменений, но системы объекта и субъекта остались практически неизменными, то результат с высокой вероятностью будет схожим.
Одни и те же люди пытаются внедрить один и тот же метод в том же отделе.
Есть множество примеров.
Если вы системно посмотрите на историю внедрения изменений в вашей компании, вы увидите подтверждение этой закономерности.
Вы также можете поискать примеры на улице; теперь система в самый раз - называется "зимняя".
Зима + город + эти люди, как их зовут, которым приходится расчищать снег.
Годы идут, а результат тот же.
Потому что все системы на месте, никаких изменений.
Ах да, бывает зима без снега - тогда результат вполне хороший.
Но чье оно? Самое сложное в этом подходе – определить есть различия в системах или нет. Для этого необходимо научиться ранжировать элементы и связи системы по важности – выделять ее ключевые, системообразующие элементы и связи.
Единого рецепта здесь нет, вариантов много.
Есть, например, метод 7S, созданный McKinsey, который разбирает систему на 7 частей.
Лично я предпочитаю себя не ограничивать, иначе могу просмотреть что-то новое для себя.
Понять ключевые элементы можно интуитивно, но нужно перепроверить себя, потому что.
Качество интуиции зависит от вашего текущего уровня развития как бизнес-программиста и может вас обмануть.
Выделение ключевых элементов позволит вам сделать прогноз быстрее, не углубляясь в детали и не изучая шум.
Вы просто видите, что ключевые элементы обеих систем остаются на своих местах, и можете быть уверены, что результат с высокой вероятностью повторится.
Чем чаще вы будете выполнять это упражнение, тем быстрее будут развиваться ваши навыки и тем точнее станут ваши прогнозы.
В нашей стране есть такое популярное выражение – «хотели как лучше, а получилось как всегда».
Теперь, прочитав это, понимаешь, что здесь чего-то не хватает. Правильнее было бы сказать «хотели как лучше, поступили как всегда, и вот результат…».
Пример такого подхода я видел у нашего министра иностранных дел Сергея Лаврова.
На пресс-конференции после встречи с госсекретарем США Рексом Тиллерсоном Лавров заявил: «Что касается конкретной проблемы Сирии, в частности Б.
Асада, то сегодня мы обсуждали исторические экскурсы, и Р.
Тиллерсон сказал, что он новый человек и предпочитает не углубляться в историю, а заниматься сегодняшними проблемами.
Однако мир таков, что если мы не будем учиться на уроках прошлого, мы вряд ли добьемся успеха в настоящем».
Затем Лавров перечислил несколько примеров - сочетания объектной и субъектной систем, с одной и той же целью субъекта - внедрение модели демократии через свержение диктатора.
НАТО и Ирак, НАТО и Ливия.
И он предсказал результат объединения систем НАТО и Сирии.
Пока что Лавров кажется правым.
Теги: #Популярная наука #Карьера в IT-индустрии #Управление проектами #Управление персоналом #Анализ и системное проектирование #системное мышление
-
Кто Хочет Получить Платный Онлайн-Опрос?
19 Oct, 24 -
Предскажи Будущее, Хабраман
19 Oct, 24 -
Hascgi Или Общедоступные Пароли
19 Oct, 24 -
Визуальный Контент Для Email-Рассылок
19 Oct, 24
