Deadline. Роман об управлении проектами - ДеМарко Том - Страница 16

• Предыдущая
• 16/61
• Следующая

— Э-ээ, меня еще иногда называют «человек, у которого нет неопубликованных мыслей».

— Хотел бы я увидеть того негодяя, который осмелился так о вас отзываться!

— Думаю, на самом деле это комплимент.

— Если так, то ладно. В любом случае, мне посчастливилось беседовать с доктором Риццоли. Было бы просто странно, если бы я не попросил у вас совета. Скажите, Гектор, что мне сделать, чтобы у проектов было как можно больше шансов на успех? Что бы вы сделали, окажись вы на моем месте? Что здесь самое главное?

Гектор Риццоли задумчиво посмотрел вверх, куда уходила покрытая пурпурным ковром лестница.

— Самое главное… Да, это непростой вопрос.

— Может, мне стоит сосредоточиться на улучшении самого процесса разработки? Ты же знаешь, эти ребята из Института программирования могут убедить кого угодно, что если им удастся подняться с СММ второго уровня до СММ третьего, то проект будет успешным. Стал бы ты этим заниматься?

— А вот на этот вопрос ответить совсем несложно. Нет, не стал бы.

— Ага.

— Теоретически, улучшать процесс всегда хорошо и полезно для проекта. Это означает, что вы учитесь делать свою работу все лучше и лучше. Но я совсем не уверен в полезности таких программ, как СММ. Мне почему-то кажется, что они являются вещью в себе.

— Но ведь должен же быть какой-то шаг… какое-то несложное мероприятие, которое повысило бы производительность моих программистов. Ну, к примеру…

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

— Да, я и сам это понимаю… Но тем не менее я хотел услышать это от вас, — вздохнул мистер Томпкинс.

— Сухой реалистичный взгляд на быстрое повышение производительности.

— Спасибо, мне это было нужно.

Официант поднялся к ним с двумя стаканами оранжевого токая. Гектор и Вебстер взяли вино и продолжали задумчиво потягивать его, сидя на ступеньках.

— Так что бы вы сделали на моем месте, а, Гектор?

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

— Кажется, я понимаю. Нужно искать источник неэффективности и искоренять его.

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

— Тогда где же я должен искать причины неэффективности работы?

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

Мистер Томпкинс кивнул:

— Например, не привезли что-то из оборудования, без которого невозможно продолжать работу? Что-то в этом роде?

— Именно. Или же разработка основного компонента заканчивается с большим опозданием. Просто потому, что на нее отвели слишком мало времени. Что вы в этом случае будете делать?

— Ну, наверное, я подумаю о том, чтобы упростить продукт. Пусть он будет выполнять меньше функций. Это облегчит ситуацию и оставит нам время, чтобы проект был сдан в срок.

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

— Да, пожалуй…

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

— У большинства моих проектов риски по большей части одни и те же: отставание от графика и чрезмерная стоимость.

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

Какое-то время мистер Томпкинс переваривал услышанное.

— Управлять проектом, так, как будто упражняешься в предотвращении рисков… А что? Мне эта идея нравится. По крайней мере, теоретически. А вот насчет практического применения… я до сих пор не могу понять, как руководствоваться вашими советами на практике. Как мне узнать, получается ли у меня предотвращать причинные риски?

— А вы посмотрите на это с другой стороны. Как можно доказать, что вы не справились с рисками? Представьте, что вас потащили в суд и собираются предъявить обвинение в плохом управлении рисками. Что вам вменят в вину?

— Ну, я думаю, меня обвинят в том, что я не составил список рисков. Это будет первым пунктом обвинения.

— Или же что вы неправильно оценили каждый риск, возможность его появления и затраты для проекта.

— Да. Или что я не придумал механизм для своевременного обнаружения материализовавшегося риска.

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

— Может быть, даже назначить специального человека. Какого-нибудь менеджера по управлению рисками.

— Да. В противном случае, если судья узнает, что вы не позаботились изобрести для своих сотрудников способы доносить до начальника дурные новости, вам придется ой как туго. А если он узнает, что никто не сообщает вам плохие новости, потому что вы культивируете у себя в компании культуру страха перед начальником, который не желает слышать ничего плохого о ходе работ… Тогда вам не миновать срока, Вебстер!

— Я никогда так не поступлю, — убежденно сказал мистер Томпкинс.

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

— Да, это не совсем то, что обычно понимают под «культурой страха перед начальством», но…

— Но эффект абсолютно тот же, — закончил за мистера Томпкинса доктор Риццоли.

— Да, понимаю.

— Итак, на вашем месте я бы занялся управлением рисками, с которыми могут столкнуться ваши проекты.

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

• Предыдущая
• 16/61
• Следующая