Принцип № 2. Изменение требований приветствуется даже на поздних стадиях разработки. agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества .

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

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

Такое трудно принять, особенно если вы делали работу именно для этого человека. Почти всеми инженерами-программистами движет чувство гордыни великого мастера: они хотят поставлять продукты, которые могут поддерживать и которые удовлетворяют потребности пользователей. Изменения в проекте угрожают этому, потому что ставят под сомнение тот путь, который они выбрали, и те допущения, которые они сделали.

Очень часто вам сообщают, что нужно изменить курс, после того как вы его выбрали.

Если этот человек уже объяснил, что именно нужно делать, и вы наполовину выполнили его требования, то вас очень огорчит его неожиданное заявление: «Я подумал вот о чем – а не можем ли мы создать что-то совсем другое?» Он не уважает ваш труд. Теперь вам придется внести изменения в уже сделанное. Трудно при этом не испытать возмущения! И хуже всего приходится тому, кто несет ответственность за результат и не соблюдает сроки.

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

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

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

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

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

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

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

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

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

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Принцип № 2. Изменение требований приветствуется даже на поздних стадиях разработки. agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества .:

  1. Основные источники инноваций для начинающих предпринимателей: Изменения в вашей компании. Неожиданные удачные изменения
  2. ЧАСТЬ 11 Собирая свидетельства об изменении культуры: как использовать отходы для создания карты бренда 41. Изучаем мусор – как истолковать выброшенные мечты
  3. Сырая нефть продолжение таблицы Рис. 24. Расчёт моментума, скорости изменения и сглаженной скорости изменения. Моментум (Mtm:7) равен сегодняшней цене закрытия минус цена закрытия 7 дней назад. Скорость изменения (RoC:7) – это сегодняшняя цена закрытия, делённая на цену закрытия 7 дней тому назад. Вместо цены закрытия вы можете использовать среднюю цену (половина суммы максимальной и минимальной). Это верно и в отношении большинства других индикаторов, приведённых в этой книге. Можно использоват
  4. Требования изменений
  5. Изменение исковых требований
  6. Процесс организационных изменений
  7. ДЖЕННИФЕР ГРИН, ЭНДРЮ СТЕЛЛМАН. ПОСТИГАЯ AGILE, 2015
  8. Ицхак Адизес. Управляя изменениями. Как эффективно управлять изменениями в обществе, бизнесе и личной жизни, 2014
  9. Обеспечение стратегических изменений финансовой деятельности предприятия
  10. Процесс институциональных изменений
  11. Изменение задания в процессе
  12. 18месячный рыночный цикл с подтверждающим индикатором темпа изменения. Синергия между темпами изменений и циклическими фигурами.
  13. Изменение - процесс накопления
  14. Процесс, описывающий изменение цены акции
  15. Анализ обеспеченности предприятия собственными оборотными средствами и оценка влияния факторов на величину их изменения
  16. Изменения в военнокадровой политике, системе комплектования и социально-экономическом обеспечении военнослужащих
  17. ПРИНЦИПЫ РОСТА И ИЗМЕНЕНИЙ