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

Перестаньте начинать, начните заканчивать

Когда мы со Scrum Inc. приходим в компанию для оценки ее гибкости, то, как правило, обнаруживаем, что около 30 % ее работы выполнять вовсе не нужно. Чаще всего она идет вразрез с целями бизнеса. Остановитесь. Согласно данным Standish Group и нашим наблюдениям, 64 % из оставшихся 70 % задач – работа над функциями, которыми потребитель пользуется редко или не пользуется вовсе. Получается, 75 % сотрудников компании либо активно работают против интересов бизнеса, либо корпят над тем, что никому не нужно. Попробуйте осознать это. Три четверти сотрудников вашей компании не должны заниматься тем, чем они занимаются.

Причина в том, что люди отказываются от приоритизации или не знают, как ее выполнять. (Еще один маленький лингвистический факт: очевидно, слово prioritize (приоритизировать) не утвердилось в английском языке до тех пор, пока бюрократы в правительстве не придумали его в 1950-е и не популяризировали в президентской кампании 1972 года, когда политическим деятелям пришлось выбирать целевые избирательные округа. По данным Оксфордского словаря английского языка 1982 года, это «слово, которое в настоящий момент нетвердо зафиксировано в языке». Очевидно, так же нетвердо оно зафиксировано в практиках сотрудников.)

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

У нас есть множество противоречащих друг другу приоритетов.

Наши команды постоянно переключаются на новые приоритетные задачи.

Все задачи – с приоритетом номер один.

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

В Confirmation.com у каждого были свои приоритеты. Отдел продаж требовал более качественный перевод на японский, чтобы продавать продукт в Японии; маркетинг хотел запустить ребрендинг сайта; руководство занималось вопросами конкуренции. На чем же сфокусироваться продуктовым командам? «Я всегда с нетерпением жду, какие же новые правила прозвучат сегодня», – сказал один из руководителей компании в беседе с Ави Шнейером, руководителем проекта со стороны Scrum Inc. Когда Ави спросил, что главное для компании, ему ответили: «Выполнение работ в срок». Заметьте: срок сам по себе, а не задача, которую нужно решить.

Ави хотел, чтобы они работали над настоящими приоритетами компании. Что важнее всего? Он помог компании увидеть, что без списка приоритетов она все равно что без руля и каждый день выбирает новое направление. И она сделала верный выбор. Это возможно, но требует искренней рефлексии и трудных решений.

Результаты работы vs Результаты деятельности

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

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

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

В Confirmation.com самой большой проблемой была унаследованная система. Она работала хорошо. Но с годами она медленно обрастала новыми функциями, нужными потребителям, исправлениями и расширениями элементов. Каждая часть добавлялась без раздумий об архитектуре и структуре системы. И естественно, последняя превратилась в такой беспорядок, что на исправление старых ошибок ушло больше времени, чем потребовалось бы на создание новой системы. Со временем компания поняла: несмотря на загруженность сотрудников, значительного прогресса нет. Работники не могли эффективно доводить дела до конца. Сосредоточившись на занятости, то есть результатах работы, руководители не обращали внимание на результаты деятельности. Нужна была новая, более современная система, позволяющая обеспечить клиентам сервис даже лучший, чем те хотели. Но все продолжали работать над старой системой, результатами работы, а не деятельности.

Критерии готовности и сущность архитектуры

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

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

Существует некая частная космическая компания, которую я назову Stealth Space Company (Незаметная космическая компания). Так они называют себя на своей странице в LinkedIn, в любой нежелательной публикации в СМИ и постоянно всем повторяют: «Мы не хвалимся, мы не говорим – мы делаем». Они располагаются на заброшенной морской авиационной станции на краю залива Сан-Франциско у побережья США. Военные базы вроде этой отличаются в зависимости от расположения и основавшей их службы, но у них есть одна общая черта – жесткая, бескомпромиссная архитектура, в которой функциональность доминирует над формой.

Крис Кемп – СЕО этой компании. У него светлые волосы, он обычно носит черные футболки, пиджаки и брюки. Его мантра – скорость. Приведу отрывок из его письма, в котором он анонсировал первую попытку запуска.

В воскресенье мы планируем запуск ракеты. Ее с нуля спроектировала команда, которой 18 месяцев назад не существовало. Мы сделали работу в пять раз быстрее, в пять раз дешевле, чем кто-либо до нас. Это первый тестовый запуск серии, и он позволит нам достичь земной орбиты, поскольку мы создаем команду и меняем свои действия на основании того, что узнали из каждой попытки.

Он смотрит на компанию SpaceX Илона Маска и видит цель, которую не просто превзойдет, но превзойдет громко: в пять раз быстрее и в пять раз дешевле. И он использует Scrum, чтобы добиться того, чего хочет. Его цель – стать космическим FedEx[17]17
  Американская грузовая авиакомпания.


[Закрыть], ежедневно отправляя небольшие целевые нагрузки на низкую орбиту. Армии необходим комплекс разведывательных спутников над новой проблемной зоной? Без проблем; спутники будут там через 30 минут, а не через три года.

Беседуя с его сотрудниками, вы чувствуете их стремление к успеху. Один из его лидеров всю свою карьеру посвятил космическому бизнесу: SpaceX, Virgin Galactic, Boeing. Он сказал, что некоторые члены его команды полагали, будто фреймворк Scrum подходит только для программного обеспечения.

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

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

Приведу простой пример. В их первой ракете комплекс бортового оборудования контролировался рядом специальных монтажных схем, которые были соединены друг с другом и с ракетой, а переключатели выполнялись из очень редкого унобтаниевого[18]18
  Унобтаний или анобтаниум (Unobtainium) – «недостижимый, недоступный» – ироничное название любого крайне редкого, дорогого либо физически невозможного вещества.


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

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

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

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

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

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

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

Исправление

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

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

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

В Confirmation.com Ави и другой мой коллега Алекс Шейве рассадили всех в комнате и поместили все действия, которые они хотели выполнить, на стену. Они работали с менеджментом, чтобы создать ясный, приоритизированный бэклог для команд. Они убедили руководство в том, что необходима стабильность, не стоит перемещать людей между командами, и распространили это послание по всей организации. Руководители поддерживали Scrum и были готовы трудиться. Они внимательно просмотрели список задач, которые хотели выполнить, и решили, за какие именно они не собираются браться, чтобы понять, что на самом деле нужно сделать.

Это первый шаг: признать, что у вас не все и не всегда получается сразу. Нужно делать выбор. И иногда это сложно. Зачастую сталкивается множество конкурирующих интересов. Но если руководство не синхронизировано и не понимает, что должно быть сделано и в каком порядке, у команд тоже не будет понимания, что им делать. Руководство Confirmation.com смогло с этим справиться. Они изменили и модернизировали структуру и убедились в том, что каждая команда имеет понятный, приоритизированный бэклог на каждый спринт. И это кардинально изменило всю работу.

Важность слова «нет»

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

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

Одно подразделение не могло выпускать продукты на рынок достаточно быстро. У них были великолепные идеи, но не получалось довести их до ума. Тогда они обратились в Scrum Inc., и в начале 2016 года спокойный молодой человек Стив Даукас пришел к ним, чтобы узнать, чем он может помочь.

Он собрал руководство лаборатории в одной комнате и сказал: «Для начала поговорим о том, что вы делаете. Перечислим все проекты на стикерах и поместим на стены, чтобы все было видно».

Через четверть часа напряженного сочинительства все проекты были на стенах. Их оказалось больше сотни.

«Хорошо, – сказал Стив. – Интереса ради давайте напишем на каждом проекте имена тех, кто над ним работает. Кто эти люди?»

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

«Почему вы работаете над несколькими задачами?» – спросил Стив.

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

«А хоть один из них уже готов?»

Тишина в ответ.

Я слышал этот разговор в разных вариантах от разных людей, начиная с родителей малышей и до стартапов и компаний из списка Fortune 500. Им столько нужно сделать, что они начинают миллиард проектов одновременно. По их мнению, они должны так поступать. А потом они говорят: «Смотрите, сколько мы делаем! Мы так заняты, это безумие! Мы работаем над всеми этими важнейшими задачами».

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

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

Тогда Стив вынудил группу признать, что не все ее проекты будут завершены. Более того, если она продолжит в том же духе, то не будет сделано ничего.

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

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

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

За десять недель их продуктивность выросла вдвое, они открыли новые возможности получения прибыли, которых не видели раньше, устранили более 53 препятствий, возникших на пути команд. Поскольку цель сместилась с результатов работы на результаты деятельности, произошли структурная реорганизация и значительные изменения. Стандартный цикл разработки длился два с половиной года; со Scrum выходило по два новых продукта каждые шесть недель. Подразделение привлекло покупателей, крупных клиентов, которые сразу захотели купить его продукты. Вот на что способен правильный фокус. Люди смогли перейти от сотен проектов, которыми никто не занимался, к двенадцати, которые выполнялись. Они изменили судьбу подразделения и повлияли на котировки акций многомиллиардной материнской компании.

Сфокусированность на доведении дела до готовности дает свои плоды. Нужно только уметь говорить «нет».

Не «в работе», а «готово»

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

Вот что с нами сделала многозадачность. Приведу цитату из своей любимой работы по данной теме.

Даже если участники дорожного движения направляют взгляд на объекты в зоне вождения, они часто не могут «увидеть» их, когда говорят по мобильному телефону, поскольку их внимание перенаправлено с внешней обстановки на внутренний когнитивный контекст, ассоциирующийся с переговорами[19]19
  Strayer D., Drews F., Crouch D. A Comparison of the Cell Phone Driver and the Drunk Driver // Human Factors. 2006. Summer. Vol. 48. № 2. Pp. 381–391.


[Закрыть].

Люди будут смотреть на объект – машину, в которую они вот-вот врежутся, или дерево, которое вот-вот погладит капот их автомобиля, – и не видеть его. Однако мы продолжаем разговаривать по телефону за рулем.

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

Вспомните: сколько раз вы отвлекались, пока читали эту книгу? А эту главу? Вам кто-то писал, пока вы читали эту страницу? Прочтя это предложение, вы посмотрели в телефон? Вы изучаете сообщения, которые пропустили за время чтения этой главы? Современное общество ожидает, что мы немедленно будем отвечать на то, что отвлекает нас. Если вы не ответите на письмо, или сообщение, или СМС немедленно, вы обидите человека, который зашел в Facebook и помахал вам, требуя внимания. Сколько раз вчера вы прерывались, отвлекались от общения с людьми, которые сидели прямо перед вами, чтобы ответить на электронное письмо от того, кого нет в комнате? И в конце дня начатые дела не закончены, вы еще не читали другое, действительно важное письмо, забыли о значимом деле и не можете вспомнить, что должны были сделать. И вот вы возвращаетесь к задаче, которой должны были заниматься, но уже понятия не имеете, о чем думали и куда направлялись. Но это не важно, пора ехать забирать детей из школы.

На эту тему есть исследования: согласно им, люди не способны к многозадачности. Поместите людей в аппарат МРТ, попросите выполнять несколько заданий одновременно, и вы увидите, что они не могут справиться с этим. Однако, делая выбор, отказываясь, четко определяя приоритеты, вы можете изменить свою судьбу. Международный производитель смог. Confirmation.com тоже. Stealth Space Company запустила свою первую ракету. Мы живем в постоянно меняющемся мире, есть способы выжить в нем и даже процветать. Но для этого нужны настоящие открытия, настоящий выбор. В первую очередь (подробнее я расскажу об этом в главе 5) нужно спросить себя, что движет вами: страх или надежда. Вам решать. Даже если вы думаете, что все вышло из-под контроля. Даже если вы видите, как приближаетесь к пропасти. Именно вам решать, что с этим делать.

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

ВЫВОД

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

Доводите дело до конца. Здесь нужно заранее определить, что значит «готово». Когда команда выбирает элемент из бэклога продукта, она должна знать, когда его можно считать готовым, как он встраивается в систему других элементов. Архитектура вашего продукта определяет критерии готовности.

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

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

БЭКЛОГ

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

2. Каковы ваши критерии готовности? Запишите их. Поместите на стену так, чтобы каждый мог видеть их каждый день.

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

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