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

Демарко Том

— Ага.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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