Системное мышление

“Что бы мы ни делали, количество дефектов в нашем бэклоге остаётся примерно тем же самым”, говорил нам менеджер; это было про наш продукт, состоящий из 15 миллионов строк кода, над которым работало несколько сотен разработчиков. В чём дело? Ответить на этот вопрос может системное мышление. В небольших группах существующие воздействия легко заметить и понять без каких-либо формальностей, но при разработке крупного проекта — или любой крупной системы — это тяжело. Джеральд Вайнберг в этой ситуации выделяет два решающих фактора:

Закон Вайнберга-Брукса: От действий менеджеров, основанных на неправильных моделях системы, пострадало больше проектов, чем от всех остальных причин вместе взятых.

Ловушка причинно-следственной связи: У каждого результата есть причина… и мы всегда можем разобраться, что есть причина, а что - следствие. [Weinberg92]

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

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

В 1958 году журнал Harvard Business Review опубликовал “Industrial Dynamics: A Major Breakthrough for Decision Makers,”, прорывную статью Джея Форрестера (Jay Forrester), профессора Школы Менеджмента Альфреда Слоуна Массачусетского Технологического Института (MIT Sloan School). Эта статья дала толчок движению системного мышления в бизнес-образовании, и Школа Менеджмента Массачусетского Технологического Института вскоре получила известность благодаря обучению людей системной динамике. Системная динамика часто трактуется как синоним системного мышления, хотя последнее - более общий термин.

МТИ также привлек и других исследователей, ориентированных на динамику систем, таких как Питер Сенге (Peter Senge).¹

В соответствии с законом Вайнберга-Брукса, исследование Форрестера показало, что когда людям, принимающим решения, предлагали улучшить производительность системы на основании динамической модели бизнес системы, они обычно делали её еще хуже [SKRRS94]. Исследование также показало, что большинство людей имеют слабое понимание о том как фундаментально улучшать системы, обычно применяя неуместный “здравый смысл” и ‘решения’ на скорую руку, которые не приводят к долговременным систематическим улучшениям.

Почему же поведение большой группы разработки (как некой системы) так сложно понять и умело им управлять? Ответ лежит, в частности, в поведении стохастических систем с очередями и изменчивостью, как показывает принцип Теории Массового Обслуживания LeSS. И тот же самый ответ лежит в теории управления: Большинство интересующих нас систем — таких, как группа разработки продукта — имеют сложные петли положительных и отрицательных обратных связей и нелинейное поведение. Поведение таких систем не поддается нашей интуиции. А еще есть небольшая проблема, связанная с людьми.

Подводя итог, причины, по котором большие системы не поддаются пониманию и управлению, включают (но не ограничиваются):

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

Короче говоря, неспособность мыслить системно.²

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

В качестве краткого изложения системного мышления, нам нравится 11 ‘законов’, описанных в книге “Пятая дисциплина” Питера Сенге:

• Сегодняшние проблемы – результаты вчерашних ‘решений’.
• Сила воздействия на систему равна силе противодействия системы.
• Временное ухудшение предшествует долговременному улучшению.
• Обычно легкий выход – это путь назад.
• Бывает, что лекарство горше болезни.
• Тише едешь – дальше будешь.
• Причины и следствия редко сильно связаны во времени и пространстве.
• Результаты малых изменений могут оказаться очень значительными… но области, в которых изменения принесут наибольший эффект, обычно наименее очевидны.
• Вы можете иметь пирог и есть его – но не в одно и то же время [нельзя поймать “двух зайцев сразу”, прим. переводчика].
• Разделив слона пополам, не получишь двух слонят.
• Не нужно искать виновных.

Внутренняя мантра Тойоты - “Правильное мышление, хорошие продукты.”[англ. Good thinking, good products]. Системное мышление - это набор инструментов мышления, помогающих…

• видеть (замечать) системную динамику — организация, занимающаяся разработкой - это система из людей и политик с неявными обратными связями и неочевидными воздействиями
  • мы можем научиться видеть и, следовательно, улучшать систему при помощи диаграмм причинного-следственных циклов (casual loop diagrams, CLD), созданных во время совместной работы
• видеть ментальные модели — одна из причин неоптимальных решений - это ложные предположения и ошибочные выводы
  • это обнаруживается при составлении диаграмм причинно-следственных циклов и метода “Пять Почему”
• видеть локальную оптимизацию — еще один источник неоптимальных решений - локальная оптимизация, когда принимается ‘лучшее’ с точки зрения отдельного человека или департамента решение, вместо глобальной оптимизации, исходящей из цели системного уровня бережливого подхода: поставлять ценность быстро, с высоким качеством и высоким уровнем морального духа.
  
  
  
  

Это введение построено вокруг следующих областей системного мышления: Учимся видеть (1) системную динамику , (2) ментальные модели , (3) корневые причины, и (4) локальную оптимизацию .

Видеть Системную Динамику: Введение

Статическая Сложность против Динамической Сложности

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

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

В отличие от привычного образования, хорошо справляющегося со статическим анализом, многие из нас не получили формального образования по анализу динамической сложности³, особенно динамики рабочей среды. Возможно, причина этого в том, что мы думаем, что в рабочей среде достаточно полагаться на здравый смысл. Форрестер продемонстрировал, что в сложных системах обычного “здравого смысла” недостаточно, и показал возможность обучения людей формальным методам, чтобы лучше понимать системную динамику рабочей среды, используя динамические модели систем, представленные в виде диаграмм потока [Forrester61].

Диаграммы потока охватывают материальные, финансовые и информационные потоки, метрики (переменные, имеющие количественные значения, такие как сумма денег или количество дефектов), последствия принятых решений или политик, и причинно-следственные связи. Популярное упрощение - это диаграмма причинно-следственных циклов, которая фокусируется на причинно-следственных связях и петлях обратной связи системы [Sterman00]. Есть несколько похожих нотаций; во всех присутствуют метрики (переменные), причинные связи и отложенный эффект. В книге [Weinberg92] это называется диаграммой воздействия.

Первый Закон Построения Диаграмм: Моделируйте, Чтобы Обсуждать

Чтобы научиться видеть системную динамику, используйте диаграммы причинно-следственных циклов, в идеале, нарисованные на доске, совместно с коллегами в рамках Общей Ретроспективы LeSS. Но прежде, чем двигаться дальше, давайте поговорим про Первый Закон Построения Диаграмм

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

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

Конкретный совет для построения диаграмм : Мы начинаем, записывая на стикерах переменные. Стикер может содержать запись “Скорость разработки фич” или “Количество дефектов”. Мы размещаем стикеры на доске. Затем мы рисуем причинно-следственные связи между стикерами. В процессе построения диаграммы всегда приходится много переписывать, стирать, перерисовывать. Самый важный результат - это понимание; в дополнение, кто-то из участников захочет сфотографировать то, что получилось на доске.

Видеть системную динамику: Диаграммы причинно-следственных связей

Диаграммы причинно-следственных циклов часто используются при знакомстве с LeSS, чтобы увидеть системную динамику того, что происходит при разработке больших систем. Уже только ради одной этой цели имеет смысл в них разобраться. Ещё полезнее нарисовать на доске несколько схем вместе с коллегами. Моделируйте, чтобы обсуждать. Когда? Например, во время Общей Ретроспективы LeSS.

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

Представленные ниже примеры могут показаться надуманными, когда их читаешь. Но представьте, что вы с коллегами присутствовали у доски в момент создания, и диаграммы появлялись в процессе живого общения. Именно так мы трактуем ‘мыслить’ системно.

Нотации и Примеры

Диаграммы причинно-следственных циклов содержат много элементов; приведённое ниже наиболее часто используемое подмножество будет рассмотрено дальше в рамках сценария.

• переменные
• причинные связи
• обратные эффекты
• ограничения
• цели
• реакции; поспешные реакции (временные решения)
• эффекты взаимодействия
• сильные воздействия
• задержки
• петли положительной обратной связи

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

Переменные — Диаграммы причинно-следственных циклов включают переменные (или метрики) такие, как скорость разработки (показатель поставки) новой функциональности и количество дефектов. Переменные имеют измеримую величину.

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

Теперь пришло время познакомиться с Законом Вайнберга-Брукса и Ловушкой причинно-следственной связи. Легко нарисовать диаграмму; но совсем другое - построить её с пониманием. Например, рассмотрим связь между количеством разработчиков и скоростью разработки новой функциональности.

Природа любой причинно-следственной связи на самом деле не очевидна, хотя это очень свойственно людям - делать поспешные выводы, такие как увеличение количества разработчиков приводит к увеличению скорости разработки. Но добавление людей на поздних стадиях разработки может уменьшить скорость (подпункт “Закона Брукса” [Brooks95]). Или: больше плохих разработчиков могут здорово вас замедлить. В качестве аргумента можно сказать, что устранение ужасных разработчиков может улучшить скорость.

Обратные эффекты — Эффект от причинно-следственной связи может быть прямым или обратным; если А растёт, то растёт и В, или наоборот. Обратный эффект показан символом ‘O’ рядом с линией. Допустим, появление дефектов создаёт препятствия в системе, замедляя разработку новой функциональности, потому что люди тратят больше времени на исправление дефектов или поиск обходных путей.

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

Ограничения - это не причинно-следственные связи. Даже если бюджет вырастет, это вовсе не означает, что количество разработчиков увеличится.

Цели и Реакции – Люди, подразделения и системы имеют цели, такие как увеличение скорости разработки. Цели часто заставляют людей реагировать (или действовать) с намерением достичь их. Но, принимая по внимание Ловушку причинно-следственной связи и Закон Вайнберга-Брукса, необходимо быть осторожными в своих предположениях, что подобные реакции будут на пользу. Цель и стимулирование соответствующих ей действий показаны на рисунке:

Цель с вознаграждением заставляет не только действовать, но и стимулирует создавать видимость действий и достижений, из-за дисфункции измерения, вызванной вознаграждениями. И дисфункция измерения может быть пропорциональной воспринимаемой ценности вознаграждения, потому что люди мотивированы получить поощрение, а не улучшить систему [Austin96]. Обратите внимание, как награды могут на самом деле привести к деградации производительности системы. Представление, соответствующей системной динамики может быть следующим…

Довольно интересно, что вся эта системная динамика появилась из-за введения поощрения, и пока нет никакой явной связи между верхней и нижней частями этой модели.

Нет никаких гарантий, что скорость разработки фич улучшилась — или даже что на неё что-то повлияло.

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

Временные решения — Одно из сложных и долгосрочных решений, призванных увеличить скорость разработки фич - нанять крутых разработчиков, увеличить степень обучения и коучинга текущей команды, уволить ужасных сотрудников. Альтернатива - так называемое временное решение, основывается на ожидании быстрого достижения цели с минимальными усилиями. Иногда такое решение работает в кратко- и долго-срочной перспективе, действительно укрепляя систему. Но “иногда” не значит… “следовательно”, “Тише едешь – дальше будешь”. Например, люди могут верить, что увеличение количества разработчиков увеличит скорость разработки новой функциональности. И, тем самым, они могут надеяться, что найм большего количества разработчиков - самый быстрый и простой способ решить проблему со скоростью разработки. Символы ‘QF’ [англ.: quick fix, прим. переводчика] обозначают временное решение:

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

Кто-то мог бы просто нарисовать (обратную) причинную связь напрямую из прибыли к коэффициенту найма очень дешёвых разработчиков, но это просто говорило бы, что уменьшение бюджета приводит к найму большого числа еще более (экстремально) дешёвых разработчиков. Это не совсем то, что мы хотим сказать; скорее, мы хотим показать эффект взаимодействия — что воздействие А влияет на воздействие B. Это можно показать, если одну причинную связь подвести к другой причинной связи. Например, от бюджета к стрелке, изображающей временное решение, идущей к коэффициент найма очень дешёвых разработчиков:

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

Чтобы показать сильное воздействие в модели, используйте жирную линию:

Задержки — Одна из проблем найма разработчиков - заблуждение о небольшом разбросе в квалификации разработчиков — ошибочное мнение, что программисты не слишком отличаются друг от друга (в смысле производительности, качества кода и т.д.). Однако исследования разброса в квалификации программистов показывают, что верхний квартиль способен работать вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница. Кроме того, модель COCOMO, основанная на продолжительных и масштабных исследованиях, показывает, что способности людей, занятых в разработке ПО, сильнее всего влияют на продуктивность [Boehm00]. Наконец, в среднем, очень слабый программист создает код худшего качества (плохой дизайн), с бóльшим количеством дефектов, создавая в системе дополнительные помехи.

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

Чтобы показать отложенное воздействие на модели, используйте линию с двойной чертой:

Задержки обладают интригующим влиянием на самообучающуюся или корректирующую силу системы. Если результат или неявные последствия чего-либо сильно отложены во времени, мы не чувствуем между ними (причинно-следственной) связи и не видим как A повлияло на B, или ещё более тонко - как A, повлияв на B, повлияло на A.

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

Петли положительной обратной связи — Петли положительной или отрицательной обратной связи⁵ и задержки - это тонкие моменты в системе — и в нашем понимании системы. К примеру, как можно стать лучшим программистом? Отчасти - обучаясь у превосходных программистов и глядя на множество примеров прекрасного кода. Но компания, в которой много программистов с низкой квалификацией, не производит много примеров прекрасного кода, также как и не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Они скорее найдут работу где-то в другом месте.

Так группа программистов входит в усиливающую саму себя нисходящую спираль — набор петель положительной (усиливающей) обратной связи. К счастью, этот нисходящий тренд ограничивается бюджетом.

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

Подсказка : Вы можете обнаружить петли положительной обратной связи, если найдете циклы с четным количеством связей с ‘Обратным’ воздействием. В модели, изображенной выше, есть несколько таких примеров.

Заключение

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

Видеть Ментальные Модели

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

Смысл “ментальной модели” в том, чтобы улучшить наш мета-когнитивный навык видеть и подвергать сомнению наши собственные предположения и логические цепочки. Не идем ли мы по ложному следу? Это также включает то, как мы ведём себя с другими, обсуждая (проясняя информацию, а не пытаясь оскорбить чужое мнение) ментальные модели наших коллег.

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

Совет, как лучше увидеть ментальные модели (убеждения, предположения, цепочки умозаключений, …), сопровождающие системную динамику: задавайте наводящие вопросы во время построения модели и записывайте ответы. “Давайте поговорим о предположениях, стоящих за этой моделью. Во что мы верим или предполагаем в смысле фактов и воздействий, которые привели нас к текущему пониманию модели?”

Ответы рисуйте прямо на доске с моделью, например:

Пример: Динамика “Тише Едешь - Дальше Будешь”

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

История Microsoft Word и секретного инструментария разработчика : Классический пример краткосрочного ‘улучшения’, но при этом ухудшения в долгосрочной перспективе - история первого релиза Microsoft Word для Windows [Spolsky04]. Его выпустили на годы позже, чем изначально ожидалось. Почему? Потому что менеджеры пытались следовать составленному вначале расписанию и давили на разработчиков, чтобы в него уложиться.

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

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

В качестве быстрого решения “на скорую руку” менеджеры Microsoft уговаривали, подкупали (при помощи потенциальных премий) и угрожали разработчикам Word, чтобы те уложились в первоначальное расписание. В результате разработчики периодически прибегали к своему секретному инструментарию разработчика — множеству практик, приводящих к написанию грязного “хакерского” кода (без тестов, без ревью, игнорируя известные дефекты, копипаст, плохой дизайн, …), чтобы быстрее выпустить новую функциональность. Как видите, у разработчиков тоже есть быстрые решения своих проблем.

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

Более детальное исследование системной динамики, показывающее почему разработка замедлилась в долгосрочной перспективе и почему первая версия Word для Windows увидела свет спустя годы после ожидаемого срока, показано на этой модели…

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

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

Решение? Принципы бережливого производства: Остановись и Исправь и Пойди и Посмотри. Во-первых, когда возникают проблемы, вместо того чтобы пытаться двигаться быстрее, менеджер-учитель побуждает людей замедлиться и помогает им научиться увидеть системную динамику и корневые причины, а также их устранить — чтобы улучшить систему разработки. Двигаясь медленнее, Тойота — чемпион бережливого мышления — стала одной из самых быстрых компаний в своей сфере. Во-вторых, менеджерам нужно пойти и посмотреть на место, где происходит реальная работа, чтобы понимать, что происходит. “Место, где происходит реальная работа” в программировании - это код, из чего следует, что первоклассными менеджерами должны становиться лучшие разработчики, которые часто оценивают код.

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

Видеть (и Слышать) Локальную Оптимизацию

“Каждый старается изо всех сил, но пропускная способность всей системы продолжает ухудшаться. Как такое может быть?” Это парадокс локальной оптимизации — когда человек или отдел, принимающий решения, оптимизирует с локальной точки зрения или из-за эгоистичных побуждений. Лицо, принимающее решение, часто верит, что оно принимает наилучшее решение, но поскольку ‘наилучшее’ решение является локальной оптимизацией, фактически это лишь субоптимизация общей пропускной способности системы. Это является результатом “узкого мышления”, недопонимания, страха, недостаточной информации, поздней обратной связи, игнорирования, карьеризма, жадности и прочих распространённых расстройств организационного развития.

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

К примеру, юридический отдел и отдел безопасности утвердили политику, которая с их точки зрения кажется критически важной. В целях предотвращения утечки интеллектуальной собственности, юридический отдел принимает решение о том, что “запрещено размещать любую информацию на стенах”. Либо, в ответ на требование сократить издержки, хозяйственный отдел обслуживания говорит, что “очень важно, чтобы все наши стены содержались в чистоте и не были повреждены”. Таким образом, они блокируют практику визуального управления, позаимствованную из бережливого мышления (которая обычно делается на стене), и препятствуют хорошо себя зарекомендовавшей инновационной практике, групповой работе у доски. Юристы, возможно, преуспеют в защите интеллектуальной собственности (на самом деле, это еще под вопросом), и хозяйственный отдел будет доволен чистыми стенами — ценой подавления инноваций и совместной работы в группе продуктовой разработки. В конце концов, компания оказывается позади со все меньшим и меньшим объемом интеллектуальной собственности, который стоило бы защищать, поскольку инструменты для инноваций и быстрой поставки были запрещены, но зато юристы успешно выполнили распоряжение топ-менеджеров: “убедиться, что наша интеллектуальная собственность надежно защищена”. И офисная полиция довольна чистыми стенами. Они старались сделать свою работу как можно лучше.

Ниже реальная цитата из электронного письма ОФИСНОЙ ПОЛИЦИИ одной организации, которая запретила использовать визуальные инструменты управления на стенах. Сможете ли вы распознать локальную оптимизацию и ментальную модель, вызвавшую такое поведение?

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

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

При внедрении Скрама или принципов гибкой разработки в большом масштабе, большинство всплывающих вопросов “Да, но …” - это примеры локальной оптимизации, например, “Да, но … что насчет управленческой отчетности?” или, обобщая, “*Да, но … что насчет <частный случай="">*?” После чего политики и практики извращаются и искажаются, подчиняясь цели отчетности или любой другой второстепенной цели, вместо подлинной цели оптимизации пропускной способности при поставке ценности. Иногда мы наблюдаем *локальную оптимизацию ради редкого или экстремального случая*. Например, человек, отвечающий за выбор централизованного инструмента разработки для компании, представляет сценарий сложный или очень специфический пример использования, после чего выбирает инструмент, который подходит под этот случай, тем самым субоптимизируя сценарий, возникающий в 5% случаев, вместо того чтобы оптимизировать ради простоты использования и скорости 95% случаев.

Другие примеры локальной оптимизации вызваны пренебрежением новыми подходами к работе. Особенно часто это можно встретить в группах, разрабатывающих масштабные продукты. Например, однажды мы помогали одной большой сетевой продуктовой группе внедрить Скрам и практику непрерывной интеграции (continuous integration, CI) вместе с CI системой, которая непрерывно интегрировала, собирала и автоматически тестировала продукт. Через некоторое время внешний менеджер, приверженец традиционных подходов, проверил как идут дела, и порекомендовал поменять практики непрерывной интеграции — потому что не было утвержденного плана интеграции, по которому менеджер интеграции смог бы вручную интегрировать все ПО, и разумеется, потому что менеджера интеграции вообще больше не было. Они хотели ‘оптимизировать’ работу менеджера интеграции, хотя он больше был не нужен. Они не понимали, что вся их устаревшая модель работы стала ненужной благодаря CI. Эта история повторяется во всех департаментах больших устоявшихся проектов: локальная оптимизация существующих способов работы, таких как ручное тестирование, отдельный департамент архитектуры, компонентные команды и так далее. Коуч, которому приходится трансформировать крупную корпорацию к Скраму в большом масштабе, имеет дело с горой подобного локально оптимизационного мышления.

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

Помогает ли это решение или политика быстрее доставлять ценность конечному потребителю, или она направлена на интересы отдела, конкретного человека, внутренней политики/практики или редкого случая?

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

Заключение

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

Рекомендованная Литература

• Выход из Кризиса Уильяма Эдвардса Деминга, шедевр пожалуй наиболее широко известного системного мыслителя и эксперта по качеству. Она начинается со скромной целью: “Задача этой книги - трансформация стиля американского менеджмента… Это требует полностью новой организационной структуры, начиная с самого основания.” Деминг также выступает за Систему Глубинных Знаний, в которой менеджеры (1) признают наличие системы, (2) понимают вариативность общего характера и вариативность особого характера (теория массового обслуживания связана с вариативностью), (3) понимают ограниченность знаний и готовы обсуждать ошибки, и (4) знают результаты авторитетных исследований в области философии и социальных исследований, таким образом поведенческие или мотивационные политики не основываются только лишь на “здравом смысле.” Эта книга основывается на его знаменитых 14 Принципах Управления, включающих (например), “Устраните целевое управление. Перестаньте управлять по числам и количественным стандартам работы. Замените это лидерством .”
  
• Industrial Dynamics Джея Форрестера - классический текст по системной динамике — хорошо написанный и содержательный. Будучи написанным в ранних 1960-х, сегодня он также актуален, как и в момент публикации. Он расширяет границы моделирования причинно-следственных связей, добавляя также моделирование потока, запасов информации, денег и материалов в системах. Эта книга включает формально математической моделирование, хотя это и не обязательно, чтобы понимать системную динамику.
• Quality Software Management: Systems Thinking и An Introduction to General Systems Thinking Джеральда Вайнберга, безусловно, достойны прочтения. Написаны с точки зрения опытного консультанта по разработке систем.
  
• Пятая Дисциплина Питера Сенге - классический труд, который пропагандирует лидерство, как обязательную составляющую для применения системного мышления (что и является пятой дисциплиной), а также другие ключевые дисциплины для создания сильной и надёжной компании. Оставшиеся дисциплины - это лидеры (1) обладающие личным мастерством, (2) размышляющие о собственных убеждениях и возможных ошибочных рассуждениях, (3) определяющие и передающие другим общее конструктивное видение и (4) способность команд к самообучению. Мы рекомендуем игнорировать — как минимум первые несколько лет практики — понятие ‘архетипов’, представленное в книге. Оно хорошо воспринималось в качестве теоретического материала, но было замечено, что это понятие отвлекает и даже отпугивает людей на начальном этапе обучения и применения базового моделирования системной динамики. ‘Архетипы’ не являются частью классической системной динамики.
  
• The Fifth Discipline Fieldbook является более подробным источником, написанным с точки зрения многих опытных практиков и консультантов.
  
• Труды об организационном обучении от Криса Арджириса (Chris Argyris), Роберта Патнэма (Robert Putnam), Маклейна (McLain) и Дональда Шона (Donald Schön). Важные концепции включают: двойной цикл обучения и пропагандистский/глубоко-исследовательский диалог. Классические работы включат в себя Action Science и Organizational Learning.
  
• Публикации и ресурсы, доступные на Society for Organizational Learning.

---

Примечания:

1. Сенге написал книгу “Пятая Дисциплина, о системном мышлении и обучающихся организациях, названную журналом Harvard Business Review “одной из основополагающих книг по управлению за последние 75 лет”. См.** [Senge94].




2. Другая причина: Вера в то, что возможен больший контроль, чем есть на самом деле. Наука сложных систем рекомендует фундаментальные ограничения в прогнозировании и контроле полу-хаотичных социальных систем [Stacey07]. Это довольно большой ящик Пандоры, который остаётся нераскрытым в этой статье.




3. Макроэкономика, психология, социология и биология являются исключениями среди прочих других.




4. ‘Базовый’ не означает нечто тривиальное или легко решаемое. Например, ‘мотивация’ и ‘качество’ являются базовыми основами, но не простыми в достижении задачами.




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

Перевод статьи осуществлен Сергеем Господчиковым, Антоном Бевзюком, Романом Лапаевым и Кротовым Артёмом.