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

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

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

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

В 1958 г. в журнале Harvard Business Review была опубликована новаторская статья «Индустриальная динамика: важный прорыв для принимающих решения лиц» Джея Форрестера, профессора Школы менеджмента Слоуна Массачусетского технологического института (МТИ) [Forrester58]. Эта статья положила начало преподаванию системной динамики в Школе менеджмента Слоуна, а вскоре обучение системному мышлению стало неотъемлемой частью бизнес-образования. Системная динамика иногда трактуется как синоним системного мышления, но последнее более общий термин.

В МТИ работали и другие выдающиеся исследователи в области системной динамики, например Питер Сенге[5].

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

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

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

■ недостаток знаний о системной динамике, петлях обратной связи, поведении нелинейных систем и непредвиденных воздействиях в системах рабочей среды;

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

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

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

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

В качестве краткого описания системного мышления нам нравятся следующие 11 «законов», описанных в книге Питера Сенге «Пятая дисциплина»:

1. Сегодняшние проблемы вызваны вчерашними «решениями».

2. Сила воздействия на систему равняется силе ее противодействия.

3. Прежде чем улучшиться, поведение системы ухудшается.

4. Легкий путь обычно ведет назад.

5. Лечение может быть хуже болезни.

6. Тише едешь, дальше будешь.

7. Причины и следствия могут быть разделены во времени и пространстве.

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

9. Можно погнаться за двумя зайцами и поймать обоих – пусть не одновременно.

10. Разделив слона пополам, вы не получите двух маленьких слоников.

11. Не нужно искать виноватых.

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

■ Видеть системную динамику:

○ организация, занимающаяся разработкой, – это система, образованная людьми и правилами, с неявными петлями обратной связи и непреднамеренными воздействиями;

○ мы можем научиться видеть эту динамику и, следовательно, улучшать систему с помощью диаграмм причинно-следственных циклов (causal loop diagrams), создаваемых на групповых встречах.

■ Видеть ментальные модели:

○ одна из причин неоптимальных решений – ложные предположения и ошибочные выводы;

○ ментальные модели обнаруживаются с помощью диаграмм причинно-следственных циклов и метода «Пяти почему».

■ Выявлять корневые причины:

○ чтобы реально улучшить систему, необходимо научиться выявлять корневые причины проблем и видеть более глубокие связи;

○ выявить корневые причины помогают диаграммы причинно-следственных циклов, метод «Пять почему» и диаграммы Исикавы.

■ Видеть локальную оптимизацию:

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

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

Учимся видеть системную динамику

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

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

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

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

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

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

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

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

Когда вы выбираете инструменты мышления или действия для использования в рабочей среде, помните слова Вольтера:

Удобство. Существует множество изощренных инструментов мышления и действия, которые так любят теоретики, но которые почему-то никак не приживаются на практике. Вместе с тем практики скрама или экстремального программирования (XP), будучи раз внедренными, становятся очень «липкими». Почему? Во-первых, они быстро приносят реальную отдачу: у них привлекательное соотношение затрат и выгод и их внедрение быстро окупается. Во-вторых, эти практики не требуют мучительных усилий; большинство людей, которые их используют, говорит, что применяет их с интересом и даже с удовольствием (и, разумеется, с пользой). Люди есть люди: они предпочитают делать то, что им нравится.

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

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

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

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

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

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

● переменные;

● причинно-следственные связи;

● обратные эффекты;

● ограничения;

● цели;

● реакции;

● «быстрые решения»;

● эффекты взаимодействия;

● сильные эффекты;

● отложенные эффекты;

● петли положительной обратной связи.

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

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

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

Скорость разработки

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

Природа некоторых причинно-следственных связей не всегда очевидна. Но людям свойственно делать поспешные выводы, что рост числа разработчиков ведет к ускорению разработки. Однако увеличение команды, особенно на поздних стадиях разработки, способно, наоборот, уменьшить скорость (подпункт «Закона Брукса» [Brooks95]). Кроме того, большое число плохих программистов может существенно замедлить работу, и часто бывает, что их удаление из группы хорошо сказывается на общей скорости.

Обратные эффекты. Эффект причинно-следственной связи может быть не только прямым, но и обратным: например, рост A ведет к росту Б, и наоборот. Обратный эффект обозначен на диаграмме символом «О» рядом с линией. Допустим, что увеличение количества дефектов создает препятствия для дальнейшей разработки, что, как следствие, замедляет скорость поставки новой функциональности, потому что люди тратят больше времени на исправление ошибок или поиск обходных путей.

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

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

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

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

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

Словом, нет никаких гарантий того, что введение вознаграждения обусловливает увеличение скорости разработки – или даже влияет на нее.

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

«Быстрые решения». Одно из трудных и медленных решений для увеличения скорости разработки – улучшить человеческий ресурс: нанять сильных разработчиков, расширить обучение и коучинг имеющейся команды, уволить слабых сотрудников. Альтернатива – достичь цели быстро и с наименьшими усилиями за счет «быстрого решения» или так называемого квик-фикса (quick fix). Иногда быстрое решение работает как в краткосрочной, так и в долгосрочной перспективе и действительно улучшает систему. Но иногда это не удается, и тогда получается как в поговорке: «Быстрее – значит медленнее». Например, если стоит цель увеличить скорость поставки новой функциональности, первое, что обычно приходит в голову людям, – увеличить количество разработчиков. Согласно их предположению, это самый быстрый и простой способ решить проблему со скоростью разработки. Итак, добавим в нашу схему это «быстрое решение» (символ БР):

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

Просто провести (обратную) причинно-следственную связь напрямую от бюджета к коэффициенту найма очень дешевых разработчиков не совсем правильно, так как, по сути, это будет означать, что уменьшение бюджета ведет к увеличению найма очень дешевых разработчиков. Мы же хотим показать эффект взаимодействия – а именно то, что причинно-следственная связь A влияет на причинно-следственную связь Б. Чтобы графически показать это, мы проводим линию обратной причинно-следственной связи от бюджета к линии быстрого решения (БР), которая в результате раздваивается на коэффициент найма обычных и очень дешевых разработчиков:

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

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

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

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

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

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

Петли положительной обратной связи. Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.

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

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

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

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

Учимся видеть ментальные модели

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

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

Увидеть ментальные модели – только первый шаг; второй, гораздо более трудный шаг – изменить их. Это искусство не входит в тематику данной книги, хотя успешное внедрение масштабированного скрама требует изменений в привычном образе мышления и выработки совместного понимания в большой группе.

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

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

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

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

История 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) способность команд к обучению. Мы рекомендуем – по крайней мере на старте – игнорировать концепцию «архетипов», представленную в этой книге. Хотя она задумывалась как вспомогательный обучающий инструмент, мы заметили, что она отвлекает и даже отпугивает людей на начальном этапе обучения и применения базового моделирования системной динамики. «Архетипы» не являются частью оригинального подхода к системной динамике.