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

Эрик спросил: «Как вы думаете, почему все эти менеджеры по работе с клиентами были расстроены?»

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

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

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

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

Точно так же, как и сейчас, – вы говорите об этом команде и выясняете ее мнение.

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

Идея самоорганизующейся команды, где каждый участник решает вопрос о своей следующей задаче перед началом работы, звучит нереально. Часто это происходит потому, что менеджер проекта тратит много усилий на выявление всех зависимостей между задачами. Учебники на тему «Управление проектами» (в том числе те, которые написали мы!) содержат разделы, объясняющие различные типы зависимостей (финиш-старт, старт-старт и т. д.) и то, как их определить и записать при планировании проекта. Так что нет смысла спрашивать, как именно анализ зависимостей проявляется в самоорганизующихся командах.

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

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

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

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

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

Руководители проектов любят цитировать президента США Дуайта Эйзенхауэра, который сказал: «В процессе подготовки к сражению я всегда находил, что планы бесполезны, но планирование необходимо». Когда вы садитесь вместе с командой и планируете проект, каждый думает о деталях работы и конкретных проблемах, с которыми придется столкнуться в ходе ее выполнения. Даже если расчеты руководителя проекта и команды неидеальны, после удачного планирования команда знает о проекте больше и все лучше подготовлены к работе. Когда происходят изменения, команда выявляет их и получает опыт, позволяющий ей в будущем избежать любых ситуаций, вызывающих проблемы планирования. Так почему бы не планировать заранее и получить эти преимущества, особенно если есть возможность изменить план, когда это будет нужно?

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

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

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

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

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

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

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

Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).

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

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

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

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

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

Вы можете узнать больше о самоорганизующихся командах и о том, как управлять scrum-проектами, в книге Кена Швабера Agile Project Management with Scrum (Microsoft Press, 2004).

Вы можете узнать больше о планировании scrum-проекта в книге Майка Кона Agile Estimating and Planning (Addison-Wesley, 2005).

Вы можете узнать больше о scrum-правилах, прочитав The Scrum Guide (Sutherland and Schwaber, 2011). Текст можно скачать на сайте Scrum.org.

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

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

• Многие agile-тренеры считают, что их scrum-команды сталкиваются с проблемами, потому что выбрали владельца продукта из числа команды. Помогите им понять, что владелец продукта должен иметь полномочия принимать разработанные функции от имени компании.

• Проводят ли команды ежедневные встречи, именуемые scrum-митингами, которые по сути являются обычными статус-митингами? Помогите команде осознать разницу между командно-административным управлением и самоорганизацией.

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