Можливо, зустрічаються ще менеджери, які вважають, що управління – це зібрання, програми навчання та підвищення якості продукції і різноманітні звіти. Однак у наш час стало очевидним, що управління проектами – це перш за все робота з людьми. Роман Тома ДеМарко, дає дуже багато дійсно цікавих інструментів для роботи. Головна ідея книги – розповісти про управління проектами, зробивши це в оригінальній, художній формі. Книга в легкій і невимушеній формі виробничого роману розповідає про основні правила управління проектами. Напевно, це єдиний у своєму роді твір. Нічого подібного до цього не зустрічав. Роман потрібно однозначно читати тим, хто застряг у кар’єрному розвитку або боїться, що ось-ось перегорить. Тут все розкладено по поличках. Якийсь компендіум знань про проекти.
Том ДеМарко – американський інженер-програміст, письменник і консультант з програмної інженерії.
Резюме:
- Оцінка: 8/10.
- Читати: так, якщо ви керуєте людьми або застрягли в кар’єрному розвитку.
З книги «Deadline. Роман про управління проектами», Том ДеМарко
У кінці кожного розділу Містер Томпкінс підводить підсумки і записує свої думки, які, по суті, є аксіомами і постулатами управління проектами по ДеМарко і Лістеру.
Чотири основних правила менеджменту:
- Знайти потрібних людей.
- Дати їм ту роботу, для якої вони найкраще підходять.
- Не забувати про мотивацію.
- Допомагати їм згуртуватися в одну команду і працювати так далі. (Все інше – адміністративна ерундистика.)
З блокнота містера Томпкінса
Безпека і переміни
- Якщо людина не шанує те, що знаходиться в безпеці, вона буде противиться змінам.
- Переміни необхідні керівнику для успішної роботи (напевно вони необхідні і в будь-якій іншій діяльності).
- Невпевненість змушує людину уникати ризику.
- Уникаючи ризику, людина втрачає всі нові можливості та вигоди, які могли б принести зміни.
- Людину легко залякати прямими погрозами, але також можна просто дати зрозуміти, що при нагоді можуть обійтися грубо і жорстко. Ефект буде таким же.
Негативна мотивація
- Загрози – самий невідповідний вид мотивації, якщо вас хвилює продуктивність співробітників.
- Чим би ви не погрожували, завдання все одно не буде виконано, якщо з самого початку ви відвели на її виконання занадто мало часу.
- Більш того, якщо люди не впораються, вам доведеться виконати свої обіцянки.
Частини тіла, необхідні для управління проектами
- Для керівництва потрібні серце, нутро, душа і нюх. Так що:
- керувати потрібно серцем;
- відчувати нутром;
- вкладати в команду і проект душу;
- мати нюх на всілякі дурниці і нісенітниці.
- Головнокомандувач на полі битви як метафора управління проектами.
- До початку бою робота головнокомандуючого уже закінчена.
Співбесіда і прийом на роботу
- Щоб найняти людину на роботу, менеджеру необхідні всі його здатності: серце, душа, нюх і здатність відчувати нутром (здебільшого останнє).
- Не намагайтеся наймати людей поодинці – набагато краще задіяти у цьому процесі інтуїцію двох менеджерів.
- Попросіть нових членів команди взятися в проекті за ту роботу, яку їм уже траплялося успішно виконувати в минулому, а інші амбіції і зростання відкласти до наступного проекту.
- Попросіть наводку: та людина, яку ви вибрали собі в команду, напевно може порадити, кого вам ще слід найняти.
- Більше слухайте, менше говоріть.
- І все це спрацює краще, якщо ви злегка підтасуєте колоду.
Підвищення продуктивності
- Не існує ніяких короткострокових заходів, які дозволили б швидко підвищити продуктивність роботи.
- Підвищення продуктивності – результат довгострокових зусиль.
- Будь-які засоби для підвищення продуктивності, які обіцяють негайний результат, насправді не що інше, як «пташине молоко».
Управління ризиками
- Щоб керувати проектом, досить управляти його ризиками.
- Створіть список ризиків для кожного проекту.
- Відстежуйте ті ризики, які є причиною провалу проекту, а не тільки кінцеві ризики.
- Оцініть ймовірність виникнення і вартість кожного ризику.
- Для кожного ризику визначте показник – симптом, за яким можна визначити, що ризик перетворюється в проблему.
- Призначте спеціальну людину для управління ризиками, і нехай він не підтримує девіз «Ми можемо все!», який культивує начальство.
- Створіть доступні (можливо, анонімні) канали для повідомлення поганих новин начальству.
Грай в захисті
- Скорочуйте втрати.
- Успіх проекту якомога швидше забезпечити скороченням непотрібних зусиль, ніж прагненням до нових перемог.
- Чим раніше ви припините непотрібну роботу, тим краще для всього проекту.
- Не намагайтеся створювати нові команди без необхідності: пошукайте в колективі вже сформовані і спрацьовані команди.
- Залишайте команди працювати разом і після закінчення проекту (якщо вони самі того хочуть), щоб у тих, хто прийшов вам на зміну керівників було менше проблем з погано спрацьованими командами.
- Вважайте, що команда, яка хоче продовжувати працювати разом і далі, – це одна з основних цілей будь-якого проекту.
- День, який ми втрачаємо на початку проекту, значить так само багато, як і день, втрачений в кінці.
- Є тисяча й один спосіб витратити день даремно і жодного, щоб повернути цей день назад.
Моделювання процесу розробки
- Моделюйте свої припущення і здогадки про те, як піде процес роботи.
- Обговорюйте ці моделі разом з партнером, щоб краще розуміти процес роботи і вносити необхідні виправлення.
- передбачати результати роботи за допомогою моделі.
- Порівнюйте результати, отримані в процесі моделювання, з реальними.
Збочена політика
- У будь-який момент потрібно бути готовим відмовитися від роботи і попросити розрахунок…
- …проте це не означає, що тим самим ви зможете уникнути наслідків збоченої політики.
- Збочена політика дістане вас всюди, навіть в самій здоровій і чистій організації.
- Головна ознака збоченої політики: на перше місце ставляться особисті цілі і вплив, а не загальні інтереси компанії.
- Це може статися навіть тоді, коли особисті цілі безпосередньо суперечать цілям організації.
- Один з побічних ефектів збоченої політики: мати добре укомплектовану команду стає небезпечно.
Збір метричних даних
- Визначайте розмір кожного проекту.
- Не старайтеся спочатку з вибором одиниці виміру – якщо згодом вам доведеться працювати з реальними даними, для початку зійдуть і абстрактні одиниці.
- Будуйте складні метрики на основі простих (тих, які легко підрахувати в будь-якому програмному продукті).
- Збирайте архівні дані, щоб вважати продуктивність праці по вже закінченим проектам.
- Працюйте над формулами обчислення складних синтетичних метрик до тих пір, поки отримані результати не будуть найбільш точно відображати ставлення абстрактних одиниць до зазначеного в архівних даних обсягом робіт.
- Проведіть через всю архівну базу даних лінію тренда, яка буде показувати очікуваний обсяг робіт у вигляді відношення значень складних синтетичних метрик.
- Тепер для кожного нового проекту досить буде вирахувати значення синтетичної метрики і використовувати її при визначенні очікуваного обсягу робіт.
- Не забувайте про «рівні перешкод» на лінії продуктивності і використовуйте його як індикатор при визначенні допустимих відхилень від загальної траєкторії.
Процес розробки і його поліпшення
- Хороший процес розробки і його постійне поліпшення – дуже гідні цілі.
- Але існують ще й робочі цілі та завдання: хороший працівник сконцентрує увагу саме на них, навіть якщо ви його про це не просили.
- Формальні програми, спрямовані на поліпшення існуючого процесу розробки, будуть дорого коштувати команді – і в часовому, і в грошовому відношенні. Навіть окремі зусилля щодо поліпшення процесу можуть відкинути команду далеко назад. Що стосується можливого підвищення продуктивності, то навіть якщо це і станеться, то навряд чи вигоди від цього підвищення покриють витрати.
- Можна сподіватися отримати позитивний результат від одного якогось добре зваженого і ретельно обраного удосконалення в методиці роботи. У цьому випадку воно може покрити гроші і час, які потрбні на його впровадження.
- Спроба впровадити більш одного удосконалення методології – пропаща справа. Програми, спрямовані на поліпшення багатьох прийомів і навичок (наприклад, перехід на наступний рівень CMM), швидше за все призведуть до того, що терміни тільки збільшаться.
- Небезпека стандартизованого процесу розробки полягає в тому, що за рутинними операціями люди можуть не помітити можливість заощадити час і зусилля по розробці проекту.
- Що стосується надмірно великих команд, то там стандартизований процес буде неухильно дотримуватися доти, поки він дозволяє всім почувати себе при справі (не важливо, з користю для проекту чи ні).
Робити роботу по-іншому
- Є тільки один спосіб скоротити час на розробку, коли його і без того мало – зменшити терміни налагодження програми.
- Проекти з високою продуктивністю вимагають набагато менше часу на налагодження і виправлення помилок.
- Проекти з високою продуктивністю вимагають набагато більше часу на проектування.
- Не можна змусити людей робити щось по-іншому, якщо про них не дбаєш, якщо ти ними НЕ цікавишся. Щоб вони змінилися, ти повинен розуміти (і цінувати) їх самих, що вони роблять і до чого прагнуть.
Що дає тиск зверху
- Люди не почнуть швидше міркувати, якщо керівництво буде тиснути на них.
- Чим більше понаднормової роботи, тим нижче продуктивність.
- Трохи тиску і понаднормової роботи можуть допомогти сконцентруватися на проблемі, зрозуміти і відчути її важливість, але тривалий тиск завжди погано.
- Можливо, керівництво так любить застосовувати тиск, тому що просто не знає, як ще можна вплинути на ситуацію, або ж тому, що альтернативні рішення здаються їм занадто складними.
- Жахлива здогад: тиск і понаднормова робота покликані вирішити тільки одну проблему – зберегти хорошу міну при поганій грі.
Сердитий начальник
- Злість і неповага заразливі. Коли вище керівництво демонструє злість і неповагу до підлеглих, керівники середньої ланки починають копіювати їх поведінку. Точно так же діти, яких карали в дитинстві, часто згодом стають жорстокими батьками.
- Неповага і злість, на думку деяких начальників, повинні змусити підлеглих краще працювати. Це типова політика «батога і пряника». Але хіба коли-небудь неповага з боку начальства призводила до того, що люди починали краще працювати?
- Якщо начальник демонструє неповагу до підлеглих, це ознака того, що він не може займати свою посаду (а зовсім не ознака того, що у нього погані підлеглі).
Туманні специфікації
- Неясність специфікації говорить про те, що між учасниками проекту є невирішені конфлікти.
- Специфікація, в якій немає списку типів вхідної та вихідної інформації, не повинна навіть прийматися до розгляду. Це означає, що вона просто нічого не специфікує.
- Ніхто ніколи не скаже вам, що специфікація погана. Люди швидше будуть звинувачувати себе в нездатності зрозуміти написане, ніж лаяти авторів специфікації.
Конфлікт
- Проект, в якому беруть участь кілька сторін, обов’язково зіткнеться з конфліктом інтересів.
- Процес створення та розповсюдження програмних систем – прямо-таки розсадник всіляких конфліктів.
- У більшості компаній, де створюється програмне забезпечення, ніхто спеціально не займається питанням вирішення конфліктів.
- Конфлікт заслуговує розуміння і шанобливого ставлення. Конфлікт не має нічого спільного з непрофесійною поведінкою.
- Донесіть до кожного, що постараєтеся враховувати інтереси всіх учасників, і простежте, щоб так воно і було.
- Важко домовлятися. Набагато легше виступати посередником.
- Оголосіть заздалегідь, що якщо інтереси конфліктуючих сторін повністю або частково протилежні, то пошук рішення буде перекладений на посередника.
- Не забувайте: ми знаходимося по один бік барикад. По інший бік знаходиться сама проблема.
Хто такий каталізатор проекту
- Чи існують люди-каталізатори. Вони допомагають створити здорову команду, відносини, бойовий дух. Навіть якби вони більше нічого не робили (а як правило, вони роблять набагато більше), їх роль в проекті залишається однією з найбільш важливих.
- Посередництво – ще одна сфера, в якій люди-каталізатори просто незамінні. Втім, посередництва можна навчитися, це не дуже складно.
- Першим кроком до посередництва повинна бути маленька церемонія. Наприклад, можна вимовити фразу: «Ви дозволите мені спробувати допомогти вам вирішити цю суперечку?»
Людині властиво помилятися
- Нам здається, що найстрашніше – не знати чого-то. Насправді набагато гірше бути впевненим, що знаєш, коли насправді це не так.
Про персоналі
- Якщо на самому початку проект робить велика команда, це знижує ефективність самої відповідальної частини роботи – визначення архітектури системи (бо всім розробникам треба швидше дати якусь роботу).
- Якщо роботу роздати людям і командам ще до того, як завершиться стадія дизайну продукту, не вийде створити прості й ефективні моделі взаємодії між людьми і робочими групами.
- Це призведе до втрати незалежності, збільшення числа зборів і нарад, загального невдоволення.
- В ідеалі було б добре спочатку набрати маленьку команду, яка створила б продуману архітектуру системи, а вже потім, на останню, шосту частину часу розробки в цю команду можна було б додати новий персонал (який працював би безпосередньо над кодуванням).
- Жахливе припущення: здається, ті команди, перед якими не ставлять жорстких термінів, закінчують роботу швидше!
Проблеми соціології
- Збори повинні бути невеликими. Для цього потрібно зробити так, щоб люди не боялися пропускати непотрібні їм зборів. Найпростіший спосіб – заздалегідь опублікувати порядок денний, а потім завжди строго його дотримуватися.
- Кожному проекту потрібна якась церемонія або ритуал.
- За допомогою церемоній можна концентрувати увагу присутніх на основні цілі та завдання наради: скоротити склад робочої групи, підвищити якість програмного коду і т.п.
- Захищайте людей від образ і лайки начальства.
- Запам’ятайте: в роботі страх = гнів. Ті керівники, які люблять кричати на своїх підлеглих і всіляко принижують і ображають їх, насправді просто чогось дуже бояться.
- Спостереження: якби для всіх прояв грубості і злості до підлеглих завжди означало б, що начальник просто боїться, то ніхто з начальників не став би так себе вести просто зі страху, що його страх стане помітний! (Це, звичайно, не вирішує проблем такого керівника, але, по крайній мірі, оберігає його підлеглих).
Про патологічну політику (ще раз)
- Цю патологію неможливо вилікувати знизу.
- Не варто втрачати час або наражатися на небезпеку, щоб перевірити попередній постулат на власному досвіді.
- Іноді єдиним виходом із ситуації стає вичікування. Спробуйте почекати, поки проблема не вирішиться сама по собі або поки ви не знайдете спосіб піти від неї в сторону.
- Чудеса, звичайно, трапляються, але краще все ж на них не розраховувати.
Злоба і скупість
- Злоба і скупість – ось формула, яку починають застосовувати в поганих компаніях ті, хто несе відповідальність за невдачі в бізнесі.
- Злоба і скупість прямо протилежні істинних цілей будь-якої доброї компанії – бути щедрим і дбайливим по відношенню до своїх співробітників.
- Коли ви помічаєте в компанії прояви злоби і скупості, знайте, їх справжня причина – страх і боязнь провалу.
Основи здорового глузду
- У проекту має бути два терміни здачі – запланований і бажаний.
- Ці терміни повинні бути різними.
