Почему изменения в проекте несут эмоциональную окраску? Понимание этого вопроса – ключ к данному принципу. Вспомните, когда в последний раз вы, работая над проектом, узнали, что нужно внести изменения в уже созданное. Что вы чувствовали? До этого момента казалось, что дела идут хорошо. Вы, наверное, многое успели обдумать – например, как структурировать работу, что создавать и что обещать клиентам. И вдруг кто-то, не участвующий в проекте, заявляет, что вы ошибались – и планирование, и работа были сделаны неправильно.
Такое трудно принять, особенно если вы делали работу именно для этого человека. Почти всеми инженерами-программистами движет чувство гордыни великого мастера: они хотят поставлять продукты, которые могут поддерживать и которые удовлетворяют потребности пользователей. Изменения в проекте угрожают этому, потому что ставят под сомнение тот путь, который они выбрали, и те допущения, которые они сделали.
Очень часто вам сообщают, что нужно изменить курс, после того как вы его выбрали.
Если этот человек уже объяснил, что именно нужно делать, и вы наполовину выполнили его требования, то вас очень огорчит его неожиданное заявление: «Я подумал вот о чем – а не можем ли мы создать что-то совсем другое?» Он не уважает ваш труд. Теперь вам придется внести изменения в уже сделанное. Трудно при этом не испытать возмущения! И хуже всего приходится тому, кто несет ответственность за результат и не соблюдает сроки.
Почти каждый профессиональный разработчик хотя бы раз попадал в подобную ситуацию. Поэтому понятно, что мы не можем заставить себя приветствовать изменяющиеся требования.
Первый шаг навстречу меняющимся требованиям – попытаться посмотреть на ситуацию с точки зрения клиента. Это не всегда легко, но поучительно. Как вы думаете, заказчик, направивший вас по ложному пути, хотел этого? Представляете, что творилось у него в душе, когда он понял, что несколько месяцев назад распорядился создать неправильное ПО и из-за этого вы потратили массу времени на выполнение ненужной работы? Он приходит к вам с просьбой изменить это. Кроме того, он признает свою ошибку, которая, к сожалению, будет стоить вам дополнительной работы. Это нелегко сделать. Неудивительно, что часто клиенты подолгу не решаются прийти к команде и попросить об изменениях! Им стыдно и к тому же не хочется приносить плохие новости. Все сроки будут сорваны, ну и пусть! Если у заказчика есть потребности, а компания готова тратить деньги на разработку ПО, удовлетворяющего их, то в случае их неудовлетворения проект не будет иметь ценности. И это вина заказчика, потому что именно он ошибся в начале проекта.
Другими словами, двум людям нужно сделать невозможное. Вы должны прочитать мысли заказчика. А он – предсказать будущее. Когда вы смотрите на вещи с таких позиций, вам намного проще принимать изменения. Но если вы хотите противостоять изменению проекта и упорно придерживаться изначального плана, то выход тоже есть: просто убедитесь, что все члены вашей команды ясновидящие.
Так что же такое «приветствовать изменения»? Это значит:
• Никто не попадет в «беду», когда есть изменение. Мы и руководство компании признаем, что мы люди и можем ошибаться. Гораздо разумнее позволить нам допускать оплошности, а затем исправлять их, чем ждать, что мы сделаем все идеально с первого раза.
• Мы все в одной лодке. Каждый член команды, в том числе клиенты, с которыми мы сотрудничаем, имеет требования к проекту и меняет их. Если требования неправильные, то это наша общая с клиентом ошибка, поэтому нет смысла искать виноватого.
• Мы принимаем решение об изменениях быстро, не дожидаясь, когда будет слишком поздно. Ошибаться, конечно, плохо. Но мы все признаем ошибку, поэтому делаем все, что в наших силах, чтобы исправить ее как можно раньше. То есть стараемся максимально ограничить ущерб.
• Мы перестаем думать об изменениях как об ошибках. На основании имевшейся на тот момент информации мы делали все возможное, и только теперь стало ясно, что мы были неправы. Благодаря принятым решениям мы увидели перспективу и признали необходимость в изменениях, которые нужно сделать сегодня.
• Мы учимся на изменениях. Это наиболее эффективный способ командного роста и строительства лучшего ПО.