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

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

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

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

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

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

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

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

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

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

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

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

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