Цитаты из книги Вальсируя с Медведями

Существенной частью управления проектами является нахождение ответов на ключевые вопросы, такие как: «Когда вы закончите? Какое среднее время безотказной работы покажет ваш продукт? Примет ли пользователь продукт и будет ли его использовать?» Все они относятся к «денежным» вопросам, поскольку имеют дело непосредственно с соотношением «затраты/стоимость» продукта, который вам предстоит создать. На все эти вопросы есть общий честный ответ: «я не знаю». Конечно, вы не знаете. Тот, кто задает вам эти вопросы, знает, что вы не знаете. Вопросы о будущих результатах и сама концепция знания – несовместимы друг с другом. Можно предварять любой свой ответ словами: «Я не знаю, но…» Но даже если вы не начинаете с этого уточнения, оно неявно подразумевается. Мы хотим здесь показать, что вам нужно узнавать эти «я-не-знаю» вопросы, потому что они всегда являются показателями риска. У того, чего вы не знаете, есть оборотная сторона, которая может повернуться против вас, в этом и состоит ваш риск. Если бы вы смогли собрать все уникальные «я-не-знаю» вопросы о своем проекте и докопаться до глубинной причины неизвестного в каждом из них, то перед вами оказался бы полный список рисков вашего проекта.

Наше название взято из песенки, включенной в песенник д-ра Сьюса «Кот в шляпе»[1]. В этой песенке поется о дядюшке Тервиллилжере, который по субботам Крадется вниз по лестнице (не встретиться б с соседями!), чтобы родной покинув дом, вальсировать с медведями Дядюшка Т. – это человек, с готовностью идущий на риск. Нам остается только надеяться, что он умеет на деле оценивать риск, принимать меры предосторожности и тем снижать его. Если это так, то он – отличный образец для менеджеров рискованных проектов по разработке программного обеспечения, ведь иной раз им приходится танцевать сразу с несколькими собственными медведями.

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

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

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

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

Существенной частью управления проектами является нахождение ответов на ключевые вопросы, такие как: «Когда вы закончите? Какое среднее время безотказной работы покажет ваш продукт? Примет ли пользователь продукт и будет ли его использовать?» Все они относятся к «денежным» вопросам, поскольку имеют дело непосредственно с соотношением «затраты/стоимость» продукта, который вам предстоит создать. На все эти вопросы есть общий честный ответ: «я не знаю». Конечно, вы не знаете. Тот, кто задает вам эти вопросы, знает, что вы не знаете. Вопросы о будущих результатах и сама концепция знания – несовместимы друг с другом. ... Тактика, присущая управлению риском, состоит в том, чтобы слушать каждое свое произнесение слов «я не знаю» (вслух или мысленно) и всякий раз принуждать себя задавать вспомогательный вопрос: Что я знаю (или что я мог бы знать) о том, чего я не знаю?

Всегда доступна какая-то информация о неизвестном. И всегда лучше иметь эту информацию, чем обходиться без нее.

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

Мильтон

Кольрилж

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

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

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

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

Советуем вам составлять план версий, выбирая для более ранних версий компоненты, у которых показатели отношения "выгоды/затраты" выше. При поставке версии n все или большинство участников могут обнаружить, что среднее значение отношения "выгоды/затраты" ещё не готовых частей незначительно. Это вполне может вызвать массовый энтузиазм по поводу соглашения о завершении проекта, признав его исключительно успешным, что позволит перейти к другим делам. И это всё без необходимости занимать непопулярную позицию по поводу того, что любимая функция такого-то была чистой подачкой его самолюбию и ни черта не давала для общей выгоды.

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