Том ДеМарко. "Deadline. Роман об управлении проектами"
И все же хотелось бы представить, что где-то на земле есть место, где цель проекта - качество, а не сроки. Но, наверное, такого не бывает.
"Deadline. Роман об управлении проектами" - самая популярная книга американского программиста Тома ДеМарко, написанная в 1997 году и переведенная на русский язык в 2006. Несмотря на то, что с момента ее написания прошло 20 лет, она не устарела и содержит много важных мыслей. Многие из них просты и очевидны, но, как показывает практика, зачастую они оказываются недоступны пониманию высшего руководства. Книга считается одной из лучших книг по управлению проектами "для начинающих" в сфере ИТ, легко и в форме художественного произведения рассказывает о серьезных вещах. В каждой главе главный герой борется с какой-то проблемой, а в конце главы - записывает в блокнот свои мысли, которые смело можно брать на вооружение, использовать в работе и других сферах жизни (для удобства выписала все эти мысли в файл, прочитать можно тут: Роман об управлении проектами. Записная книжка). "Дедлайн" напомнил мне "Тестирование Дот Ком" Романа Савина, книгу, которую обязан был прочитать каждый начинающий тестировщик, написанную так же легко, доступно, с шутками и примерами.
Основная идея романа в том, что основа любого проекта - люди. Именно они способны совершать чудеса, если цель значительна и вера в свои силы велика. Именно они способны привести к краху любые начинания, если личные мотивы идут вразрез с целями проекта. Для проектного менеджера главное - не мешать людям выполнять ту работу, которая им нравится. Основная его задача - оберегать таких людей от внешних факторов, мешающих этой работе.
Сюжет книги простой и незамысловатый, но довольно-таки странный: в компании главного героя, Вебстера Томпкинса, талантливого менеджера проектов, происходит сокращение. Его увольняют, и на лекции для таких же уволенных сотрудников он встречает шпионку Лаксу из выдуманной коммунистической страны Моровии (находящейся где-то в районе Албании), которая к 2000 году (сейчас - 1997) хочет стать мировым лидером по производству ПО. Девушка давно следила за Томпкинсом, и после его фразы о том, что главное в работе менеджера - это
1. Найти нужных людей.
2. Дать им ту работу, для которой они больше всего подходят.
3. Не забывать о мотивации.
4. Сплотить команду и поддерживать ее в состоянии сплоченности.
(Все остальное - административная ерундистика.)
она понимает, что Вебстер как нельзя лучше подойдет на роль человека, который выполнит эту задачу. Лакса накачивает Томпкинса наркотиками и перевозит в Моровию. В Моровии находится полторы тысячи первоклассных ИТ-специалистов, прекрасно владеющих английским языком и работающих в одной крупной корпорации.
Цель ВВН (Великого Вождя Народа, молодого американского миллиардера-программиста, купившего Моровию) - за 2 года написать 6 продуктов-аналогов имеющегося на рынке ПО: Photoshop, Color Painter и еще 4 уже непопулярных в наше время продуктов. Задача Томпкинса - отобрать из 1500 человек подходящих для этого сотрудников и управлять ими. Подкупает главного героя то, что ВВН предлагает ему провести эксперимент: для каждого продукта набрать по 3 команды с разным количеством людей, с разной степенью контроля, использующих разные методологии и т. д. и оценить, как это повлияет на разработку. Лучшие продукты попадут на рынок. Проблема в том, что эксперимент так и не завершился - ВВН вместе с Лаксой уехали на год по делам, и Моровией в это время управлял министр внутренних дел мистер Бэллок: неприятный, грубый, некомпетентный человек, который постоянно сокращал сроки и ставил палки в колеса главному герою. Он потребовал перенести дедлайн на полгода назад, объединив группу из 3 команд в одну для каждого продукта. В огромных переполненных командах разработчики не могли работать, их менеджеры срывались, но Вебстер набрал еще по 2 команды из оставшихся сотрудников, передал им разработки прежних команд Б и В и, в итоге, новые команды Б и В, сформированные без уведомления других и использующие свои оригинальные методы, закончили разработку быстрее и качественнее переполненных команд А.
В каждой главе мистер Томпкинс встречает рояли в кустах: компетентных специалистов, помогающих ему и дающих советы. Герои утрированные, но живые - сразу же пытаешься подобрать им аналог из своего опыта. Разумеется, в жизни все происходит не так, но благодаря удачному стечению обстоятельств, герой делает полезные выводы. Книга, в основном, рассказывает об управлении очень большими командами и проектами, но и менеджер небольших команд сможет подчеркнуть многое. В романе рассказывается, как создаются продукты, как нанимают персонал, как решать конфликты, как работать с трудным руководством и вредными подчиненными, как правильно относиться к своим работникам и многое другое. Некоторые советы (мотивация, разрешение конфликтов, поведение в коллективе) пригодятся и в повседневной жизни.
Перед началом работы главный герой сразу же говорит, что все его сотрудники должны работать вместе, что невозможно создать продукт, когда между работниками нет дружеских отношений и возможности быстрого общения. Сейчас мы имеем возможность общаться с любым человеком на расстоянии, но отношения в коллективе тоже очень важны. Команда, участники которой готовы и дальше работать вместе, - это одна из основных целей любого проекта.
Мне понравилась описанная в книге техника проведения больших и нудных совещаний (на которых, скорее всего, был каждый из нас). Для каждого собрания должна быть опубликована повестка (и ее нужно строго придерживаться!), чтобы сотрудники знали, действительно ли обсуждаемая проблематика для них важна или интересна. В начале митинга руководитель должен выбрать по меньшей мере одного человека, чья работа настолько важна для проекта, что ему лучше покинуть совещание. Если на собрании обсуждаются вопросы проекта, уходящий сотрудник просит оставшихся решить определенные вопросы. Далее группа выражает согласие и человек уходит.
Из записной книжки мистера Томпкинса я вынесла и дополнила мысли, посвященные двум важным темам: производительность и конфликты, на которые я бы хотела обратить ваше внимание:
Повышение производительности:
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность работы (например, добавление в команду новых работников. Чем больше людей, тем сложнее им стать единой командой, тем больше времени у них уходит на взаимодействие и общение.) Повышение производительности - результат долгосрочных усилий.
2. Формальные программы (например, сертификации, повышение квалификации), направленные на улучшение существующего процесса разработки, будут дорого стоить команде - и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то, даже если это и произойдет, едва ли выгоды от этого повышения покроют затраты.
3. Можно надеяться получить положительный результат от какого-либо одного хорошо взвешенного и тщательно выбранного усовершенствования (но не более одного за раз) в методике работы. В этом случае оно может окупить себя.
4. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам. Чем раньше вы прекратите ненужную работу, тем лучше это отразится на проекте в целом. Не нужно добавлять в процесс новое, нужно убирать лишнее.
5. Есть только один способ сократить время на разработку, когда его и без того мало, - уменьшить сроки отладки программы. В детально спроектированных проектах на написание кода уходит примерно в 2 раза меньше времени, чем на проектирование.
6. Мотивация персонала не должна быть отрицательной. Угрозы и давление убивают инициативу, а не ускоряют работу. Какими угрозами не запугивать сотрудников, они не смогут выполнить задачу, если изначально были поставлены нереальные сроки.
7. Люди не станут быстрее соображать оттого, что руководство начнет давить на них. Чем больше сверхурочной работы, тем ниже производительность. Это происходит потому, что люди знают, что им все равно придется работать допоздна и больше времени тратят на перерывы, работают менее эффективно. Результатом сверхурочной работы становятся усталость, отсутствие творческой энергии, ошибки, нервное напряжение. Люди начнут выдыхаться, терять веру в проект.
8. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда дает отрицательный результат. Возможно, руководство просто не знает других способов повлиять на ситуацию.
Конфликты:
1. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании. Вследствие этого появляются злоба плюс скупость (сокращение сроков, финансирования…) - вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Неуважение и злоба, по мнению некоторых руководителей, должны заставить подчиненных лучше работать. Но это никогда не сподвигнет людей работать лучше. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность. Нужно уважать каждого, даже самого вредного из своих подчиненных.
3. В работе страх = гнев. Страх в нашем обществе почему-то нельзя демонстрировать. А вот злость можно. Но когда ты испытываешь сильную эмоциональную перегрузку, тебе просто необходимо выплеснуть свои чувства. Именно поэтому люди, испытывающие страх, чаще всего демонстрируют на людях злость и презрительное отношение к другим. Скорее всего, они просто чего-то боятся: вышестоящего начальства; подвести свою команду; того, что они не справятся с поставленной задачей.
4. Проект, в котором участвуют несколько сторон, не избежит конфликта интересов. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Любую сложную вещь можно описать простыми словами. Если это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
6. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника. Первым шагом в деле посредничества при решении конфликта должна быть маленькая церемония. Например, можно произнести фразу "Можно я попробую рассудить ваш спор?"
7. Не забывайте: все участники ситуации находятся по одну сторону баррикад. По другую сторону находится сама проблема.
Tl;dr. "Deadline. Роман об управлении проектами" будет интересен и тем, кто работает с людьми, и тем, кто работает в IT, а в особенности - менеджерам проектов. Каких-то глубоких изречений и серьезных исследований от книги ждать не стоит, но то, что лежит на поверхности, и то, что многие не замечают, - особенно важно. Конечно, можно прочитать и просто выводы (еще раз даю ссылку), но куда интереснее знать, как главный герой к этому пришел, да и с жизненными примерами все намного лучше запоминается (а еще у книги интересный финал - не спойлерю)). В реальной жизни события не складываются так удачно, как у мистера Томпкинса, поэтому у некоторых людей, не связанных с IT, может возникнуть неправильное представление о сфере. Но начинающим менеджерам книга даст понять, нравится ли им то, во что они ввязались много полезных советов. Также минусом "Романа" могу назвать то, что после него тяжело читать "правильную" профессиональную литературу, после легкого и интересного сюжета она кажется нудноватой. В целом, "Роман об управлении проектами" заслуженно получает от меня 9 ВВН из 10.
"Deadline. Роман об управлении проектами" - самая популярная книга американского программиста Тома ДеМарко, написанная в 1997 году и переведенная на русский язык в 2006. Несмотря на то, что с момента ее написания прошло 20 лет, она не устарела и содержит много важных мыслей. Многие из них просты и очевидны, но, как показывает практика, зачастую они оказываются недоступны пониманию высшего руководства. Книга считается одной из лучших книг по управлению проектами "для начинающих" в сфере ИТ, легко и в форме художественного произведения рассказывает о серьезных вещах. В каждой главе главный герой борется с какой-то проблемой, а в конце главы - записывает в блокнот свои мысли, которые смело можно брать на вооружение, использовать в работе и других сферах жизни (для удобства выписала все эти мысли в файл, прочитать можно тут: Роман об управлении проектами. Записная книжка). "Дедлайн" напомнил мне "Тестирование Дот Ком" Романа Савина, книгу, которую обязан был прочитать каждый начинающий тестировщик, написанную так же легко, доступно, с шутками и примерами.
Основная идея романа в том, что основа любого проекта - люди. Именно они способны совершать чудеса, если цель значительна и вера в свои силы велика. Именно они способны привести к краху любые начинания, если личные мотивы идут вразрез с целями проекта. Для проектного менеджера главное - не мешать людям выполнять ту работу, которая им нравится. Основная его задача - оберегать таких людей от внешних факторов, мешающих этой работе.
Сюжет книги простой и незамысловатый, но довольно-таки странный: в компании главного героя, Вебстера Томпкинса, талантливого менеджера проектов, происходит сокращение. Его увольняют, и на лекции для таких же уволенных сотрудников он встречает шпионку Лаксу из выдуманной коммунистической страны Моровии (находящейся где-то в районе Албании), которая к 2000 году (сейчас - 1997) хочет стать мировым лидером по производству ПО. Девушка давно следила за Томпкинсом, и после его фразы о том, что главное в работе менеджера - это
1. Найти нужных людей.
2. Дать им ту работу, для которой они больше всего подходят.
3. Не забывать о мотивации.
4. Сплотить команду и поддерживать ее в состоянии сплоченности.
(Все остальное - административная ерундистика.)
она понимает, что Вебстер как нельзя лучше подойдет на роль человека, который выполнит эту задачу. Лакса накачивает Томпкинса наркотиками и перевозит в Моровию. В Моровии находится полторы тысячи первоклассных ИТ-специалистов, прекрасно владеющих английским языком и работающих в одной крупной корпорации.
Цель ВВН (Великого Вождя Народа, молодого американского миллиардера-программиста, купившего Моровию) - за 2 года написать 6 продуктов-аналогов имеющегося на рынке ПО: Photoshop, Color Painter и еще 4 уже непопулярных в наше время продуктов. Задача Томпкинса - отобрать из 1500 человек подходящих для этого сотрудников и управлять ими. Подкупает главного героя то, что ВВН предлагает ему провести эксперимент: для каждого продукта набрать по 3 команды с разным количеством людей, с разной степенью контроля, использующих разные методологии и т. д. и оценить, как это повлияет на разработку. Лучшие продукты попадут на рынок. Проблема в том, что эксперимент так и не завершился - ВВН вместе с Лаксой уехали на год по делам, и Моровией в это время управлял министр внутренних дел мистер Бэллок: неприятный, грубый, некомпетентный человек, который постоянно сокращал сроки и ставил палки в колеса главному герою. Он потребовал перенести дедлайн на полгода назад, объединив группу из 3 команд в одну для каждого продукта. В огромных переполненных командах разработчики не могли работать, их менеджеры срывались, но Вебстер набрал еще по 2 команды из оставшихся сотрудников, передал им разработки прежних команд Б и В и, в итоге, новые команды Б и В, сформированные без уведомления других и использующие свои оригинальные методы, закончили разработку быстрее и качественнее переполненных команд А.
В каждой главе мистер Томпкинс встречает рояли в кустах: компетентных специалистов, помогающих ему и дающих советы. Герои утрированные, но живые - сразу же пытаешься подобрать им аналог из своего опыта. Разумеется, в жизни все происходит не так, но благодаря удачному стечению обстоятельств, герой делает полезные выводы. Книга, в основном, рассказывает об управлении очень большими командами и проектами, но и менеджер небольших команд сможет подчеркнуть многое. В романе рассказывается, как создаются продукты, как нанимают персонал, как решать конфликты, как работать с трудным руководством и вредными подчиненными, как правильно относиться к своим работникам и многое другое. Некоторые советы (мотивация, разрешение конфликтов, поведение в коллективе) пригодятся и в повседневной жизни.
Перед началом работы главный герой сразу же говорит, что все его сотрудники должны работать вместе, что невозможно создать продукт, когда между работниками нет дружеских отношений и возможности быстрого общения. Сейчас мы имеем возможность общаться с любым человеком на расстоянии, но отношения в коллективе тоже очень важны. Команда, участники которой готовы и дальше работать вместе, - это одна из основных целей любого проекта.
Мне понравилась описанная в книге техника проведения больших и нудных совещаний (на которых, скорее всего, был каждый из нас). Для каждого собрания должна быть опубликована повестка (и ее нужно строго придерживаться!), чтобы сотрудники знали, действительно ли обсуждаемая проблематика для них важна или интересна. В начале митинга руководитель должен выбрать по меньшей мере одного человека, чья работа настолько важна для проекта, что ему лучше покинуть совещание. Если на собрании обсуждаются вопросы проекта, уходящий сотрудник просит оставшихся решить определенные вопросы. Далее группа выражает согласие и человек уходит.
Из записной книжки мистера Томпкинса я вынесла и дополнила мысли, посвященные двум важным темам: производительность и конфликты, на которые я бы хотела обратить ваше внимание:
Повышение производительности:
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность работы (например, добавление в команду новых работников. Чем больше людей, тем сложнее им стать единой командой, тем больше времени у них уходит на взаимодействие и общение.) Повышение производительности - результат долгосрочных усилий.
2. Формальные программы (например, сертификации, повышение квалификации), направленные на улучшение существующего процесса разработки, будут дорого стоить команде - и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то, даже если это и произойдет, едва ли выгоды от этого повышения покроют затраты.
3. Можно надеяться получить положительный результат от какого-либо одного хорошо взвешенного и тщательно выбранного усовершенствования (но не более одного за раз) в методике работы. В этом случае оно может окупить себя.
4. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам. Чем раньше вы прекратите ненужную работу, тем лучше это отразится на проекте в целом. Не нужно добавлять в процесс новое, нужно убирать лишнее.
5. Есть только один способ сократить время на разработку, когда его и без того мало, - уменьшить сроки отладки программы. В детально спроектированных проектах на написание кода уходит примерно в 2 раза меньше времени, чем на проектирование.
6. Мотивация персонала не должна быть отрицательной. Угрозы и давление убивают инициативу, а не ускоряют работу. Какими угрозами не запугивать сотрудников, они не смогут выполнить задачу, если изначально были поставлены нереальные сроки.
7. Люди не станут быстрее соображать оттого, что руководство начнет давить на них. Чем больше сверхурочной работы, тем ниже производительность. Это происходит потому, что люди знают, что им все равно придется работать допоздна и больше времени тратят на перерывы, работают менее эффективно. Результатом сверхурочной работы становятся усталость, отсутствие творческой энергии, ошибки, нервное напряжение. Люди начнут выдыхаться, терять веру в проект.
8. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда дает отрицательный результат. Возможно, руководство просто не знает других способов повлиять на ситуацию.
Конфликты:
1. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании. Вследствие этого появляются злоба плюс скупость (сокращение сроков, финансирования…) - вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Неуважение и злоба, по мнению некоторых руководителей, должны заставить подчиненных лучше работать. Но это никогда не сподвигнет людей работать лучше. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность. Нужно уважать каждого, даже самого вредного из своих подчиненных.
3. В работе страх = гнев. Страх в нашем обществе почему-то нельзя демонстрировать. А вот злость можно. Но когда ты испытываешь сильную эмоциональную перегрузку, тебе просто необходимо выплеснуть свои чувства. Именно поэтому люди, испытывающие страх, чаще всего демонстрируют на людях злость и презрительное отношение к другим. Скорее всего, они просто чего-то боятся: вышестоящего начальства; подвести свою команду; того, что они не справятся с поставленной задачей.
4. Проект, в котором участвуют несколько сторон, не избежит конфликта интересов. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Любую сложную вещь можно описать простыми словами. Если это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
6. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника. Первым шагом в деле посредничества при решении конфликта должна быть маленькая церемония. Например, можно произнести фразу "Можно я попробую рассудить ваш спор?"
7. Не забывайте: все участники ситуации находятся по одну сторону баррикад. По другую сторону находится сама проблема.
Tl;dr. "Deadline. Роман об управлении проектами" будет интересен и тем, кто работает с людьми, и тем, кто работает в IT, а в особенности - менеджерам проектов. Каких-то глубоких изречений и серьезных исследований от книги ждать не стоит, но то, что лежит на поверхности, и то, что многие не замечают, - особенно важно. Конечно, можно прочитать и просто выводы (еще раз даю ссылку), но куда интереснее знать, как главный герой к этому пришел, да и с жизненными примерами все намного лучше запоминается (а еще у книги интересный финал - не спойлерю)). В реальной жизни события не складываются так удачно, как у мистера Томпкинса, поэтому у некоторых людей, не связанных с IT, может возникнуть неправильное представление о сфере. Но начинающим менеджерам книга даст понять, нравится ли им то, во что они ввязались много полезных советов. Также минусом "Романа" могу назвать то, что после него тяжело читать "правильную" профессиональную литературу, после легкого и интересного сюжета она кажется нудноватой. В целом, "Роман об управлении проектами" заслуженно получает от меня 9 ВВН из 10.