Постигая Agile

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

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

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

Часто задаваемые вопросы

Как мне поступить с зависимостями между задачами в моем плане проекта?

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

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

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

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

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

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

Все это хорошо в теории, но будет ли это работать на практике?