Другими словами, двум людям нужно сделать невозможное. Вы должны прочитать мысли заказчика. А он – предсказать будущее. Когда вы смотрите на вещи с таких позиций, вам намного проще принимать изменения. Но если вы хотите противостоять изменению проекта и упорно придерживаться изначального плана, то выход тоже есть: просто убедитесь, что все члены вашей команды ясновидящие.
Так что же такое «приветствовать изменения»? Это значит:
• Никто не попадет в «беду», когда есть изменение. Мы и руководство компании признаем, что мы люди и можем ошибаться. Гораздо разумнее позволить нам допускать оплошности, а затем исправлять их, чем ждать, что мы сделаем все идеально с первого раза.
• Мы все в одной лодке. Каждый член команды, в том числе клиенты, с которыми мы сотрудничаем, имеет требования к проекту и меняет их. Если требования неправильные, то это наша общая с клиентом ошибка, поэтому нет смысла искать виноватого.
• Мы принимаем решение об изменениях быстро, не дожидаясь, когда будет слишком поздно. Ошибаться, конечно, плохо. Но мы все признаем ошибку, поэтому делаем все, что в наших силах, чтобы исправить ее как можно раньше. То есть стараемся максимально ограничить ущерб.
• Мы перестаем думать об изменениях как об ошибках. На основании имевшейся на тот момент информации мы делали все возможное, и только теперь стало ясно, что мы были неправы. Благодаря принятым решениям мы увидели перспективу и признали необходимость в изменениях, которые нужно сделать сегодня.
• Мы учимся на изменениях. Это наиболее эффективный способ командного роста и строительства лучшего ПО.
Возможно, вы подумали, что идея приветствовать изменения требований интересна и может помочь проектам или, наоборот, что она ужасна. Это довольно распространенная реакция. Многие из тех, кто работает в команде разработчиков программного обеспечения (особенно традиционные руководители проектов), чувствуют себя неуютно, впервые узнав об этом.
Эти менеджеры ежедневно сталкиваются с изменениями, но гибкие методологии предполагают совершенно иное решение. В agile-практиках традиционное отношение к изменениям проекта считается командно-административным подходом.
Термин «командно-административный» заимствован из военной терминологии. В уже упоминавшейся книге «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга», выпущенной в 2010 году, есть интервью Нила Сигела, главного инженера компании Northrop Grumman, который дал определение этому термину:
Эндрю. Я не знаком с военными системами – что такое командно-административная система?
Нил. Это информационная система военных командиров. Она позволяет им общаться друг с другом и поддерживать ситуационную осведомленность: знать расположение войск и их статус. Благодаря этому командир понимает, что происходит. Раньше сражения проходили на небольших площадях и командир мог стоять на холме с биноклем и наблюдать за происходящим. Но примерно к 1900 году поля сражений стали настолько большими, что вы уже не можете стоять на холме, как это делал Наполеон. Вы должны начать использовать технологию, чтобы «видеть» все поле боя. И системы, которые делают это, называются командно-административными.
Командно-административное управление проектом похоже на военную систему.
• Слово «командное» имеет отношение к тому, как руководитель проекта распределяет работу в команде. Команда может не отчитываться перед руководителем, но он контролирует выполнение всех своих распоряжений. Он делит работу на части, создает график выполнения задач, распределяет их и ресурсы внутри команды.
• Слово «административное» описывает способ, при помощи которого руководитель управляет изменениями. Каждый проект сталкивается с изменениями: работа занимает больше времени, чем ожидалось, люди болеют или покидают проект, оборудование выходит из строя и т. д. Руководители проектов постоянно следят за этими изменениями и управляют проектом, оценивая каждое изменение, обновляя планы, включая изменения в графики работ, производя назначения в команде, а также управляя ожиданиями всех заинтересованных сторон, чтобы исключить неожиданности.
Причина, по которой традиционный менеджер проекта испытывает неудобства, впервые столкнувшись с изменениями, в том, что те же самые проблемы будут происходить и в agile-проектах, и команда должна быть в состоянии отвечать на них. Простое принятие изменений выглядит как гарантированный способ хаотизировать проект. Если agile-команды не используют командно-административный подход, то как они умудряются справляться со всеми этими изменениями, одновременно решая и все те проблемы, с которыми проектные команды сталкиваются ежедневно?
Рис. 3.1. Команда использует итерации для частой доставки работающего программного обеспечения, добавления новых функций с каждым релизом
Ключ к одобрению изменений без внесения хаоса заключается в частой поставке рабочей программы. Команда использует итерации, чтобы разбить проект на части с регулярными сроками сдачи. Во время итераций команда поставляет рабочее ПО. По окончании каждой итерации команда проводит демонстрацию, показывая клиенту созданный продукт, а также предыдущие варианты, чтобы посмотреть, какие уроки можно извлечь из данной ситуации. Затем начинают сеанс планирования, чтобы выяснить, что они будут создавать в следующей итерации. Предсказуемый график и постоянные точки контроля помогают команде отследить эти изменения на ранних стадиях и создают атмосферу, в которой не принято искать виноватого, когда каждый может обсудить изменения и придумать стратегию, чтобы включить ее в проект.
В этот момент Agile становится привлекательной для традиционного командно-административного менеджера проекта. Такой менеджер хочет контролировать срок. Установка ограничений на продолжительность итераций дает ему эту возможность. Кроме того, решается также одна из главных задач менеджера – работа с изменениями, которые возникают в самом конце проекта. Один из наиболее сложных моментов в работе традиционного менеджера – мониторинг изменений. Ежедневные отчеты и ретроспективы итераций позволяют руководителю проекта заручиться поддержкой всех членов команды, ведь они теперь глаза и уши руководителя, помогающие обнаружить необходимость изменений, прежде чем они станут причиной более серьезных проблем в проекте.
Роль менеджера проекта в том, чтобы инициировать замену командно-административной системы управления, при которой ему необходимо ежедневно давать задания членам команды и постоянно корректировать план работ, чтобы направить их в нужное русло. Теперь менеджер взаимодействует с командой лишь для того, чтобы убедиться: каждый специалист видит единую картину и трудится над общими целями. Проще всего это выполнить, когда команда работает в режиме коротких итераций, позволяющих поставлять рабочее программное обеспечение. Это ставит перед каждым участником конкретные цели и дает ему исчерпывающее представление о том, над чем работает команда, а также чувство ответственности не только за свою работу, но и за общий результат по окончании итерации.
Как эти принципы могут помочь нашему проекту «Электронная книга»? Вспомним о проблемах, с которыми столкнулась команда: их проект провалился, потому что отсутствовали важные функции, которые были у конкурентов (поддержка отраслевого стандартного формата для электронных книг и предоставление пользователям доступа к почте на этом устройстве), а функции оказались неактуальными (шаблон для создания интернет-магазина).
Давайте снова запустим проект, но на этот раз менеджер разделит работу команды и стейкхолдеров на месячные спринты. Ситуация сразу стала иной.
• После третьего спринта один из разработчиков сообщил, что был утвержден новый формат отраслевого стандарта для электронных книг. Команда решила реализовать библиотеку, которую согласилась разрабатывать на четвертом спринте, а на пятом включила ее в пользовательский интерфейс читателя.
• После десяти месяцев разработки они произвели сборку программы, которую можно было загружать в прототип электронного устройства и раздавать бета-версии первым пользователям. Руководитель проекта, поговорив с ними, обнаружил, что они действительно хотели бы иметь доступ к документам Microsoft Word и газетным статьям в своих электронных книгах. Команда выделила часть следующего спринта на разработку почтового интегратора для электронной книги, чтобы пользователи могли рассылать статьи со своих устройств.
• Год активного участия стейкхолдеров в проекте позволил команде узнать, что шаблон для интернет-магазина не нужен, потому что розничные продавцы используют стандартный формат электронной книги. К счастью, на разработку этой функции ушло не так много времени, потому что нужно было заниматься более важными вещами.
Поскольку команда всегда поставляла рабочее программное обеспечение после каждого спринта, удаление функции из списка невыполненных работ означало, что они могли завершить работу раньше! Партнер-издатель был уже с книгами, потому что все его старшие руководители получили ранние версии ПО и прототипы оборудования для его использования. Это поддержало их вовлеченность и простимулировало подготовку к получению книги к моменту выхода первой версии продукта.
Используя непрерывные релизы, приветствуя изменения и предоставляя рабочее программное обеспечение после каждой итерации, команда проекта «Электронная книга» сумела поставить успешный продукт гораздо раньше. В отличие от неэффективного водопадного подхода, в котором утвержденные в начале проекта требования отгородили команду от клиентов, agile-методология позволила команде все время взаимодействовать с клиентами. Это дало возможность реагировать на изменения и создать лучший продукт.