Приведенная выше диаграмма отражает не только реальные причинно-следственные связи, но и предположения людей о таких связях ментальные модели, которые могут быть ошибочными. Необходимо отметить, что на человеческое восприятие причин и следствий влияет временно́й интервал между ними (отложенный эффект) и качество обратной связи в системе.
Цель выявления ментальных моделей в том, чтобы улучшить наш метакогнитивный навык видеть и подвергать сомнению собственные предположения и логические цепочки. Не ошибаемся ли мы в нашей логической схеме? Другая цель в том, чтобы узнать и обсудить (не пытаясь оскорбить чужую точку зрения) ментальные модели наших коллег.
Попробуйте выявлять ментальные модели и предположения через совместную разработку диаграмм причинно-следственных циклов.
Увидеть ментальные модели только первый шаг; второй, гораздо более трудный шаг изменить их. Это искусство не входит в тематику данной книги, хотя успешное внедрение масштабированного скрама требует изменений в привычном образе мышления и выработки совместного понимания в большой группе.
Совет: чтобы выявить ментальные модели (предположения, убеждения, цепочки умозаключений и т. д.), связанные с системной динамикой, в ходе построения модели задавайте наводящие вопросы и записывайте ответы. Например: «Давайте поговорим о предположениях, стоящих за этой моделью. Что именно и почему заставляет нас так считать?»
Ответы записывайте на доске рядом с соответствующими элементами модели, например:
Пример: динамика «быстрее значит медленнее»
Теперь, когда мы разобрались с тем, что такое «быстрые решения», отложенные эффекты, петли положительной обратной связи и ментальные модели, давайте рассмотрим интересную ситуацию, когда «быстрое решение» ведет сначала к кажущемуся краткосрочному улучшению какой-либо переменной, а затем к отложенному ухудшению той же переменной, то есть динамику «быстрее значит медленнее». Такая динамика часто встречается в рабочей среде и ведет к снижению производительности. Поэтому она заслуживает отдельной иллюстрации.
История Microsoft Word и секретного инструментария разработчика классический пример динамики краткосрочного «улучшения» с последующим долгосрочным ухудшением. Речь идет о первом релизе Microsoft Word для Windows [Spolsky04]. Программа была выпущена на несколько лет позже, чем ожидалось. Почему? Потому что менеджеры старались соблюсти первоначально составленный график и давили на разработчиков, чтобы уложиться в срок.
Эта история показывает, почему склонность принимать желаемое за действительное рассматривается в бережливом подходе как один из факторов потерь. В нашем случае принятие желаемого за действительное выражалось в попытке строго следовать первоначальному графику, в основе чего лежало неправильное предположение (движимое все тем же соблазном принимать желаемое за действительное), будто исходные оценки проекта являются не оценками, а обязательствами, распространенное заблуждение, которое часто ведет к деградации системы.
Рис. 2.2. иллюстрирует базовую динамику того, что происходит, когда менеджеры давят на людей с целью соблюсти первоначальный график, и почему такое «быстрое решение» проблемы медленного прогресса в краткосрочной перспективе вроде бы ускорило работу команды, но в долгосрочной замедлило ее еще больше. В этой модели мы частично опустили более глубокую динамику, которая будет рассмотрена дальше и представлена на рис. 2.3.
Итак, в качестве «быстрого решения» менеджеры Microsoft уговаривали, подкупали (обещанием премий) и угрожали разработчикам Word, чтобы те уложились в первоначальный график. В результате разработчики вполне предсказуемо прибегли к своему секретному инструментарию множеству практик, известных как «грязные хаки», которые ведут к написанию грязного кода (без тестов, без инспекции, с игнорированием известных дефектов, копипастом, плохим дизайном и т. д.), чтобы быстрее выпускать новую функциональность. Как видите, у разработчиков тоже есть «быстрые решения» своих проблем.
Поначалу казалось, что эта тактика обладает магическим действием. Чем настойчивее менеджеры давили на разработчиков, тем активнее те использовали свой секретный инструментарий и тем быстрее выпускались «фичи», что усиливало убеждение менеджеров, будто давление на разработчиков помогает. Но у этого обманчивого ускорения имелся отложенный эффект в виде долгосрочного замедления разработки (мы рассмотрим это чуть дальше). Развитие негативной динамики первое время оставалось незамеченным, поскольку последствия использования секретного инструментария проявились не сразу и руководство считало, что менеджерам не нужно самим быть опытными разработчиками, чтобы разбираться в деталях исходного кода или же регулярно проверять его состояние.
Более глубокий анализ системной динамики, который показывает, по какой причине разработка замедлилась в долгосрочной перспективе и почему первая версия Word для Windows была выпущена на несколько лет позже ожидаемого срока, представлен на рис. 2.3.
Естественно, значительный объем грязного кода в конечном итоге замедлил разработку. Хуже того, разработчики игнорировали постоянно растущий список открытых дефектов, генерируя вместо этого все больше новой функциональности. Это вело к тому, что между моментом возникновения дефекта и его устранением проходило все больше времени. Это в свою очередь значительно увеличило вариативность и время/усилия на устранение дефекта из-за усугубляющего негативного воздействия долгоживущей ошибки (например, из-за обходных решений и сильной связанности), а также потому что разработчики со временем забывали детальный контекст связанного с дефектом кода и, следовательно, им требовалось восстановить в памяти этот контекст, вокруг которого к тому времени оказалось еще больше грязного запутанного кода.
Проницательный читатель мог заметить несколько петель положительной обратной связи, которые усиливали этот цикл деградации; неудивительно, что при такой динамике продукт был выпущен на несколько лет позже, чем предполагалось.
Решение? Использовать принципы бережливого подхода «остановись и исправь» и «пойди и посмотри». Во-первых, когда возникают проблемы, вместо того чтобы пытаться двигаться быстрее, менеджер-учитель побуждает людей замедлиться, понять системную динамику и корневые причины и устранить их чтобы улучшить систему. Двигаясь медленнее, Toyota чемпион бережливого мышления стала одной из самых быстро развивающихся компаний в мире. Во-вторых, менеджерам нужно пойти туда, где делается реальная работа, и посмотреть, что происходит. «Реальная работа» в программировании это код; следовательно, менеджеры первого уровня должны быть квалифицированными программистами, которые способны оценить качество кода и должны делать это регулярно.
Когда релиз все-таки состоялся, люди в Microsoft наконец-то провели ретроспективу и проанализировали произошедшее. Результатом стало принятие компанией политики «ноль дефектов», которая требует в первую очередь исправить все известные дефекты в разрабатываемом коде свести список открытых дефектов к нулю и только затем приступать к работе над новой функциональностью.
Учимся видеть корневые причины
«Мы пытались внедрить скрам на протяжении всего прошлого года, но не увидели больших улучшений. Почему?» Выявление корневых причин может помочь найти ответ. Системное мышление требует от нас развивать умение «проникать в суть» видеть фундаментальные причины и более глубокие действующие силы. Непредвиденные последствия и «быстрые решения» это симптомы того, что люди не понимают сути происходящего.