Текст книги "Гибкое управление. Как перевести всю компанию на скрам"

Глава 4
Долой мышечную память: проблемы перемен

Если вы уверены, что более 29 % клиентов довольны проектами разработчиков из вашей группы[12]12
  Jim Johnson, My Life Is Failure, The Standish Group International, Inc., 2006, p. 2.


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

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

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

«Водопадное» мышление

«Водопадный» процесс родился из стремления руководителей проектов преодолеть сложность с помощью предсказуемости. Эта модель царила в области разработки в течение последних 25 лет. «Водопадный» подход изучают в университетах, он представлен в большинстве книг о процессах и в другой литературе как самый правильный, а Институт управления проектами[13]13
  Речь идет о PMI (Project Management Institute) – одной из наиболее авторитетных организаций по управлению проектами в мире, которой принадлежит авторство большого количества методик, курсов и других обучающих материалов. Самая распространенная в мире сертификация проектных менеджеров – PMP^© – принадлежит PMI. Также эта организация является автором PMBoK (Project Management Body Of Knowledge) – свода знаний по управлению проектами. – Прим. науч. ред.


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

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

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

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

Однажды я присутствовал на встрече по обзору спринта. Для спринта скрам-команда выбрала из бэклога продукта пять элементов, но завершила только один из них. Команда оправдывалась: дескать, специалисты по обеспечению качества (тестированию) не успели завершить тестирование. Но ведь скрам-команда кросс-функциональна по определению. За создание завершенных функциональных элементов в каждом спринте отвечают все. С тестированием не справились не тестировщики, а вся команда. Скрам предполагает, что каждый сделает все для выполнения работы. Там, где требуется функциональная специализация, инициативу берут сотрудники с соответствующими навыками, но исполнителями могут быть все[14]14
  В современном аджайл-управлении все дальше уходят от понятия Т-shaped специалистов в пользу T-shaped команд. Во времена написания этой книги действительно считалось нормальным, что программисты приходят на помощь тестировщикам, а тестировщики могут писать несложный код. Сейчас же превалирует подход, когда команда способна самостоятельно реализовать любой элемент бэклога продукта. Взаимопомощь не отменяется, но большее внимание уделяется процессам планирования и внутрикомандного взаимодействия. Главным считается необходимый набор навыков внутри команды, а не наличие универсальных участников в ее составе. Такова эволюция подхода. – Прим. науч. ред.


[Закрыть].

Компания Trey Research (TR), наше первое воображаемое предприятие, разрабатывает акустические продукты. TR собиралась вывести на рынок новый радиоприемник. Склад был забит товаром, готовым к продаже. Основатель и генеральный директор компании д-р Трей, читая в своем кабинете инструкцию для пользователей, хмурился все больше и больше. Наконец он вызвал технического писателя Матиаса Берндта и сказал, что разочарован документацией – пользоваться ею невозможно. Берндт согласился, но заметил, что она в точности отражает принципы работы приемника. Сохраняя спокойствие, д-р Трей попросил Берндта прогуляться на склад, открыть коробку с приемником и проверить, действительно ли он работает так, как указано в технической документации. Два часа спустя Берндт вернулся в кабинет д-ра Трея с приемником в одной руке и с инструкцией в другой. И сказал: «Мне, конечно, очень неприятно об этом говорить, д-р Трей, но приемник работает в точности так, как написано в инструкции».

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

Управление и контроль

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

Слушатели курса подготовки сертифицированных скрам-мастеров убеждаются в эффективности самоуправления, выполняя следующее упражнение. Вначале организуется замкнутое пространство площадью около 40 м². В нем беспорядочно располагаются стулья, столы и прочие препятствия. Участники разбиваются на пары: начальник и подчиненный. Начальник должен добиться с помощью команд «старт», «стоп», «налево», «направо», «быстрее» и «медленнее», чтобы подчиненный за 2 минуты сделал 60 полных шагов. По истечении 2 минут оказывается, что 60 шагов сумели сделать только 50 % подчиненных. Во второй части упражнения пары разбиваются. Каждый участник становится работником, который сам управляет своей работой. Использовать можно вышеперечисленные указания или придумать новые, более подходящие. Каждого просят сделать 60 полных шагов и остановиться. Все выполняется за минуту. Самоуправление во второй части упражнения удваивает эффективность. А поскольку теперь начальники тоже становятся работниками, она возрастает вчетверо.

Сертифицированные скрам-мастера знают, что самоуправляемые скрам-команды более продуктивны. Их сознание на 10 % принимает идею самоуправления, но на 90 % уверено, что они по-прежнему отвечают за все. Если что-то пойдет не так, они вмешаются и подскажут команде, что нужно делать. Нас приучили считать, что только таким способом можно обеспечить абсолютно бесперебойную работу. Отказаться от привычки управлять и контролировать очень трудно.

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

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

Обязательства, противоречащие законам природы

Я живу в Бостоне и по работе часто бываю в Нью-Йорке. Челночный рейс Delta Airlines из аэропорта Логана, недалеко от Бостона, в нью-йоркский аэропорт Ла-Гуардия занимает всего 45 минут. Это так удобно, что иногда я назначаю по несколько встреч в день.

Однажды утром, едва проснувшись, я отправился в Нью-Йорк на встречу. К 14:00 я уже был в Ла-Гуардии, чтобы успеть на обратный рейс до Бостона в 14:30. На 16:30 у меня была назначена встреча в центре Бостона, и я бы не выбился из графика, если бы не туман, из-за которого все дневные рейсы были задержаны или отменены. Я подошел к стойке компании Hertz по прокату автомобилей и сказал служащей, что через полтора часа должен быть в Бостоне и мне нужна машина. Она посмотрела на меня как-то странно. Конечно же, я хотел невозможного. Правила дорожного движения, максимальная скорость доступных в прокате автомобилей и расстояние между Бостоном и Нью-Йорком делали мое требование смехотворным и невыполнимым. Оно противоречило законам физики.

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

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

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

■ Кто-то просит вас создать продукт к определенной дате. Вы должны это сделать, потому что он уже дал кому-то обещание выпустить продукт именно к этому числу. Теперь он хочет, чтобы вы своим обязательством подкрепили его обязательство. Вы не знаете точно, в чем состоит его обязательство, но от этого человека зависит ваша карьера и зарплата. Возьмете ли вы на себя обязательства?

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

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

Сокрытие реальности

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

Во втором спринте скрам-команды замахнулись на большой объем работ из бэклога продукта. Прошло две недели с начала спринта, и команды поняли, что дело плохо. Собравшись вместе, они обнаружили, что у всех одна и та же история: функциональность была значительно сложнее, чем в первом спринте. Было ясно, что из обещанных 24 функций они смогут реализовать семь или восемь. После первого обзора спринта, когда все их хвалили, было страшно представить, что будет, если они выполнят только 33 % второго спринта. Команды решили, что единственный способ выполнить работы полностью – это отказаться от тестирования и рефакторинга; они просто наложат новую функциональность на старую. Надежда была на то, что если в третьем спринте взять на себя меньше обязательств, то времени хватит, чтобы вернуться и все исправить.

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

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

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

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

Подведем итоги

Итеративная, инкрементальная природа скрама ведет к изменениям внутри компании. Компания должна адаптироваться к тому, что изменения вносятся в проект ежемесячно[15]15
  Это снова отсылка к спринтам длительностью месяц. – Прим. науч. ред.


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

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