Том ДеМарко - Deadline. Роман об управлении проектами
- Название:Deadline. Роман об управлении проектами
- Автор:
- Жанр:
- Издательство:Вершина
- Год:2006
- Город:М
- ISBN:5-9626-0132-7
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Том ДеМарко - Deadline. Роман об управлении проектами краткое содержание
Как выбрать из множества кандидатов нужного вам человека? Каково оптимальное число людей в команде на разных этапах проекта? Как можно оптимизировать работу, если перед вами поставлены жесткие сроки? Как определять и решать конфликты? Как уволить человека, не обидев его? Какими качествами должен обладать хороший руководитель? Обо всем этом вы узнаете из данной книги, которая к тому же представляет собой не сухой научный труд, а увлекательный приключенческий роман!
Книга адресована менеджерам по управлению проектами в области информационных технологий.
Deadline. Роман об управлении проектами - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Доктор попробовал.
— Ого! Вот это вино — вкус, аромат… Знаете, я, наверное, как-нибудь съезжу в Моровию. Интересно, что это за страна.
— Я думаю, чем-то похожа на нашу, — ответил мистер Томпкинс. — Красивые пейзажи, приятные люди и, конечно же, много отличного вина.
Дегустация проходила в саду того самого отеля, где жил мистер Томпкинс и где поселили высокого гостя. Когда вечер подошел к концу, им всего-то нужно было подняться по широкой парадной лестнице, чтобы оказаться у себя в номерах. На дорожку они выпили еще по стаканчику моградекского токая, нежного десертного вина почти оранжевого цвета, с оригинальным вкусом. И как это нередко случается с двумя джентльменами навеселе, их путь вверх по лестнице несколько затянулся, потому что где-то посередине между ними завязалась непринужденная беседа. Прошел час, а они все так же сидели на покрытых бордовым ковром ступенях и разговаривали.
— Знаете, Гектор, мы так долго обсуждали эксперименты по управлению проектами, цели, задачи и способы подсчета результатов, что я совсем забыл сказать: это не совсем эксперимент. В смысле, в конце этих экспериментов нам нужно представить готовые программные продукты очень высокого качества и в срок.
— Ну, конечно, это не чистый эксперимент. Но тем не менее это прекрасная возможность изучить факторы, влияющие на динамику развития проектов.
— Несомненно, но ведь есть еще и другой аспект — динамика моей работы, и она меня тоже очень интересует. Мы можем задаться целью изучить все возможные аспекты управления проектами и не поставить заказчику ни единого готового продукта, и я, как руководитель, окажусь несостоятельным. С другой стороны, мы могли бы сконцентрировать усилия на создании продуктов и ничем другим больше не заниматься.
— Понятно, вы хотите усидеть на двух стульях одновременно.
— Именно.
— М-да, если бы я был на вашем месте, я бы тоже добивался именно этого.
— Видите ли, мы готовы учиться на ошибках, но в большинстве случаев нам нужен успех.
Доктор Риццоли задумчиво кивнул.
— Для начала скажу, что, по моему мнению, сам факт экспериментирования и есть залог успеха. Как вы можете провалить проект, если его параллельно делают три отдельные команды, а вам остается лишь выбрать тот, который будет закончен быстрее и лучше остальных? Мало какая компания может позволить себе такую роскошь. Кроме того, дух соревнования, который неизбежно возникнет между тремя вашими командами, будет напоминать о конкурентной борьбе, неизбежной при выходе любого нового продукта. А это, в свою очередь, будет дисциплинировать разработчиков.
— Да, конечно. Но сейчас рядом со мной находится не кто иной, как всемирно известный доктор Риццоли, признанный авторитет в деле программных разработок, человек, опубликовавший сотни статей, научных исследований, книг, учебников…
— Э-ээ, меня еще иногда называют «человек, у которого нет неопубликованных мыслей».
— Хотел бы я увидеть того негодяя, который осмелился так о вас отзываться!
— Думаю, на самом деле это комплимент.
— Если так, то ладно. В любом случае, мне посчастливилось беседовать с доктором Риццоли. Было бы просто странно, если бы я не попросил у вас совета. Скажите, Гектор, что мне сделать, чтобы у проектов было как можно больше шансов на успех? Что бы вы сделали, окажись вы на моем месте? Что здесь самое главное?
Гектор Риццоли задумчиво посмотрел вверх, куда уходила покрытая пурпурным ковром лестница.
— Самое главное… Да, это непростой вопрос.
— Может, мне стоит сосредоточиться на улучшении самого процесса разработки? Ты же знаешь, эти ребята из Института программирования могут убедить кого угодно, что если им удастся подняться с СММ второго уровня до СММ третьего, то проект будет успешным. Стал бы ты этим заниматься?
— А вот на этот вопрос ответить совсем несложно. Нет, не стал бы.
— Ага.
— Теоретически, улучшать процесс всегда хорошо и полезно для проекта. Это означает, что вы учитесь делать свою работу все лучше и лучше. Но я совсем не уверен в полезности таких программ, как СММ. Мне почему-то кажется, что они являются вещью в себе.
— Но ведь должен же быть какой-то шаг… какое-то несложное мероприятие, которое повысило бы производительность моих программистов. Ну, к примеру…
— Нет-нет, в нашем деле не может быть никаких несложных мероприятий, — энергично затряс головой Гектор. — Нельзя вот так взять и быстренько поднять производительность работы. Когда ты закончишь свои проекты, то увидишь, что производительность напрямую зависела от твоих предшественников. И все, что ты сейчас можешь сделать, — это прикладывать усилия, плоды которых будут пожинать те, кто придет после.
— Да, я и сам это понимаю… Но тем не менее я хотел услышать это от вас, — вздохнул мистер Томпкинс.
— Сухой реалистичный взгляд на быстрое повышение производительности.
— Спасибо, мне это было нужно.
Официант поднялся к ним с двумя стаканами оранжевого токая. Гектор и Вебстер взяли вино и продолжали задумчиво потягивать его, сидя на ступеньках.
— Так что бы вы сделали на моем месте, а, Гектор?
— Ну, поскольку производительность все равно быстро не изменишь, я бы всецело сосредоточился на том, чтобы не тратить время зря. Достаточно предположить некий фиксированный уровень производительности труда за час эффективной работы, и тогда вам останется только уменьшать количество неэффективных часов.
— Кажется, я понимаю. Нужно искать источник неэффективности и искоренять его.
— Да, это всегда полезно. Однако не ждите от этой процедуры каких-то грандиозных результатов, потому что люди всегда сами стараются избавиться от того, что мешает им работать. То есть эти усилия, конечно же, пойдут на пользу, но решающим фактором они не станут.
— Тогда где же я должен искать причины неэффективности работы?
— Представьте, что происходит, когда в проекте что-то идет не так. Риск, который до этого был всего лишь возможностью, вдруг материализуется и превращается в проблему.
Мистер Томпкинс кивнул:
— Например, не привезли что-то из оборудования, без которого невозможно продолжать работу? Что-то в этом роде?
— Именно. Или же разработка основного компонента заканчивается с большим опозданием. Просто потому, что на нее отвели слишком мало времени. Что вы в этом случае будете делать?
— Ну, наверное, я подумаю о том, чтобы упростить продукт. Пусть он будет выполнять меньше функций. Это облегчит ситуацию и оставит нам время, чтобы проект был сдан в срок.
— Допустим. Допустим, вы упростили его. Но ведь это тоже трата времени и сил: может быть, менять функциональность продукта уже слишком поздно. В конце концов, наверняка ваши люди уже потратили какое-то время на программирование этой функциональности.
Читать дальшеИнтервал:
Закладка: