Гибкая разработка ПО может процветать даже в самой динамичной среде бизнеса и технологий. Действительно, согласно статье на веб-сайте Мартина Фаулера, лидера в области гибкой разработки, название “гибкая” было выбрано потому, что создатели этого направления рассматривали “адаптируемость и готовность к изменениям” в качестве важнейших требований своей методологии.

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

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

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

Управление изменениями на предприятии (enterprise change management, ECM) представляет собой механизм решения многих из этих проблем. В данной статье мы рассмотрим, как организации могут использовать приемы ECM применительно к гибкой разработке, чтобы добиться широкого освоения ПО среди сотрудников .

Информируйте о предстоящих переменах

В книге “Суть перемен” (The Heart of Change) Джон Коттер, Коносуке Мацусита (почетный профессор Гарвардской школы бизнеса) и Дан Коэн (консультант) сводят основную модель успешных изменений к формуле “увидел — прочувствовал — изменил” (see — feel — change). Для преодоления негативного отношения со стороны заинтересованных лиц программа ECM должна распространить такое видение перемен, которое будет достаточно привлекательным, чтобы не просто преодолеть отрицательные установки, но и стимулировать позитивное участие.

Некоторые ИТ-специалисты и менеджеры программ относятся к людям, которые будут затронуты инициативами в области ПО, так, словно это лишенные эмоций гуманоиды вроде жителей планеты Вулкан из сериала Star Trek. Разумеется, основная масса людей ближе к землянину Керку из того же сериала, чем к вулканцу Споку. Они не занимаются рациональной оценкой информации и не руководствуются исключительно логикой. Вместо того чтобы воздержаться от выводов по поводу грядущих перемен (таких, как новые инициативы в области ПО), люди склонны инстинктивно, руководствуясь интуицией, выносить суждения, которые зачастую имеют негативный характер и свидетельствуют о сопротивлении изменениям.

Авторы книги “Переключение: как добиться изменений, несмотря на трудности” (Switch: How To Change Things When Change is Hard) Чип и Дан Хит для обозначения трех главных вопросов, которые необходимо решить в процессе управления изменениями, используют метафору “погонщик, слон и дорога” (Rider, Elephant and Path).

Три главных вопроса

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

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

Дорога  означает среду, в которой происходят изменения. Речь идет о переменах в физической среде (таких, как организация офисного пространства) и о процессах или процедурах (например, Канбан — концепция производства “с колес”).

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

Интересно, что чем успешнее проект в области гибкой и быстрой разработки новых возможностей, тем больше проблем может возникать для ECM. Хотя гибкий подход с ориентацией на все более полное удовлетворение клиентских потребностей уменьшает масштабы изменений, связанных с каждым новым релизом ПО, он заставляет выпускать их намного чаще. Вместо того чтобы привыкнуть к единственному релизу с большим количеством изменений, созданным в процессе последовательной каскадной разработки (что является обычным при подготовке релизов раз в несколько лет), заинтересованным лицам приходится каждые один-два месяца иметь дело с новыми релизами, содержащими мелкие последовательные улучшения.

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

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

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

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

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

Интеграция ECM и гибкого подхода

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

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

Возьмем в качестве примера реализацию типичного плана управления изменениями. С учетом будущего релиза ПО, создаваемого в процессе гибкой разработки, задачи по управлению изменениями могут включать:

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

Формулирование задач ECM и задач разработки одними и теми же способами позволяет интегрировать управление изменениями в процесс гибкого программирования. Фактически такие задачи можно формулировать так же, как задания на разработку по результатам тестирования. Применительно к вышеприведенным задачам можно составить тест с тем, чтобы:

  • в список заинтересованных лиц был включен специалист из бизнес-группы;
  • исследование охватывало определенный контент;
  • в аналитической таблице присутствовала соответствующая колонка.

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

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

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