Традиционное и системное мышление

9 июля 2019 г. 3 min read

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

Перевод статьи Сезарио Рамоса Systems and traditional thinkers

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

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

«95 % проблем в бизнесе возникают на уровне систем и только 5 % на уровне людей».

Э. У. Деминг

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

Но что представляет собой система? Р. Л. Акофф предложил лучшее, на мой взгляд, определение:

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

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

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

Хм… И что теперь? Как применять системное мышление в разработке программного обеспечения?
Тестировщики улучшают процесс тестирования, разработчики улучшают написание кода, Скрам-мастера улучшают Скрам и так далее. Хорошо, а кто улучшает целое?.. Традиционные мыслители?
Как поможет такая локальная оптимизация? Мне это кажется улучшением частей по отдельности!

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

Традиционный мыслитель и системный мыслитель отличаются тем, как они думают и действуют. Тот же профессор Р. Л. Акофф пишет про аналитическое и синтетическое мышление. Он утверждает, что традиционное мышление — аналитическое. Если есть проблема, которую надо понять, раздели ее на более мелкие части, изучи эти части, построй понимание целой проблемы на основе понимания ее частей и на основе этого действуй.

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

Давайте продемонстрируем это на примере.

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

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

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

Разработка программного обеспечения — это система! Это часть более крупной системы, которая может быть продуктовой организацией, сервисной организацией или организацией другого типа. Поэтому нам надо относиться к разработке программного обеспечения как к самостоятельной системе, как к части более крупной системы. Только тогда можно устранить первопричины проблем и достичь долговременных улучшений.

Я закончу статью, как вы могли догадаться, мотивирующей цитатой Р. Л. Акоффа.

«В большинстве случаев в проблемах присутствуют циклические, а не линейные причины и следствия. В результате свыше 90 % проблем в корпорации лучше решать в другом месте, а не там, где они появились».

Р. Л. Акофф

Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.