Deadline

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

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

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

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

— Ага.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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