Использование методологии Adaptive Software Development
Страница 2. Жизненный цикл проекта, ориентированный на внесение изменений

Жизненный цикл проекта, ориентированный на внесение изменений

Главной предпосылкой типичного цикла управления проектом - Plan-Deliver-Review (Планирование - Поставка - Просмотр) - является относительно стабильное бизнес-окружение. В наши дни найти такое окружение практически невозможно, поэтому традиционные методологии не справляются с постоянным потоком изменений. Первый шаг в таком цикле, планирование, представляет собой наиболее трудный момент для большинства инженеров и менеджеров. Планирование возникло на основе редукционизма (науки сокращать любую вещь до ее составных частей) и почти религиозной веры в то, что тщательное планирование, за которым следует строгое осуществление намеченных планов, приводит к достижению желаемого результата ("мы контролируем ситуацию"). Именно поэтому многим из нас кажется такой странной идея, что сделать все правильно с первого же раза попросту невозможно.

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

Обдумывание дает гораздо больший простор мыслям и исследованиям, предоставляет возможность прояснить те вопросы реализации проекта, в которых вы пока сомневаетесь, и, наконец, позволяет без всякого страха и угрызений совести отклоняться от намеченных планов. Это вовсе не означает, что планирование устарело и больше не нужно. Просто необходимо сознавать, что в наши дни оно должно быть куда менее полным и категоричным, нежели раньше. Это также означает, что циклы поставки продукта должны быть короткими, и что в них необходимо использовать итеративный подход. Обдумывание не исключает планирования, но в отличие от него, признает правомочность любых необходимых изменений. Чаще всего отклонения от традиционно разработанных планов немедля попадают в разряд ошибок, подлежащих немедленному исправлению, в то время как многие из них являются прекрасной возможностью получить новый опыт и знания. При обдумывании вы отдаете себе отчет в том, что любая сложная проблема имеет неоднозначную природу. Более того, обдумывание подразумевает проведение исследований и экспериментов, направленных на ее выяснение. Обдумывание (которое так сложно воспринимать моим клиентам из банковских кругов) позволяет нам осознать тот факт, что мы не можем знать все. А раз мы признаем, что не знаем все, а следовательно, можем ошибиться, то гораздо легче воспринимаем третий шаг цикла ASD - Обучение.

Между этими двумя циклами есть второй, средний компонент. Имя ему - Взаимодействие. Сложные системы не создаются за один раз - они растут и развиваются. Для того чтобы работать над такой системой, нужно собрать большое количество разнообразной информации, проанализировать ее и понять, как ее можно применить к данной проблеме. Такая работа не под силу одному человеку. "Никто из нас поодиночке не сравнится со всеми нами вместе" - пишут Уоррен Беннис (Warren Bennis) и Патриция Бидерман (Patricia Biederman) в своей книге "Organizing Genius" ("Сплотить таланты").

Большинство разработчиков вполне прилично владеет навыками анализа, программирования, тестирования и т.д. (хотя, разумеется, любые знания всегда стоит пополнять и улучшать). Однако для современного бизнес-окружения характерно постоянное увеличение потока информации (с одной стороны) и необходимость владеть знаниями из самых разнообразных областей (с другой). Так, чтобы создать сайт для электронной торговли, нужно задействовать гораздо более богатый набор технологических решений, знаний в данной сфере бизнеса и других полезных навыков, чем для создания типичного программного продукта пять - десять лет назад. Сейчас весь поток информации не может охватить не только один человек, но даже небольшая команда, поэтому в наши дни, чтобы "знать все" нужно научиться широко взаимодействовать с другими людьми, организациями и командами. Навыки такого сотрудничества - от совместной работы над проектом до совместного принятия решений - уже стали жизненно необходимыми компонентами для успешной работы над любым проектом.

В книге Майкла Шраге (Michael Schrage) "No More Teams, Mastering the Dynamics of Creative Collaboration" ("Команд больше не будет или Постигаем динамику созидательного сотрудничества"), сотрудничество называют "актом совместного создания и/или открытия чего-либо". Проблема, говорит Шраге, вовсе не в команде, а в том, "какие отношения должны строить и поддерживать организации, если они хотят поставить своим заказчикам и клиентам действительно уникальный продукт". Совместная работа не признает тех границ, в которых существуют обычные команды разработчиков. Она охватывает и команду программистов, и заказчиков, и сторонних консультантов, и тех, кто будет торговать этим программным продуктом. Таким образом, сотрудничество и взаимодействие становятся третьим необходимым "китом" для построения более гибкой методологии управления проектом. Команды разработчиков должны взаимодействовать при решении технических проблем и при определении требований к системе. Им необходимо улучшать свою способность принимать совместные решения. Руководству, кстати, пора передать командам больше прав для принятия решений, так как постоянные изменения (и жесткий график работ) совершенно исключают традиционный стиль управления - Command - Control (Приказ - Контроль).

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

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

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