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