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

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

Так что же такое «приветствовать изменения»? Это значит:

• Никто не попадет в «беду», когда есть изменение. Мы и руководство компании признаем, что мы люди и можем ошибаться. Гораздо разумнее позволить нам допускать оплошности, а затем исправлять их, чем ждать, что мы сделаем все идеально с первого раза.

• Мы все в одной лодке. Каждый член команды, в том числе клиенты, с которыми мы сотрудничаем, имеет требования к проекту и меняет их. Если требования неправильные, то это наша общая с клиентом ошибка, поэтому нет смысла искать виноватого.

• Мы принимаем решение об изменениях быстро, не дожидаясь, когда будет слишком поздно. Ошибаться, конечно, плохо. Но мы все признаем ошибку, поэтому делаем все, что в наших силах, чтобы исправить ее как можно раньше. То есть стараемся максимально ограничить ущерб.

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

• Мы учимся на изменениях. Это наиболее эффективный способ командного роста и строительства лучшего ПО.

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

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

Термин «командно-административный» заимствован из военной терминологии. В уже упоминавшейся книге «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга», выпущенной в 2010 году, есть интервью Нила Сигела, главного инженера компании Northrop Grumman, который дал определение этому термину:

Эндрю. Я не знаком с военными системами – что такое командно-административная система?

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