Старый, как выяснилось, советский анекдот:
Увольняется руководитель проекта. Этот РП передал сотруднику, который приходил на его место, три конверта, и сказал ему открывать по одному конверту каждый раз, когда ему понадобится совет.
После начального анализа проекта новый РП понял, что ему нужен совет, и открыл первый конверт. В нем была записка со словами «Вали все на своего предшественника». Новый РП так и сделал, и с помощью этого заработал немного времени на исправление проблем. Но время шло, и появились новые сложности. РП открыл второй конверт, в котором было одно слово: «Реорганизация». «Классная идея» — подумал РП, и затеял реорганизацию. Шумиха и активность, возникшая при этом, позволила скрыть проблемы. Но проект не стал от этого здоровее. Прошло еще немного времени, был освоен дополнительный бюджет, и пришло время открыть третий конверт. В нем была записка: «Пора делать три конверта».
Прочёл в последней командировке сабж. Рекомендацию увидел в сайдбаре «Что почитать» блога «Дедлайн как стиль жизни». Не мудрствуя лукаво, купил и… проглотил.
Увлекательный приключенческий роман
Книжные интернет-магазины не слишком напрягаются, публикуя стандартную аннотацию из книги. Заканчивается она словами: «Обо всём этом вы узнаете из данной книги, которая к тому же представляет собой не сухой научный труд, а… увлекательный приключенческий роман!»
Сразу хочется сделать оговорку. Вот о чём вы узнаете из книги, я сейчас аккуратно (чтобы не испортить впечатление от прочтения) затрону, а насчёт сюжета приключенческого романа — чур, я ничего не говорил. По сути, сюжет в это «художественное» произведение притянут за уши и призван лишь упростить восприятие информации. Что, надо сказать, удалось сделать на все 100%. По духу книга напоминает «Понедельник начинается в субботу» Стругацких. Читается очень легко, к тому же там такой хэппи энд… просто красота… жили, в общем, они долго и щасливо и умерли в один день.
Эта книга — своеобразный сборник рецептов, где воедино собраны ответы на вопросы из разряда «о чём вы всегда подозревали, но не решались озвучить».
Итак, приступим.
Распределённые команды
В последнее время, на волне «фриланса» и иже с ним получила популярность тема распределённых команд. На самом деле, этот вопрос из разряда спорных, спорить о которых можно до хрипоты. И в каждом конкретном случае, возможно, ответ на этот вопрос будет свой. ДеМарко же в книге вполне однозначно пишет (то есть его персонаж, руководитель проектов Томпкинс, говорит):
Вы никогда не выполните проект, если люди, которые над ним работают, разбросаны по разным городам и весям. Все вместе.Если честно, мне хочется верить, что существует «серебряная пуля», которая позволит собирать действительно распределённые команды, которые будут работать также эффективно, как и собранные в одном месте, и не будут тратить львиную долю времени на коммуникации. Но тут я даю тезисный конспектик книги, а в ней на этот счёт высказано мнение вполне конкретное.
Смелость
Ещё одна мысль из книги, которую мы все любим озвучивать в обществе, желая показаться решительным и целеустремлённым персонажем, но боимся прочувствовать её и принять к действию:
Неуверенность заставляет человека избегать риска. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
Дорога к мудрости проста,
Как этот краткий стих:
Ошибки смело совершай —
И станет меньше их.
Пит Хайн
No comment, как говорится. Просто очередное напоминание, а, возможно, пинок в зад… или удар по тыковке — на кого как действует.
Техника — ничто, люди — всё
Лейтмотив взглядов и действий мистера Томпкинса (думаю, что и ДеМарко) по отношению к управлению проектами можно выразить так: «Техника — ничто, люди — всё». Точка зрения опять же неоднозначная, требует ряда оговорок, например, о том, что люди в проекте — действительно всё, при условии, что PM владеет техникой. Не будем на этом заострять внимание. Не будем также скрывать, что все мы мечтаем когда-нибудь создать «машину по выполнению проектов», которая могла бы работать распределённо с константной производительностью, круглосуточно без выходных, праздников и вынужденных перерывов на цунами и наводнения. Собственно, поэтому в книге особое внимание уделяется взаимоотношениям в команде, способам поддержания боевого духа, а также методам управления. Например, вот что записал Вебстер Томпкинс в свой блокнот после разговора с Вождём Всех Народов (никогда не догадаетесь, кто это :-))):
Отрицательная мотивация. Угрозы — самый неподходящий вид мотивации… Более того, если люди не справятся, вам придётся выполнять свои обещания.
Просто цитаты, не требующие комментариев:
Мы ищем таких руководителей, которые настолько хорошо подходят для своей работы, что могут менять мир вокруг себя и добиваться гармонии между этим миром и тем, что они делают вместе со своей командой.
Главнокомандующий на поле битвы как метафора управления проектами. К началу сражения работа главнокомандующего уже закончена.
Некоторые мысли в книге звучат несколько цинично. И, бывает, до боли обидно осознавать, что когда-то такие методы опробовали на тебе. Не хочется соглашаться или принимать к вооружению, например, следующее высказывание:
Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.В этом вопросе мне гораздо ближе точка зрения Ричарда Брэнсона, о книге которого я ранее писал. Так вот, он говорил, что его политика — это создание автономных предприятий и направлений, в которых он делит долю между собой и руководителем направления в пропорции 50×50. При этом он доверяет управляющему и полностью на него полагается, предоставляя максимальную свободу. Нужно, наверное, давать возможность расти тем, кто этого хочет, при этом позволяя менять курс и род занятий — только так можно найти что-то по-настоящему интересное и неизведанное… Сорри, отвлёкся. В конце концов, в книге цель мистера Томпкинса была не в создании нового направления бизнеса или прорыва в науке, а в банальном, извините, единоразовом копипиздинге. Для этого, конечно, изложенный принцип вполне подходит.
Методы повышения производительности и качества труда
Интересно почитать про CMM:
…мне почему-то кажется что они (программы вроде CMM, — прим. мои) являются вещью в себе.Нельзя на уже работающем проекте повысить производительность труда — можно лишь заложить фундамент и сделать так, что следующие проекты будут выполняться более эффективно. Не существует моментального способа повышения производительности:
…в нашем деле не может быть никаких несложных мероприятий… Нельзя вот так взять и быстренько поднять производительность работы. Когда ты закончишь свои проекты, то увидишь, что производительность напрямую зависела от твоих предшественников. И всё, что ты сейчас можешь сделать, — это прикладывать усилия, плоды которых будут пожинать те, кто придёт после.Главное — не интерпретировать эти слова как бесполезность улучшения процесса производства, поскольку пожинать плоды можно будет только в неопределённой перспективе. Меня всегда интересовало, как работают PM вокруг. Часто приходится читать, что руководитель приходит, делает своё дело и уходит после сдачи проекта. Вроде как его работа выполнена. Цитата, которую я приводил в этом абзаце, наводит на мысль о преимуществах найма «постоянного» руководителя по сравнению с «приглашённым». Постоянный руководитель готов закладывать фундамент для общего прогресса, повышения производительности, улучшения методологий разработки и ведения проектов. В то время как приглашённый сделает своё дело, основываясь на тех методологиях, которые уже внедрены в компании и врядли будет тратить драгоценное время, отведённое на проект, для улучшения этого процесса. Его задача — однократный конечный результат. Хотя с эгоистической точки зрения, интересней «придти, увидеть, победить» и уйти покорять новые вершины, сбросив балласт сопровождения и рутинного развития («после меня хоть потоп»).
Размер команды
Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приёмов и навыков, […] скорее всего приведут к тому, что сроки только увеличатся.
Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).
Ещё о размере проектной команды:
… маленькие команды могут творить чудеса, в то время как большие за то же самое время едва ли успевали как следует сработаться и набрать темп.Выход для больших проектов — дробить его на маленькие максимально независимые подпроекты, выполнением которых занимаются небольшие команды.
Отдельно говорится о вреде привлечения больших команд к разработке архитектуры на начальной стадии проекта:
Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчикам надо скорее дать какую-то работу).Точно подмечено, не правда ли? Но как только этот порок сформулирован и записан, не поддаваться ему гораздо проще.
Риски
Риски — это то, в чём в повседневной работе не хочется себе сознаваться. Чувствуешь себя последней скотиной, варваром, расколотившим прекрасную статую (проект), когда необходимо объяснить заказчику, какие риски есть в проекте и (о ужас!) честно сказать, на сколько при материализации риска пострадают сроки сдачи проекта. Чего уж тут скрывать, обманываем зачастую и себя и заказчика, надеясь на «авось». А прятаться на самом неделе не стоит, т. к. риски — это опухоль, которая сожрёт проект изнутри, если не признать её существование. О важности управления рисками говорит и ДеМарко:
Разработка программного обеспечения — вообще очень рискованный бизнес, и подчас всё управление процессом сводится к управлению рисками.С рисками нужно обходиться честно, а именно:
- открыто признавать их существование и фиксировать в виде списка на самых ранних стадиях проекта, придать этот список огласке (как минимум сообщить о нём заказчику и указать на пункты в списке, которые зависят от него);
- правильно оценивать каждый риск, вероятность его появления и реальные последствия (будущие затраты) для проекта;
- как можно раньше придумать механизм своевременного обнаружения риска (!), прокручивать этот механизм в цикле на протяжении всего времени выполнения проекта.
Наука
ДеМарко пишет в книге о важности сбора метрических данных в процессе выполнения проекта. Вот этот вопрос мне до конца всё-таки не понятен, да и страшно подумать, сколько труда может потребоваться, чтобы разработать единицу измерения объема выполненной работы и посчитать размер проекта в этих единицах. Имеются в виду не банальные строчки кода, а действительно эффективные единицы, которые позволили бы выразить среднюю производительность труда, объем проекта и видеть проект как пересыпание крупы из мешка «предстоит сделать» в ёмкость «сделано». К сожалению, в нашем суматошном мире, когда, случается, проект продаётся ещё до создания, а сроки сдачи определяются в доверительной беседе «бизнесов» без предпроектного исследования и участия руководителя, вопросу метрик внимание не перепадает.
Сверхурочная работа
Поддерживаю полностью:
… А также потеря времени в течение обычного рабочего дня… Потому что люди знают, что всё равно будут работать допоздна. Поэтому они могут себе позволить долгие и не очень нужные совещания и тому подобное… А если запретить работать сверхурочно, то им (программистам, — прим. мои) волей-неволей придётся использовать рабочее время более эффективно.
Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.
О злобных придурках
Руководство к действию:
Если вам случится работать под руководством злобного придурка, надейтесь на чудо.
И жили они долго и счастливо, и умерли в один день… кажется, я уже об этом писал. Ну, тогда закругляюсь. Приятного чтения.
Update 2.04.2008: скачать эту книгу в электронном виде можно отсюда: rapidshare.com/files/5903222/Deadline.rar.html. Спасибо за информацию Олегу Шиловскому.
Update 7.04.2008: В конце каждой главы в книге приводится листик «из записной книжки мистера Томпкинса», где собраны основные мысли, затронутые в главе. Вот эти мысли законспектировал Евгений Охотников, спасибо ему за это. Перейдя по ссылке вы сможете ознакомиться с краткой выдержкой основных выводов, которые сделал мистер Томпкинс. Рекомендую: #.
Подписаться на новые статьи: 
RSS (Что это такое?) или Email
.JPG)
