Почему команды противостоят изменениям и чем могут помочь практики

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

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

Рис. 6.2. Каждый руководитель проекта знаком с ощущением беспомощности из-за необходимости внесения изменений, которые разработчики не в состоянии выполнить. Каждому разработчику знакомо чувство тревоги, когда, казалось бы, небольшие изменения в коде разрастаются как снежный ком и требуют слишком много времени

И разве можно их за это винить? Команды сопротивляются этим изменениям, особенно в конце проекта[50], потому что им предстоит дополнительная работа. И не просто работа – а самый плохой ее вариант, самый раздражающий. Изменения заставляют вас возвращаться к тому, что вы считали законченным, разносят сделанное в пух и прах и вынуждают переписывать большие куски кода заново. И это не просто разочаровывающая работа: ваша команда вложила в нее много душевных сил, решила массу проблем и нашла наиболее элегантные решения. А теперь вам говорят, что нужно разрушить созданный командой Тадж-Махал, потому что на самом деле нужна была Эйфелева башня.

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

Теперь его просят ответить на вопросы, которые ему не совсем понятны: «Кто должен иметь доступ к этой функции?»; «Сколько людей будут использовать эту систему одновременно?»; «Каково допустимое время между нажатием кнопки “начать” и отображением результатов?»; «Какова правильная последовательность действий?»

То, что начиналось как встреча, на которой пользователь пытался объяснить свою проблему, каким-то образом превратилось в бесконечный поток обращенных к нему технических вопросов, на которые он не знает ответов. А время-то идет, и он чувствует: если не дать ответы на все вопросы, то команда отложит выполнение проекта и обвинит в этом его. (Будем честны: именно так она, скорее всего, и поступит.) Все знают, что создание ПО – дорогое удовольствие, а пользователь – не специалист в этом, поэтому дает самый лучший ответ, на который способен. И когда встреча заканчивается, он не мешает команде двигаться вперед и сжигать бюджет.

Как решить эту проблему? Кто прав?

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

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

Именно так поступают команды XP и называют такой стиль

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

Еще по теме Почему команды противостоят изменениям и чем могут помочь практики:

  1. Службы, которые могут помочь
  2. ЧЕМ МОГУ ПОМОЧЬ?
  3. Таким образом, только агрессивные инструменты могут помочь обогнать инфляцию и преумножить ваши сбережения.
  4. Совет 3. ВАЖНЕЕ ПОМОЧЬ, ЧЕМ ПОКАЗАТЬ ОБРАЗЕЦ
  5. Почему команда необходима?
  6. Почему ценовые проекции могут не выполняться?
  7. Небольшие изменения могут иметь большие последствия!
  8. Почему в теории маркетинг одно, а на практике – другое?
  9. 38. Ваши мысли могут оказаться гораздо ценнее, чем вы думаете
  10. Почему друзья и другие приличные люди могут подарить вам вирус?
  11. Имейте в виду, что мелкие изменения могут трансформировать всю систему конкуренции
  12. Изменения в практике государственного регулирования
  13. Таким образом, вложения в недвижимость могут помочь вам в диверсификации вашего инвестиционного портфеля как с точки зрения включения в него нового инструмента, так и с точки зрения ухода от валюты.
  14. Изменение привычек покупателей и новые возможности распределения могут остаться незамеченными.
  15. Глава 1О совах, лисах, овцах и ослах, или почему девятнадцать тысяч переговорщиков могут ошибаться
  16. Кого вы можете назвать Мастером в продажах услуг, в рос­сийской или зарубежной практике? Почему?
  17. II Разный подход к «да» и «нет», или почему идеи, которые отвергли в крупной компании, могут положить начало вашему бизнесу
  18. Кого вы можете назвать Мастером в продажах услуг, в рос­сийской или зарубежной практике? Почему?
  19. Кого вы можете назвать Мастером в продажах услуг, в рос­сийской или зарубежной практике? Почему?
  20. Кого вы можете назвать Мастером в продажах услуг, в рос­сийской или зарубежной практике? Почему?