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

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

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

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

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

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

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

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

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

— Ага.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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