Масштабированный скрам. Как организовать гибкую разработку в крупной компании

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

Пример: динамика «быстрее – значит медленнее»

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

История Microsoft Word исекретного инструментария разработчика – классический пример динамики краткосрочного «улучшения» с последующим долгосрочным ухудшением. Речь идет о первом релизе Microsoft Word для Windows [Spolsky04]. Программа была выпущена на несколько лет позже, чем ожидалось. Почему? Потому что менеджеры старались соблюсти первоначально составленный график и давили на разработчиков, чтобы уложиться в срок.

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

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

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

Поначалу казалось, что эта тактика обладает магическим действием. Чем настойчивее менеджеры давили на разработчиков, тем активнее те использовали свой секретный инструментарий и тем быстрее выпускались «фичи», что усиливало убеждение менеджеров, будто давление на разработчиков помогает. Но у этого обманчивого ускорения имелся отложенный эффект в виде долгосрочного замедления разработки (мы рассмотрим это чуть дальше). Развитие негативной динамики первое время оставалось незамеченным, поскольку последствия использования секретного инструментария проявились не сразу и руководство считало, что менеджерам не нужно самим быть опытными разработчиками, чтобы разбираться в деталях исходного кода или же регулярно проверять его состояние.

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

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

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

Решение? Использовать принципы бережливого подхода «остановись и исправь» и «пойди и посмотри». Во-первых, когда возникают проблемы, вместо того чтобы пытаться двигаться быстрее, менеджер-учитель побуждает людей замедлиться, понять системную динамику и корневые причины и устранить их – чтобы улучшить систему. Двигаясь медленнее, Toyota – чемпион бережливого мышления – стала одной из самых быстро развивающихся компаний в мире. Во-вторых, менеджерам нужно пойти туда, где делается реальная работа, и посмотреть, что происходит. «Реальная работа» в программировании – это код; следовательно, менеджеры первого уровня должны быть квалифицированными программистами, которые способны оценить качество кода и должны делать это регулярно.

Когда релиз все-таки состоялся, люди в Microsoft наконец-то провели ретроспективу и проанализировали произошедшее. Результатом стало принятие компанией политики «ноль дефектов», которая требует в первую очередь исправить все известные дефекты в разрабатываемом коде – свести список открытых дефектов к нулю – и только затем приступать к работе над новой функциональностью.

Учимся видеть корневые причины

«Мы пытались внедрить скрам на протяжении всего прошлого года, но не увидели больших улучшений. Почему?» Выявление корневых причин может помочь найти ответ. Системное мышление требует от нас развивать умение «проникать в суть» – видеть фундаментальные причины и более глубокие действующие силы. Непредвиденные последствия и «быстрые решения» – это симптомы того, что люди не понимают сути происходящего.

Попробуйте… выявлять корневые причины с помощью причинно-следственного моделирования, метода «Пять почему» и диаграмм Исикавы

Непрерывное улучшение – один из двух столпов бережливого подхода. В Toyota существует культура «останови и исправь», которая состоит в следующем:

1. Когда люди видят проблему, они останавливаются…

2. Анализируют ее, чтобы найти корневые причины…

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

Следующие простые инструменты помогают обсудить проблему и выявить корневые причины:

? метод «Пять почему» (рассматривается в главе о бережливом подходе);

? диаграммы Исикавы («Рыбья кость»).

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

Выявление корневых причин с помощью диаграмм Исикавы

Метод «Пять почему» относительно неструктурирован; его можно комбинировать с диаграммами Исикавы (диаграммами «Рыбья кость») [Ishikawa86], чтобы организовать и связать причины, лежащие в основе проблемы, например такой, как неэффективность скрам-мастеров. Шаг первый – провести мозговой штурм по причинам проблемы; мы рекомендуем брейнрайтинг, когда каждый участник записывает свои идеи по одной на листочке бумаги и кладет эти листочки на общий стол. Шаг второй – кластеризация по сходству; нужно сгруппировать причины в семейства связанных причин и дать название каждой группе (рис. 2.5). Шаг третий – нарисовать скелет диаграммы Исикавы, где в качестве «костей» используются названия групп. Шаг четвертый – применить метод «Пять почему» к каждой группе или к заслуживающим внимания подэлементам каждой группы, чтобы выявить корневые причины. Все ответы нужно заносить в диаграмму, как показано на рис. 2.6.

После анализа корневых причин: проведите корректирующие эксперименты

Анализ корневых причин проводится не ради любопытства. Когда вы узнаете первопричины проблемы, следующий важный шаг, который необходимо сделать в рамках ретроспективы спринта, – провести эксперименты по улучшению системы [Vodde07].

Учимся видеть (и слышать) локальную оптимизацию

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

Попробуйте… увидеть (и услышать) случаи локальной оптимизации; это бич больших продуктовых групп.

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

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

Ниже приведен фрагмент из реального электронного письма «офисной полиции» одной компании с запретом использовать визуальные инструменты управления на стенах. Подумайте, какова цель этой локальной оптимизации и какие ментальные модели могут лежать в ее основе?

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

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

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

При масштабном внедрении скрама или принципов гибкой разработки большинство возникающих вопросов типа «Да, но?..» касаются именно локальной оптимизации, например: «Да, но… как насчет управленческой отчетности?» или, более обобщенно, «Да, но… как насчет <этого конкретного случая>?». В результате правила и практики меняются таким образом, чтобы удовлетворить требования отчетности или служить любой другой второстепенной цели, вместо того чтобы обеспечивать глобальную оптимизацию – улучшать общую способность системы быстро создавать ценность. Иногда можно встретить локальную оптимизацию ради редких или чрезвычайных случаев. Например, группа, отвечающая за централизованный выбор программного инструмента для всей компании, фокусируется на самых сложных и редких случаях его использования и на основе этого сценария выбирает инструмент, который подходит именно для таких случаев. В результате достигается субоптимизация для 5 % случаев – за счет простоты использования и скорости в 95 % случаев.

Еще одна причина локальной оптимизации – консервативное мышление и незнание новых подходов к работе. Особенно часто это встречается в крупных продуктовых группах. Например, однажды мы помогали большой сетевой продуктовой группе в Европе внедрить скрам и практику непрерывной интеграции (НИ) вместе с системой НИ, которая постоянно интегрировала, собирала и автоматически тестировала продукт. Спустя некоторое время внешний менеджер проверил, как идут дела, и потребовал изменить практику интеграции, потому что у группы не было формального плана, в соответствии с которым менеджер по интеграции должен был вручную интегрировать все ПО, и, разумеется, не было и самого менеджера по интеграции. Внешний менеджер хотел «оптимизировать» работу менеджера по интеграции, который был больше ни к чему. Он не понимал, что вся эта устаревшая модель работы стала не нужна благодаря НИ. Эта история повторяется во всех крупных устоявшихся компаниях-разработчиках, где локальной оптимизации подвергаются существующие традиционные способы работы, такие как ручное тестирование, или отдельные группы по разработке архитектуры, компонентные команды и т. д. Консультанту, который занимается внедрением масштабированного скрама на уровне компании, приходится разгребать горы таких локальных оптимизаций.

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

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

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

Заключение

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

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

? «Выход из кризиса: Новая парадигма управления людьми системами и процессами» Уильяма Эдвардса Деминга (М.: Альпина Паблишер, 2022) – основополагающий труд одного из самых выдающихся системных мыслителей и экспертов по качеству. Книга начинается с заявления скромной цели: «Цель этой книги – преобразование американского стиля менеджмента. Это не означает его перестройку или ревизию. Преобразование требует полностью обновленной структуры сверху донизу». Для этого, по мнению Деминга, менеджерам необходимо владеть системой глубинных знаний, то есть: (1) понимать, что такое система; (2) понимать вариабельность, обусловленную общими или особыми причинами (с этим, в частности, имеет дело теория массового обслуживания); (3) признавать ограниченность знаний и быть готовыми обсуждать ошибки и (4) обладать современными знаниями в области психологии и социологии, чтобы не руководить поведением и мотивацией людей только лишь на основе «здравого смысла». Книга построена вокруг знаменитых 14 принципов управления, один из них: «Исключите управление по целям. Перестаньте управлять по числам и количественным результатам. Замените его лидерством».

? «Мировая динамика» Джея Форрестера (М.: АСТ, 2003) – классическая работа по системной динамике, ясная и содержательная. Написанная в начале 1960-х гг., она не теряет своей актуальности и сегодня. Наряду с моделированием причинно-следственных связей в работе рассматривается моделирование потоков и запасов – информационных, денежных, материальных – в системах. Также затрагивается тема формального математического моделирования, но последнее необязательно для понимания системной динамики.

? «Управление качеством ПО: Системное мышление» (Quality Software Management: Systems Thinking) и «Введение в общее системное мышление» (An Introduction to General Systems Thinking) Джеральда Вайнберга, безусловно, достойны прочтения. Написаны опытным консультантом по развитию систем.

? «Пятая дисциплина: Искусство и практика обучающейся организации» Питера Сенге (М.: МИФ, 2018) – еще один классический труд, который доказывает необходимость применения лидерами системного мышления (пятой дисциплины), а также других четырех ключевых дисциплин для создания сильной и устойчивой компании. Эти четыре дисциплины: 1) личное совершенствование; 2) умение критически смотреть на собственные убеждения и мышление (интеллектуальные модели) и видеть в них ошибки; 3) умение создавать и сообщать другим значимое общее видение и 4) способность команд к обучению. Мы рекомендуем – по крайней мере на старте – игнорировать концепцию «архетипов», представленную в этой книге. Хотя она задумывалась как вспомогательный обучающий инструмент, мы заметили, что она отвлекает и даже отпугивает людей на начальном этапе обучения и применения базового моделирования системной динамики. «Архетипы» не являются частью оригинального подхода к системной динамике.