Первоисточник: Том ДеМарко “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. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
Автор: neegor
