Вступ
Том ДеМарко написав історію про досвідченого керівника, який потрапив до якоїсь уявної країни, де до різних правил управління вносилися поправки «згори». Головний герой – менеджер Вебстер Томпкінс – містичним чином опиняється у колишній соціалістичній республіці Моровії з тоталітарним режимом управління, де його було призначено керівником кількох проектів зі створення програмного забезпечення.
Усі принципи управління проектами описані тут у цікавій та ненав’язливій формі – формі бізнес-роману.
Знайдіть правильних людей. Потім, що б ви не робили, яких би помилок не допускали, люди витягнуть вас з будь-якої колотнечі. У цьому полягає робота керівника.
— Вам не здається, що у вас є невиправдано багато людей для якихось шести проектів?
Томпкінс подивився на перелік проектів, які відібрав для нього Великий Вождь Народів.
– Зрозуміло, – сказав він. — У нас тут робота всього для сотні людей.
– Правильно. А що ви робитимете з рештою?
— Розуму не докладу. Ви вважаєте, що я маю вирішувати цю проблему? Ну хай тоді підуть у відпустку.
— Це не проблема, Вебстере. Це ваш шанс. Шанс зробити небувалий експеримент в управлінні проектами. Невже вам ніколи не хотілося точно дізнатися, як би команда впоралася з проектом, якби використовувала не цю, а іншу методологію?
Невже вам не цікаво було б дати одне й те саме завдання різним командам? Двом, трьом…
Очі містера Томпкінса спалахнули:
— Експеримент… Одна команда працює під жорстким контролем, інша — під помірним, третя — практично вільно, і всі три вирішують те саме завдання. А ми дивимося, яка їх швидше закінчить. Все життя мріяв зробити щось схоже. Можна створити численну команду, нечисленну та команду з оптимальним, на мій погляд, числом учасників.
— До однієї команди набрати лише досвідчених фахівців, до іншої — досвідчених і новачків, — продовжила Лакса.
Але містер Томпкінс уже наскрізь перейнявся ідеєю.
— В одну набрати людей, які вже працювали разом, і подивитись, як вони змагатимуться з командою, де ніхто раніше один одного не знав. Якщо ми це зробимо, то зможемо розгадати одну з найбільших за гадок менеджменту. Ми дізнаємося, чому одним проектам супроводжує успіх, а іншим – ні.
– Все у ваших руках, Вебстере. Можете експериментувати над усією Моровією, ось вона, перша у світі Лабораторія з управління проектами.
Томпкінс отримав у подарунок записник, у якому він мав записувати ті відкриття, які зможе зробити у процесі роботи.
На першій сторінці теж було зроблено запис: Чотири основні правила менеджменту.
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. Ці терміни не повинні співпадати.
— Розкажіть, будь ласка, про досвід, який ви набули у Моровії. Про те, що ви дізналися на шляху до сьогоднішнього успіху і що винаходили прямо в ході проекту.
— Напевно, читачам буде цікавіше дізнатися про ті помилки, які я робив, і як я долав наслідки цих помилок.
— Це було друге питання, — зізнався журналіст.
— Отже, що я робив правильно, а що — неправильно і яких висновків дійшов… — задумливо промовив містер Томпкінс. — Дивно, що ти про це питаєш. Це ж питання я ставив собі з першого дня перебування у Моровії. І знаєш, майже кожен день я записував свої висновки та спостереження у записник.
— Боже мій, адже це саме те, що ми хотіли дізнатися! Я думаю, тисячі керівників роками мріяли дізнатися про те, що ви тут виклали. І як багато тут записів?
– Сто п’ять, – відповів містер Томпкінс.
— І ви хочете це мені віддати? Давайте зроблю собі копію, а оригінал поверну вам?
– Не треба, – похитав головою містер Томпкінс. — Мені здається, що мої записи принесуть користь вашим читачам. А мені вони вже не потрібні. Не думаю, що почав би перечитувати їх коли-небудь: я все це випробував на власній шкурі.