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

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

«Культура ест стратегию на завтрак», – сказал Питер Друкер (Peter Drucker).

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

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

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

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

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

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

Рис. 6–2. Пример оценки культуры организации

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

Как было сказано выше в настоящем Практическом руководстве, одной из ценностей Agile-манифеста является следующая: «сотрудничество с заказчиком важнее согласования условий договора». Многие проекты потерпели неудачу из-за разлада в отношениях между заказчиком и поставщиком. Уровень риска по проекту выше, когда участвующие в договоре стороны занимают позицию с точки зрения «победитель против проигравшего». Сутью подхода сотрудничества является стремление установить отношения «совместный риск – общая выгода», когда выигрывают все участвующие стороны. В числе методов заключения договоров, которые могут формально закрепить данные отношения, можно назвать следующие:

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

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

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

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

Культура против структуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ Управление заинтересованными сторонами. Обеспечивают владельцу продукта обучение и консультирование по вопросам приемочного тестирования, оценки и осуществления обратной связи о системах. Отстаивают важность экспертов по предметным областям (subject matter experts, SMEs) для проектов.

♦ Осуществление набора, отбора и оценки лидеров команд. Разрабатывают указания по проведению собеседований с agile-практиками.

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

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

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

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

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

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

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