Системное мышление — фундаментальная часть бережливого производства программного обеспечения. Системный взгляд и системное понимание организации позволяет улучшить ее неожиданным для вас образом. Системное мышление помогает работать с комплексными системами, например, системой с участием людей.
Системный мыслитель признает, что большинство проблем в разработке программного обеспечения возникает в системе, в которой работают люди. Проблемы по своей сути системны!
«95 % проблем в бизнесе возникают на уровне систем и только 5 % на уровне людей».
Э. У. Деминг
Предполагается, что лучший способ решить проблему — сделать так, чтобы она не возникла вновь, а для этого нужно переструктурировать систему, т. е. изменить способы работы и взаимодействия. Это также означает, что если вы сосредоточились на улучшении людей и способов их работы, вы, скорее всего, работаете не над теми вещами.
Но что представляет собой система? Р. Л. Акофф предложил лучшее, на мой взгляд, определение:
«Система — это целое, состоящее из многих взаимозависимых частей. Каждая система — часть более крупной системы, и ее роль или функция определяется большей системой. Свойства системы проистекают из взаимодействия ее частей, а не отдельных действий каждой части».
Что вообще это значит?! Во-первых, это означает, что чтобы улучшить систему, в которой мы работаем, не достаточно просто оптимизировать ее части. Оптимизация отдельных частей приведет к ухудшению производительности системы. Мы улучшаем или ухудшаем производительность какой-либо части, только если это ведет к улучшению производительности или способствует достижению целей системы в целом. Поэтому, чтобы улучшить систему, нужно понять ее цель и выявить, что делают ее части и какую функцию они выполняют или должны выполнять в составе целого.
Это также означает, что систему нельзя разделить на отдельные части. Если вы все же разделите систему на составные, то система как единое целое и все ее части теряют свои основные свойства и в результате не смогут работать и выполнять свою цель.
Хм… И что теперь? Как применять системное мышление в разработке программного обеспечения?
Тестировщики улучшают процесс тестирования, разработчики улучшают написание кода, Скрам-мастера улучшают Скрам и так далее. Хорошо, а кто улучшает целое?.. Традиционные мыслители?
Как поможет такая локальная оптимизация? Мне это кажется улучшением частей по отдельности!
Сколько раз вы «улучшали» что-то в организации, но улучшения держались очень недолго? Что насчет быстрых результатов, которые позже приводили к обратному эффекту! И когда последний раз вы предпринимали какое-либо действие по улучшению, выходящее за рамки вашего опыта, команды или отдела?
Традиционный мыслитель и системный мыслитель отличаются тем, как они думают и действуют. Тот же профессор Р. Л. Акофф пишет про аналитическое и синтетическое мышление. Он утверждает, что традиционное мышление — аналитическое. Если есть проблема, которую надо понять, раздели ее на более мелкие части, изучи эти части, построй понимание целой проблемы на основе понимания ее частей и на основе этого действуй.
Системное мышление синтетично. Если есть проблема, которую надо понять, найди, как проблемные части взаимодействуют с другими частями в рамках целого, изучи, как взаимодействия различных частей привели к проблеме, и наконец действуй в отношении взаимодействий и функций этих частей, чтобы проблема не могла возникнуть вновь.
Давайте продемонстрируем это на примере.
Предположим, организация столкнулась с большим количеством багов и заявок на доработки от клиентов, и обработка этих багов и заявок отнимает значительную часть времени разработчиков.
Традиционный мыслитель будет специализировать работу и оптимизировать отдельные части. Внимание будет направлено на то, как выполнена работа, и на самих людей. Для устранения багов будут созданы специальные команды (специализация работы). Будут куплены усовершенствованные инструменты для обработки и выполнения задач, внедрены новые процессы для лучшего приоритизирования и принятия решений, что делать, а что нет (оптимизация частей).
Системный мыслитель будет искать первопричины и оптимизировать целое. Внимание будет уделяться взаимодействию отделов, команд и людей. Поступающие баги и заявки на доработки будут изучаться для того, чтобы понять их природу и причину появления (анализ первопричин). Взаимодействия между отделами маркетинга, разработки и продаж рассматриваются с точки зрения устранения первопричины даже за счет производительности этих отделов (оптимизация целого).
Разработка программного обеспечения — это система! Это часть более крупной системы, которая может быть продуктовой организацией, сервисной организацией или организацией другого типа. Поэтому нам надо относиться к разработке программного обеспечения как к самостоятельной системе, как к части более крупной системы. Только тогда можно устранить первопричины проблем и достичь долговременных улучшений.
Я закончу статью, как вы могли догадаться, мотивирующей цитатой Р. Л. Акоффа.
«В большинстве случаев в проблемах присутствуют циклические, а не линейные причины и следствия. В результате свыше 90 % проблем в корпорации лучше решать в другом месте, а не там, где они появились».