is_реклам: анализ огтт

пошук, категорії та ін. показати ▼

Deadline. Роман про те як керувати проектами

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. Злоба і скупість прямо протилежні істинним цілям будь-якої хорошої компанії — бути щедрими і дбайливими по відношенні до своїх співробітників.
схоже за тегами

Залишити коментар:

Яндекс цитирования UA TOP Bloggers