Вальсируя с медведями

ОглавлениеДобавить в закладки К обложке

Такой реактивный подход не имеет ни одного из тех преимуществ, на которые претендует инкрементный метод.

Проактивный инкрементный метод

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

• ценность для заказчика

• подтверждение гипотез о возможных рисках

Это требует установления приоритетов компонентов системы.

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

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

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

ТДМ: Будучи новичком в игре в бридж и наблюдая за игрой своего однокашника, я с удивлением увидел, что он ходит с очень слабой карты, имея на руке много старших карт и козырей. Потом я спросил его об этом. Он ответил: «Том, всегда пораньше отдавай взятки. Конечно, я мог легко взять первые шесть или восемь взяток, а что дальше? Если я останусь без козырей, другая сторона, перехватив взятку, получает полный контроль над ситуацией. Я могу потерять и все свои оставшиеся хорошие карты, если они будут ходить с той масти, какую выберут».

В работе над проектом тоже разумно пораньше понести неизбежные потери. Иначе вы теряете контроль над ситуацией, позволяя событиям распоряжаться вами как угодно (что делает это особенно тяжким). Но, столкнувшись с трудностями раньше, вы сохраняете силы, чтобы вновь вернуть контроль над ситуацией. Те части системы, которые зависят от создания технических чудес, следует втолкнуть в ранние версии. Таким образом, если чудес не получилось, у вас остаются максимальные шансы для перехода на «аварийный режим». Если это происходит достаточно рано, вам, может быть, удастся справиться с трудностями собственными силами, в то время как подобное поражение на более позднем этапе проекта коснется всех.

Невозможность инкрементной поставки

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

Наш коллега Том Гилб смотрит на эту ситуацию с крайних позиций: «Как будто бы я как руководитель проекта не имел бы права знать срок сдачи проекта, пока этот срок не настанет. И у меня была бы единственная, полученная заранее инструкция: «быть готовым упаковать все, что окажется готовым на любое указанное утро, чтобы поставить это клиенту к концу того же дня». Конечно, это вынудит меня создавать множество версий (поэтому время между версиями будет достаточно мало) и убеждаться, что все самое лучшее будет уже включено в самые ранние версии».


-= 56 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня