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

Первоисточник: Том ДеМарко “Deadline. Роман об управлении проектами”

Постарался выжать всю “соль” из не самой плохой, на мой взгляд, книги об управлении проектами. Выкладываю на суд общественности.

1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы.
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Угрозы - самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
6. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
7. Более того, если люди не справятся, вам придется выполнить свои обещания.
8. Для руководства нужны сердце, нутро, душа и нюх.
9. Больше слушайте, меньше говорите.
10. Чтобы управлять проектом, достаточно управлять его рисками.
11. Создайте список рисков для каждого проекта.
12. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
13. Оцените вероятность возникновения и стоимость каждого риска.
14. Для каждого риска определите показатель - симптом, по которому можно определить, что риск превращается в проблему.
15. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.
16. Сокращайте потери.
17. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к
новым победам.
18. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
19. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
20. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
21. Считайте, что команда, которая хочет продолжать работать вместе и дальше, - это одна из основных целей любого проекта.
22. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
23. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.
24. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
25. Обсуждайте эти модели.
26. Определяйте размер каждого проекта.
27. Не усердствуйте поначалу с выбором единицы измерения - если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
28. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
29. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
30. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
31. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
32. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
33. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
34. Хороший процесс разработки и его постоянное улучшение - весьма достойные цели.
35. Но существуют еще рабочие цели и задачи.
36. Попытка внедрить более одного усовершенствования методологии - гиблое дело. Программы, направленные на улучшение многих приемов и навыков, скорее всего приведут к тому, что сроки только увеличатся.
37. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
38. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).
39. Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.
40. Люди не начнут быстрее соображать, если руководство будет давить на них.
41. Чем больше сверхурочной работы, тем ниже производительность.
42. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
43. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
44. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему - сохранить хорошую мину при плохой игре.
45. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
46. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
47. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
48. Процесс создания и распространения программных систем - прямо-таки рассадник всевозможных конфликтов.
49. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
50. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
51. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
52. Тяжело договариваться. Гораздо легче выступать посредником.
53. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
54. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
55. Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
56. Нам кажется, что самое страшное - не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
57. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
58. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ - заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
59. Защищайте людей от оскорблений и ругани Начальства.
60. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
61. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
62. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.
63. Злоба и скупость - вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
64. Злоба и скупость прямо противоположны истинным целям любой хорошей компании - быть щедрыми и заботливыми по отношении к своим сотрудникам.

Написанная еще в 1997 году книга Тома ДеМарко «Deadline. Роман об управлении проектами» не только не утратила актуальности, но и по сей день остается жемчужиной управленческой мудрости. Надо понимать, что никакие новые методологии, стандарты, Lean и Agile не заменяют собой простых, хотя и вовсе не очевидных принципов управления, изложенных с потрясающей легкостью.
Давно собирался собрать воедино «записную книжку мистера Томпинкса», в которую герой романа заносит ключевые выводы и тезисы, чтобы можно было освежать их в памяти. Ну и вот наконец. Enjoy!

Четыре основных правила менеджмента

1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.

(Все остальное - административная ерундистика.)

Безопасность и перемены

1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Отрицательная мотивация

1. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
2. Угрозы - самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
3. Более того, если люди не справятся, вам придется выполнить свои обещания.

Части тела, необходимые для управления проектами

1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:
   • руководить надо сердцем;
   • чувствовать нутром;
   • вкладывать в команду и проект душу;
   • иметь нюх на всякую ерунду и бессмыслицу.

Главнокомандующий на поле битвы, как метафора управления проектами.

К началу сражения работа главнокомандующего уже закончена.

Собеседование и прием на работу

1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
2. Не пытайтесь нанимать людей в одиночку - гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
4. Попросите наводку - тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
5. Больше слушайте, меньше говорите.

Повышение производительности

Управление рисками

1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель - симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите

1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, - это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

1. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
2. Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
3. Предсказывайте результаты работы с помощью модели.
4. Сравнивайте результаты, полученные а процессе моделирования, с реальными.

Извращенная политика

1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных

1. Определяйте размер каждого проекта.
2. Не усердствуйте поначалу с выбором единицы измерения - если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

1. Хороший процесс разработки и его постоянное улучшение - весьма достойные цели.
2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде - и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
4. Можно надеяться получить положительный результат от одного какого‑нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
5. Попытка внедрить более одного усовершенствования методологии - гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по‑другому

1. Есть только один способ сократить время на разработку, когда его и без того мало - уменьшить сроки отладки программы.
2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.

Нельзя заставить людей делать что‑то по‑другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху

1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.
3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему - сохранить хорошую мину при плохой игре.

Сердитый начальник

1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда‑нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации

1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

(Важное пояснение. Упомянутые «спецификации» — это нечто среднее между техническим заданием и эскизным проектом. Лично моя практика показывает, что для ТЗ это тезисы полностью справедливы!)

Конфликт

1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
2. Процесс создания и распространения программных систем - прямо‑таки рассадник всевозможных конфликтов.
3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.
7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Кто такой катализатор проекта

1. Существуют люди‑катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
2. Посредничество - еще одна сфера, в которой люди‑катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Человеку свойственно ошибаться

Нам кажется, что самое страшное - не знать чего‑то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

О персонале

1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы - определения архитектуры системы (потому что всем разработчиком надо скорее дать какую‑то работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии

1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ - заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какая‑то церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего‑то очень боятся.
6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)

1. Эту патологию невозможно вылечить снизу.
2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

Злоба и скупость

1. Злоба и скупость - вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании - быть щедрыми и заботливыми по отношении к своим сотрудникам.
3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина - страх и боязнь провала.

Основы здравого смысла

1. У проекта должно быть два срока сдачи - запланированный и желаемый.
2. Эти сроки должны быть разными.

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

И, наконец, если вдруг так получилось, что эта книга до сих пор не попала в зону Вашего внимания — то срочно читать. Читать не спеша, со вкусом.

В последнее время в бизнес-среде все большее внимание уделяется работе над проектами. Если раньше подход был более простым, когда ставилась задача, обозначались исполнители и сроки исполнения, то теперь этот процесс существенно усложнился. Это дает возможность выполнять работу более эффективно за счет контроля над каждым этапом и тщательного планирования. В деле управления проектами существует масса нюансов, о которых стоит знать любому менеджеру и руководителю. Книга Тома ДеМарко «Deadline. Роман об управлении проектами» в ненавязчивой художественной форме раскрывает суть этого непростого процесса.

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

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

На нашем сайте вы можете скачать книгу "Deadline. Роман об управлении проектами" ДеМарко Том бесплатно и без регистрации в формате fb2, rtf, epub, pdf, txt, читать книгу онлайн или купить книгу в интернет-магазине.

Не всегда бизнес литература оставляет такое приятное послевкусие, как книга Тома ДеМарко "Deadline. Роман об управлении проектами". В ней автор в очень интересной манере рассказывает об управлении IT-проектами - основные принципы менеджмента излагаются в художественной форме от имени главного героя, толкового руководителя мистера Томпкинса. Таким образом книга читается довольно легко, а ситуации, в которые попадают герои книги и то, как они из них выходили, успешно можно применять на практике.

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

"И все же хотелось бы представить, что где-то на земле есть место, где цель проекта - качество, а не сроки.
Но, наверное, такого не бывает." Мистер Томпкинс

1. Людям нужно давать ту работу, для которой они подходят лучше всего

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

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

2. Для успешной работы людям необходимы перемены

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

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

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

3. Угрозы подчиненным не повышают их производительность

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

Но если на выполнение задачи заранее отведено нереально малое количество времени, то как бы вы не угрожали своим подчиненным, они в этот срок не вложатся. Также, автор делает интересное замечание, что если работа действительно не была сделана в отведенный нереальный срок, то вам придется выполнять то, что вы им "наугрожали".

4. Для успеха проекта в команде должны быть хорошие отношения

Удивительно было узнать мнение автора о том, что менеджер никак не может непосредственно повлиять на формирование хороших отношений внутри своей команды. Менеджер может создать нужную обстановку для зарождения здоровых отношений в команде, заложить фундамент и не препятствовать развитию этих отношений. Автор считает, что для успеха проекта одни из ключевых факторов - это слаженная команда и эффективные коммуникации со всеми остальными сотрудниками. В прочем мы, в E-PAGES, уделяем как раз этим пунктам особое внимание!

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

Основная задача менеджера - создать фундамент для построения крепкой слаженной команды с теплыми и дружественными отношениями внутри.

5. Повышение производительности команды требует больших усилий

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

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

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

6. Нужно сокращать потери

"Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно."

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

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

7. Увеличение количества людей в команде не означает, что работа будет закончена раньше срока

Автор считает, что в ситуации, когда работу по разработке ПО нужно закончить раньше срока, увеличение размера команды не принесет пользы, а даже нанесет вред. Большим коллективом на много труднее управлять, на много труднее создать позитивную рабочую атмосферу, обеспечить всем необходимым для работы, оперативно решать возникшие проблемы. Большая команда разработчиков требует излишне много координации.

Один из создателей методологии Scrum, Джефф Сазерленд, не рекомендует создавать команды из более чем семи человек. Ведь количество каналов коммуникации у команды уже из 10-ти человек равна 45! Это огромная нагрузка на менеджера, с которой качественно справиться одному человеку очень сложно.

8. Нужно собирать статистику о результатах своей работы

Очень полезно собирать данные о своей работе. Сколько времени потрачено на выполнение проекта, на какой вид работы сколько времени было потрачено (например, сколько на верстку, программирование, тестирование), сколько потрачено на коммуникации с заказчиком. Собирайте те данные, которые в будущем помогут определить как хорошо был сделан проект и что можно улучшить в следующих.

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

9. Давление на своих подчиненных увеличивает их производительность всего на 6%

"Почему давление на программистов увеличивает производительность работы всего на шесть процентов?
На людей можно надавить, но они не станут от этого быстрее соображать."

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

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

10. Большие команды на старте проекта - вредны

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

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

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

(Пока оценок нет)

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

О книге «Deadline. Роман об управлении проектами» Том Демарко

Одним из веяний в менеджменте последних десятилетий, стала повсеместная работа по управлению проектами. И если раньше любой проект рассматривался просто, как задача, для выполнения которой задействовано определенное количество людей, и которая должна быть качественно выполнена, то теперь требования стали намного жестче. Сейчас в выполнении проекта средней и максимальной сложности задействованы не только непосредственный руководитель и исполнители, но и всевозможные проект-менеджеры, рассчитывающие время работы над задачей и ответственные за отчетность на промежуточных этапах. Введен даже специальный термин – Deadline, в буквальном переводе с английского означающий «мертвая линия», то есть предельный срок для выполнения поставленной задачи, по истечении которого, данная работа потеряет свою ценность, а компания — клиентов, прибыль и, возможно, репутацию.

Слово Deadline стало настолько пугающим, а специалистов к нему относящихся настолько много, что без специализированного, научного подхода выполнять данную работу стало весьма сложно. Том Демарко великолепный автор и непревзойденный специалист в данном вопросе, сумел создать книгу, которая в легкой, художественной форме даст ответы на многие каверзные вопросы. «Deadline. Роман об управлении проектами» — книга уникальная в своем роде, как по способу подачи, так и по количеству и качеству информации.

Книга Демарко «Deadline» по сути, учебник для новичков по менеджменту проектов, своеобразная энциклопедия, написанная в форме художественного произведении, имеющая свой сюжет, но не упускающая главную познавательную составляющую. По ходу развития сюжета, читатель узнает не только об увлекательных приключениях героя-менеджера, но и о его невероятной работе. Произведение разбито на главы, в конце которых, автор акцентирует внимание читателя на только что изложенных основных понятиях и важнейших идеях. Это очень удобно и помогает в легкой, ненавязчивой форме усвоить массу полезной и во многом уникальной информации. Книга расскажет не только о непосредственной работе по управлению проектами, но и о работе по управлению людьми, о сохранении комфортных отношений в коллективе, об опасностях связанных с нерациональным использованием рабочего времени и о многом, многом другом. В этой книге даже опытные менеджеры найдут свежие идеи и полезные мысли для оптимизации своей работы.

Читайте уникальную книгу Тома Демарко «Deadline. Роман об управлении проектами», берите на заметку полезные идеи и наслаждайтесь незаурядным художественным сюжетом. Приятного чтения.

На нашем сайте о книгах сайт вы можете скачать бесплатно без регистрации или читать онлайн книгу Том Демарко «Deadline. Роман об управлении проектами» в форматах epub, fb2, txt, rtf, pdf для iPad, iPhone, Android и Kindle. Книга подарит вам массу приятных моментов и истинное удовольствие от чтения. Купить полную версию вы можете у нашего партнера. Также, у нас вы найдете последние новости из литературного мира, узнаете биографию любимых авторов. Для начинающих писателей имеется отдельный раздел с полезными советами и рекомендациями, интересными статьями, благодаря которым вы сами сможете попробовать свои силы в литературном мастерстве.

Цитаты из книги «Deadline. Роман об управлении проектами» Том Демарко

Настоящий руководитель чувствует ситуацию нутром, управляет людьми исключительно сердцем и может вдохнуть живую душу в проект, команду или всю организацию.

Отрицательная мотивация
1. Угрозы – самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
3. Если люди не справятся с поставленной задачей, вам придется привести в действие свои угрозы.

На людей можно надавить, но они не станут от этого быстрее соображать.

Проблемы социологии
1. Собрания не должны быть многолюдными. Необходимо обеспечить присутствие на собрании лишь тех людей, для которых обсуждаемая проблематика действительно важна или интересна. Самый простой способ – заранее опубликовать повестку дня и всегда строго ее придерживаться.
2. Каждому проекту нужна какая-то церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
4. Защищайте людей от давления и ругани Больших Боссов.
5. Запомните: в работе страх = гнев. Руководители, которые постоянно кричат на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
6. Наблюдение: если бы проявление грубости и злости к подчиненным всегда говорило окружающим о том, что начальник просто боится, то никто из руководителей не стал бы так себя вести просто из опасения, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

Мы ищем менеджеров, которые настолько искусны в своей работе, что могут менять мир вокруг себя и добиваться гармонии между этим миром и тем, что они делают вместе со своей командой.

Концентрация, – ответила Белинда. – Просто не думай ни о чем, и все получится само собой.

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

Злоба и скупость
1. Злоба плюс скупость – вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Злоба и скупость прямо противоположны истинным ценностям любой хорошей компании – быть щедрыми и заботливыми по отношению к своим сотрудникам.
3. Если вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина – страх провала.

Так вот, значит, большинство ошибок – это ошибки взаимодействия, вот в чем дело. Значит, основные ошибки возникают во время проектирования системы. Было бы нелепо полагать, что во время проверки кода можно анализировать архитектуру всей системы. Это же твои собственные слова. Анализ дизайна следует проводить отдельно, тогда же нужно отлавливать ошибки, которые в нем присутствуют. Почему проверка кода считается эффективной? Потому что на этом этапе исправлять ошибки проектирования немного проще, чем во время тестирования. Но ведь наш процесс проектирования стал более формальным. Мы проводим тщательную проверку архитектурных решений, причем не во время написания кода, а в момент проектирования. Именно поэтому у нас практически нет ошибок. А значит, проверка кода – пустая трата времени.

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

Скачать бесплатно книгу «Deadline. Роман об управлении проектами» Том Демарко

(Фрагмент)