Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

Приведу простой пример. В их первой ракете комплекс бортового оборудования контролировался рядом специальных монтажных схем, которые были соединены друг с другом и с ракетой, а переключатели выполнялись из очень редкого унобтаниевого[18] материала. Если одна схема ломалась, нужно было снимать все и восстанавливать сотни коннекторов вручную, используя невероятно дорогие материалы. В какой-то момент редкоземельные элементы, которые они применяли для коннекторов, просто ушли с рынка: Apple и Samsung смели мировой запас для производства нового поколения телефонов. Чтобы раздобыть материалы, потребовалось двенадцать недель. Кемп был в ярости и выругался: «Три месяца, чтобы достать коммутатор Ethernet? Подобное [непотребство] нас в могилу сведет!»

Мой коллега Джо Джастис сел вместе с Итаном, руководителем отдела авионики, и объяснил проблему. «Во-первых, – сказал Джо, – у вас есть все эти схемы со специальными коннекторами и все они разные, каждая передает свою информацию. Вам нужно снизить запутанность, заменить их другими коннекторами, с лучшим дизайном. Но если демонтировать один, сломаются все. Поэтому наладим стабильный интерфейс между комплексом бортового оборудования и другими системами ракеты. Перестроим их так, что они могли передавать все виды данных, больше, чем вам нужно, но с общими коннекторами, которые можно купить готовыми и недорого. Ограничим проблему, сделаем выборку элементов, которые не изменятся. Убедимся, что остальные проектировщики ракеты знают, как нужно подсоединять свой интерфейс, используя одну сторону коннектора, а проектировщики радиоэлектронных систем в курсе, что им нужна вторая. Так вы сможете менять что угодно в любой части системы; пока общий интерфейс сохраняется, неважно, где будет происходить изменение. Нужно сделать задачи модульными. По принципу конструктора LEGO. Чтобы части легко соединялись и разъединялись».

Такой подход упростил формирование критериев готовности: элемент должен работать и подходить известному стабильному интерфейсу. Теперь вы можете решать проблемы одну за другой. Лишний вес из-за самого интерфейса? Займетесь этим позже, когда решите остальные проблемы.

Теперь возьмем пример гибкой архитектуры из сферы программного обеспечения. Схема та же. Spotify – музыкальный сервис. Его цель, как и цель аэрокосмической компании, – скорость. Когда компания еще была стартапом, ее CEO Дэниел Эк как-то сказал Scrum Inc.: «Apple, Google и Amazon хотят нас убить. И это умные, крупные компании со множеством навыков. Единственный способ выжить для нас – скорость. Нам надо быть быстрее, чем они».

Так Spotify разделился на модули, подобно ракете. Есть система воспроизведения, рекомендательный движок, функции плейлиста, мобильное приложение и т. д. И точно так же, как Stealth Space Company, они разработали стабильные интерфейсы между частями. Команды, занимающиеся плейлистами, могут вносить столько инноваций, сколько хотят, менять столько, сколько пожелают, пока их участки укладываются в нужные рамки, передают и получают нужные данные и не ломают ничего другого. Так они могут быстро двигаться вперед и не беспокоиться о том, что повредят другие части системы.

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

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

Исправление

Что вы будете делать? У вас десятки проектов, сотни приоритетов, и все их нужно довести до конца. Так вы решили.

Шаг первый, как и всегда, – признать, что у вас есть проблема. Если ваша стратегия – бессмысленно говорить, что приоритет – это все, вы фактически признаете, что приоритеты вашей компании будет определять самый нижестоящий сотрудник, а затем он же станет решать, что делать дальше, не получит никакого руководства и указания на то, что на самом деле главное.

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