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

Введение

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

Все принципы управления проектами описаны здесь в интересной и ненавязчивой форме — форме бизнес-романа. 

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

— Вам не кажется, что у вас неоправданно много людей для каких-то шести проектов? 

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

— Понятно, — сказал он. — У нас тут работа всего-то для сотни человек. 

— Верно. А что вы будете делать с остальными? 

— Ума не приложу. Вы считаете, что я должен решать эту проблему? Ну, пусть тогда пойдут в отпуск. 

— Это не проблема, Вебстер. Это ваш шанс. Шанс совершить небывалый эксперимент в управлении проектами. Неужели вам никогда не хотелось доподлинно узнать, как бы команда справилась с проектом, если бы использовала не эту, а другую методологию? 

Неужели вам не интересно было бы дать одну и ту же задачу разным командам? Двум, трем… 

Глаза мистера Томпкинса загорелись: 

— Эксперимент… Одна команда работает под жестким контролем, другая — под умеренным, третья — практически свободно, и все три решают одну и ту же задачу. А мы смотрим, какая из них быстрее закончит. Всю жизнь мечтал сделать что-то подобное. Можно создать многочисленную команду, малочисленную и команду с оптимальным, на мой взгляд, числом участников… 

— В одну команду набрать только опытных специалистов, в другую — опытных и новичков, — продолжила Лакса. 

Но мистер Томпкинс уже насквозь проникся идеей. 

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

 — Все в ваших руках, Вебстер. Можете экспериментировать над всей Моровией, вот она, первая в мире Лаборатория по управлению проектами. 

Томпкинс получил в подарок записную книжку, в которую он должен был записывать те открытия, которые он сможет сделать в процессе работы. 

На первой странице тоже была сделана запись: Четыре основных правила менеджмента. 

1. Найти нужных людей.

2. Дать им ту работу, для которой они более всего подходят.

3. Не забывать о мотивации.

4. Сплотить команду и поддерживать ее в состоянии сплоченности. (Все остальное — административная ерундистика.) 

Из записной книжки мистера Томпкинса 

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

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. Чем больше сверхурочной работы, тем ниже производительность. 

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

66. Возможно, руководство так любит применять давление, потому что просто не знает, как иначе можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся ему слишком сложными. 

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

Грозный начальник 

68. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать такое поведение . Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями. 

69. Неуважение и злоба, по мнению некоторых руководителей, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но такой «кнут» никогда не сподвигает людей работать лучше. 

70. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не того, что у него плохие подчиненные). 

Туманные спецификации на разработку 

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

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

73. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут подозревать себя в неспособности понять написанное, чем обвинят авторов спецификации в несостоятельности. 

Конфликт 

74. Проект, в котором участвуют несколько сторон, не избежит конфликта интересов. 

75. Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов. 

76. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов. 

77. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением. 

78. Донесите до каждого, что будете учитывать интересы всех участников, и исполняйте свое обещание. 

79. Тяжело договариваться. Гораздо легче выступать посредником. 

80. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника. 

81. Не забывайте: все участники ситуации находятся по одну сторону баррикад. По другую сторону находится сама проблема. 

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

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

83. Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно. 

84. Первым шагом в деле посредничества должна быть маленькая церемония. Например, можно произнести фразу «Можно я попробую рассудить ваш спор?». 

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

85. Нам кажется, что самое страшное — незнание. Но гораздо хуже ложное знание. 

О персонале 

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

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

88. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству. 

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

90. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее тех, которые сильно ограничены во времени! 

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

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

92. Каждому проекту нужна какая-то церемония или ритуал. 

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

94. Защищайте людей от давления и ругани Больших Боссов. 

95. Запомните: в работе страх = гнев. Руководители, которые постоянно кричат на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся. 

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

Если вам случится работать под руководством злобного придурка, надейтесь на чудо. 

Об извращенной политике (еще раз) 

97. Эту патологию невозможно вылечить снизу. 

98. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте. 

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

100. Чудеса, конечно, случаются, но лучше на них не рассчитывать. 

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

101. Злоба плюс скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе. 

102. Злоба и скупость прямо противоположны истинным ценностям любой хорошей компании — быть щедрыми и заботливыми по отношению к своим сотрудникам. 

103. Если вы подмечаете в компании проявления злобы и скупости, знайте: их настоящая причина — страх провала. 

Записная книжка мистера Томпкинса, свидетель и хранитель всех его необыкновенных приключений, открытий и знакомств, в требовательном ожидании лежала перед ним на столе, открытая на сто второй странице. Ему хотелось, чтобы последняя запись стала чем-то особенным, суммировала бы весь его новый опыт и полученные знания. Однако окончательные выводы все никак не могли оформиться в его голове. Может быть, такой итоговой записью была вся его записная книжка целиком? Он пролистнул одну страницу назад. Там было написано то, что он уже давно понял, но все никак не удосуживался выразить на бумаге. 

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

104. У проекта должно быть два срока сдачи — запланированный и желаемый. 

105. Эти сроки не должны совпадать. 

— Расскажите, пожалуйста, об опыте, который вы приобрели в Моровии. О том, что вы узнали на пути к сегодняшнему успеху и что изобретали прямо по ходу проекта. 

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

— Это был второй вопрос, — признался журналист. 

— Итак, что же я делал правильно, а что — неправильно и к каким выводам пришел… — задумчиво проговорил мистер Томпкинс. — Забавно, что ты об этом спрашиваешь. Этот же вопрос я задавал себе с первого дня пребывания в Моровии. И знаешь, почти каждый день я записывал свои выводы и наблюдения в записную книжку. 

— Боже мой, ведь это именно то, что мы хотели узнать! Я думаю, тысячи руководителей годами мечтали узнать то, что вы здесь изложили. И как много здесь записей? 

— Сто пять, — ответил мистер Томпкинс. 

— И вы хотите мне это отдать? Давайте я сделаю себе копию, а оригинал верну вам? 

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

Об авторе

Том ДеМарко — американский писатель, классик разработки программного обеспечения. В 1970-х годах принимал участие в создании методологии структурного анализа с целью преобразования общих, неясных данных о требованиях к системе в точные определения. Лауреат премии Warnier Prize за вклад в развитие вычислительной техники и премии Стивенса за вклад в методы разработки программного обеспечения. Автор 15 книг, в том числе художественных.

/2086