Текст книги "Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство"

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

♦ разъясняет всем заинтересованным сторонам, зачем нужен agile и как стать agile; объясняет выгоды бизнес-ценности, основанной на приоритизации, более высокой ответственности и производительности от наделенных возможностями команд и повышении качества в результате часто проводимых обзоров и т. п.;

♦ поддерживает членов команды путем наставничества, поощрения и оказания помощи; выступает в поддержку обучения и карьерного продвижения членов команды. Парадоксальное высказывание «мы ведем команды вперед, пребывая в их тени» говорит о роли лидера в профессиональном развитии членов своей команды. Благодаря поддержке, поощрению и профессиональному развитию члены команды приобретают уверенность в своих силах, берут на себя дополнительные задачи и вносят вклад на более высоких уровнях в своих организациях. Главная роль обслуживающего лидера состоит в воспитании и развитии членов команды в ходе исполнения ими своих текущих ролей и в последующем, даже если это может привести к их уходу из команды;

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

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

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

ПОЛЕЗНЫЙ СОВЕТ

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

Согласно определения в Руководстве PMBOK® – Шестое издание, руководитель проекта – это «лицо, назначенное исполняющей организацией руководить командой и отвечающее за достижение целей проекта».

Многие руководители проектов привыкли находиться в центре координации проекта, отслеживать и представлять всей остальной организации статус команды. Такой подход не вызывал возражений, пока проекты распадались на разрозненные функции.

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

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

Главная установка как ценностей, так и принципов Agile-манифеста состоит в утверждении важности людей и взаимодействия. Подход agile оптимизирует поток ценности, обращая основное внимание на быструю поставку определенного свойства заказчику, а не на то, как «используются» люди.

ПОЛЕЗНЫЙ СОВЕТ

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

Когда команда думает, как оптимизировать поток ценности, очевидными становятся следующие преимущества:

♦ вероятность сотрудничества между людьми становится выше;

♦ команды быстрее завершают создающие ценность работы;

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

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

Кроссфункциональные agile-команды часто производят функциональный продукт инкрементно. Это объясняется тем, что члены таких команд несут коллективную ответственность за работу и только все вместе обладают необходимыми навыками для поставки конечного результата.

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

Структуры команд проекта, которые улучшают сотрудничество внутри команд и между ними, дают преимущества проектам agile. В таблице 4–1 показано, как сотрудничающие члены команды резко повышают производительность и способствуют инновационному решению проблем.

Таблица 4–1. Свойства успешных agile-команд

В agile имеются три общепринятые роли:

♦ члены кроссфункциональной команды,

♦ владелец продукта,

♦ фасилитатор команды.

Эти роли в команде описаны в таблице 4–2.

Таблица 4–2. Роли в agile-команде

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

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

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

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

«ЛЮДИ С I-ОБРАЗНОЙ И Т-ОБРАЗНОЙ КВАЛИФИКАЦИЕЙ»

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

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

Во многих отраслях команды приняли принципы и практики agile. Они организуют людей на принципах кроссфункциональных команд с целью итеративной разработки рабочих продуктов.

ПРАКТИЧЕСКИЙ ПРИМЕР

Члены основной команды, сформированной для подготовки текста настоящего Практического руководства, имели разный предшествующий опыт работы, когда некоторые из них представляли PMI, другие – Agile Alliance. Чтобы выполнить работу, они самоорганизовались и работали инкрементно. PMI собрал группу экспертов по предметным областям для инспектирования работы, что позволило команде использовать результаты обратной связи и улучшать продукт по мере его разработки. Однако основная команда не была образцом типичной команды agile, так как рабочее время ее членов не было полностью (на 100 %) посвящено этому проекту.

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

В одном крупном финансовом учреждении США осуществлялась программа с участием нескольких команд, одни члены которых находились на Восточном побережье США, а другие – на территории Индии. Когда эта команда впервые приступила к работе, она представляла собой одну большую рассеянную команду (UX, аналитики, разработчики и тестировщики), члены которой вели разработку в порядке «следуя за солнцем»[9]9
  Процесс разработки в порядке «следуя за солнцем» – это процесс, когда работа в конце каждого рабочего дня передается из одного рабочего места в другое, находящееся от него в нескольких часовых поясах, с целью сократить время разработки продукта.


[Закрыть], когда рабочее время разных членов команды накладывалось друг на друга, что позволяло передавать работу из рук в руки на ходу. Члены команды проводили совместные ежедневные летучки с использованием веб-камер, чтобы охватить всех членов команды. Основные роли (аналитики, владельцы продукта, UX-дизайнеры и лидеры разработки) в США выходили на связь раньше, чтобы ответить на все вопросы, которые возникали у их коллег в Индии, и помочь в устранении препятствий.

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

У них также был основной состав аналитиков, находившихся в двух местах в США, которые вели работу со своим менеджером продукта и владельцами продукта в США, а затем – с каждой из команд соответственно. Хотя у них действовала определенная структура, – они проводили анализ продукта в рамках всей программы, – большая часть их прочей деятельности осуществлялась на уровне команды, исходя из того, что было наиболее полезно для команды, чтобы создать для ее членов возможность самоорганизации.

Что происходит, когда члены команды уделяют менее 100 % рабочего времени работе в команде? Хотя такая ситуация далека от идеала, к сожалению, в некоторых случаях ее невозможно избежать.

Основная проблема в ситуации, когда сотрудник уделяет работе в команде от 25 % до 50 % своего времени, состоит в том, что он работает в многозадачном режиме и вынужден переключаться от задачи к задаче. Многозадачный режим работы снижает производительность команды и отрицательно влияет на ее способность уверенно прогнозировать поставку.

ПОЛЕЗНЫЙ СОВЕТ

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

При переходе от одной задачи к другой производительность труда людей снижается на 20–40 %. Снижение производительности труда растет экспоненциально по мере увеличения количества задач.

Когда человек выполняет два разных проекта, его вовлеченность в каждый проект не составляет 50 %. В действительности, из-за дополнительных потерь от переключения между задачами его отдача в каждом проекте составит от 20 % до 40 %.

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

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

ПРАКТИЧЕСКИЙ СОВЕТ

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

Дополнительные советы о работе команд в средах agile, в частности о процессах в области знаний об управлении ресурсами проекта, см. в таблице А1-2 о разделении по группам процессов управления проектом и областям знаний.

ПОЛЕЗНЫЙ СОВЕТ

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

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

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

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

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

В числе заслуживающих внимания методов управления коммуникациями в рассеянных командах можно назвать «аквариумные окна» (fishbowl windows) и «удаленную работу в парах» (remote pairing):

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

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

ПОЛЕЗНЫЙ СОВЕТ

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

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

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

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

Дополнительную информацию о командах см. в приложении Х2 о свойствах, оказывающих влияние на адаптацию.

ПОЛЕЗНЫЙ СОВЕТ

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