Основи здорового глузду

1. В проекту має бути два строки здачі — запланований та бажаний.
2. Ці строки мають бути різними.
3. Бажаний строк має бути ближче запланованого – в цьому секрет успіху.

Злоба й скупість

1. Злоба й скупість — ось формула, яку починають застосовувати в поганих компаніях ті, хто несе відповідальність за невдачі в бізнесі.
2. Злоба й скупість прямо протилежні істинним цілям будь-якої хорошої компанії — бути щедрими й дбайливими по відношенню до своїх працівників.
3. Коли ви помічаєте в компанії прояви злоби й скупості, знайте, їх справжня причина — страх і боязнь провалу.

Про патологічну політику (ще раз)

1. Цю патологію неможливо вилікувати знизу.
2. Не варто втрачати час чи піддівати себе небезпеці, щоб перевірити попередній постулат на власному досвіді.
3. Часом єдиним виходом з ситуації є вичікування. Спробуйте почукати, поки проблема не вирішиться сама по собі або поки ви не знайдете спосіб відійти від неї в сторону.
4. Чудеса, звичайно, трапляються, але краще все ж на них не розраховувати.

Проблеми соціології

1. Збори мають бути невеликими. Для цього треба зробити так, щоб люди не боялись пропускати непотрібні їм збори. Найпростіший спосіб — завчасно оголосити повістку дня, а потім завжди строго її притримуватись.
2. Кожному проекту потрібна якась церемонія чи ритуал.
3. За допомогою церемоній можна концентрувати увагу тих, хто зібрався, на основних цілях та задачах зборів: с­коротити склад робочої групи, підвищити якість програм­ного коду і т. п.
4. Захищайте людей від образ та сварок керівництва.
5. Запам’ятайте: в роботі страх = гнів. Ті керівники, які люблять кричати на своїх підлеглих й всіляко принижують та ображають їх, насправді просто чогось дуже бо­яться.
6. Спостереження: якщо б для всіх прояви грубощів та зло­сті до підлеглих завжди означали б, що начальник про­сто боїться, то ніхто з керівників не став би так себе поводити просто зі страху, що його страх помітять! (Це, звичайно, не вирішує проблем такого керівника, але, принаймні, оберігає його підлеглих.)

Про персонал

1. Якщо в самому початку проект робить велика команда, це знижує ефективність найвідповідальнішої частини роботи — визначення архітектури системи (тому що всім розро­бникам треба скоріше дати якусь роботу).
2. Якщо роботу роздати людям і командам ще до того, як завер­шиться стадія дизайну продукту, не вдасться створити про­сті й ефективні моделі взаємодії між людь­ми й робочими групами.
3. Це призведе до втрати незалежності, збільшення числа зборів та нарад, загального незадоволення.
4. В ідеалі було б добре спочатку набрати маленьку коман­ду, яка б створила продуману архітектуру системи, а вже потім, на останню, шосту частину часу розро­бки в цю команду можна було б додати новий персонал (який працював би безпосередньо над кодуванням).
5. Жахливе припущення: здається, ті команди, перед якими не ставлять жорстких строків, закінчують роботу швидше!

Людині властиво помилятись

Нам здається, що найстрашніше — не знати чогось. Насправді значно гірше бути впевненим, що знаєш, коли насправді це не так.

Хто такий каталізатор проекту

1. Існують люди-каталізатори. Вони допомагають створити здорову команду, стосунки, бойовий дух. Навіть якщо б вони більше нічого не робили (а зазвичай вони роблять багато чого), їх роль в проекті залишається однією найбільш важливих.
2. Посередництво — ще одна сфера, в якій люди-каталізатори просто незамінні. А втім, посередництву можна навчитись, це не дуже складно.
3. Першим кроком до посередництва має бути маленька церемонія. Наприклад, можна сказати фразу: «Ви дозволите мені спробувати допомогти вам вирішити цей спір?»

Конфлікт

1. Проект, в якому беруть участь декілька сторін, обов’язково зіштовхнеться з конфліктом інтересів.
2. Процес створення та розповсюдження програмних систем — просто розсадник різноманітних конфліктів.
3. В більшості компаній, які створюють програмне забезпечення, ніхто спеціально не займається питанням вирішення конфліктів.
4. Конфлікт заслуговує на розуміння та поважне ставлення. Конфлікт не має нічого спільного з непрофесійною поведінкою.
5. Донесіть до кожного, що намагатиметесь враховувати інтереси всіх учасників, и прослідкуйте, щоб це так і було.
6. Важко домовлятись. Значно легше виступати посередником.
7. Оголосіть заздалегідь, що якщо інтереси конфліктуючих сторін повністю або частково протилежні, то пошук вирішення буде перекладений на посередника.
8. Не забувайте: ми знаходимось з одного боку барикад. З іншого боку знаходиться сама проблема.

Туманні специфікації

1. Неясність специфікації свідчить по те, що між учасниками проекту є невирішені конфлікти.
2. Специфікація, що не має списків типів вхідної та вихідної інформації, не повинна навіть прийматись до розгляду. Це означає, що вона просто нічого не специфікує.
3. Ніхто ніколи не скаже вам, що специфікація погана. Люди скоріше будуть звинувачувати себе в неспроможності зрозуміти написане, ніж сварити авторів специфікації.

Сердитий керівник

1. Злість та неповага заразні. Коли вище керівництво демонструє злість й неповагу до підлеглих, керівники середньої ланки починають копіювати їх поведінку. Так як і діти, яких карали в дитинстві, часто потім бувають жорстокими батьками.
2. Неповага та зліть, на думку деяких керівників, мають примусити підлеглих краще працювати. Це типова політика «батога та пряника». Але хіба коли-небудь неповага з боку керівництва призводила до того, що люди починали краще працювати?
3. Якщо керівник демонструє неповагу до підлеглих, це є ознакою того, що він не може більше займати свою посаду (аж ніяк не ознака того, що в нього погані підлеглі).

Що дає тиск згори

1. Люди не почнуть швидше міркувати, якщо керівництво буде тиснути на них.
2. Чим більше понаднормової роботи, тим нижча продуктивність.
3. Трохи тиску та понаднормової роботи можуть допомогти сконцентруватись на проблемі, зрозуміти та відчути її важливість, але тривалий тиск завжди шкідливий.

Працювати по-іншому

1. Існує лише один спосіб скоротити час розробки, коли його й без того мало — зменшити час відлагодження програми.
2. Проекти з високою продуктивністю вимагають значно менше часу на відлагодження та виправлення помилок.
3. Проекти з високою продуктивністю вимагають значно більше часу на проектування.
4. Не можна примусити людей робити щось по-іншому, якщо ти про них не дбаєш, якщо ти ними не цікавишся. Для того, щоб вони змінились, ти маєш розуміти (й цінутвати) їх самих, те, що вони роблять, й чого прагнуть.

Процес розробки та його покращення

1. Добрий процес розробки та його постійне покращення — цілком пристойні цілі.
2. Але також існують робочі цілі й задачі: добрий працівник сконцентрує увагу як раз на них, навіть якщо ви його про це не просили.
3. Формальні програми, скеровані на покращення існуючого процесу розробки, будуть дорого коштувати коман­ді — в відношенні і часу, і грошей. Навіть окремі зусилля з покращення процесу можуть відкинути команду далеко назад. Щодо можливого підвищення продуктивності, то навіть якщо це й станеться, наврядчи переваги від цього підвищення перекриють затрати.
4. Можна сподіватись отримати позитивний результат від якогось од­ного добре виваженого й ретельно обраного вдосконалення в методиці роботи. В такому випадку воно может компенсувати гроші та час, затрачені на його впровадження.
5. Спроба впровадити більш ніж одне вдосконалення мето­дології — пропаща справа. Програми, скеровані на покащення багатьох прийомів та навиків (наприклад, перехід на наступний рівень СММ), скоріш за все призведуть до того, що строки тільки збільшаться.
6. Небезпека стандартизованого процесу розробки полягає в тому, що за рутиними операціями люди можуть не помітити можливість зекономити час та зусилля в розро­бці проекту.
7. Щодо надміру великих команд, там стандарти­зований процес буде неухильно притримуватись до тих пір, поки він дозволяє всім почуватись при справі (не важливо, з користю для проекту чи ні).

Збирання метричних даних

1. Визначайте розмір кожного проекту
2. Не переймайтесь спочатку вибором одиниці вимірювання - якщо згодом вам доведеться працювати з реальними даними, для початку згодятся й абстрактні одиниці.
3. Будуйте складні метрики на основі простих (тих, що легко підрахувати в будь-якому програмному продукті).
4. Збирайте архівні дані, щоб рахувати продуктивність праці по вже закінченим проектам.
5. Працюйте над формулами обрахунку складних синтетичних метрик доти, доки отримані результати не будуть найточніше відображати відношення абстрактних одиниць до вказаного в архівних даних об'єму робіт.
6. Проведіть через всю архівну базу даних лінію тренду, що буде показувати очікуваний об'єм робіт у вигляді відношення значень складних синтетичних метрик.
7. Тепер для кожного нового проекту достатньо буде вирахувати значення синтетичної метрики і використовувати її при визначенні очікуваного об'єму робіт.
8. Не забувайте про "рівень перешкод" на лінії продуктивності і використовуйте його як індикатор при визначенні припустимих відхилень від загальної траекторії.
   

Спотворена політика

1. В будь-який момент треба бути готовим відмовитись від роботи й розрахуватись...
2. ...однак це не значить, щи ви тим самим зможете уникнути наслідків спотвореної політики.
3. Спотворена політика дістане вас всюди, навіть в найздоровшій та найчистішій організації.
   
4. Головна ознака спотвореної політики: в основу ставляться особисті цілі та вплив, а не спільні інтереси компанії.
5. Це може статись навіть тоді, коли особисті цілі напряму суперечать цілям організації.
6. Один з побічних ефектів спотвореної політики: мати добре вкомплектовану команду стає небезпечно.
   

Моделювання процесу розробки

1. Моделюйте свої передбачення та здогади про те, як піде процес роботи.
2. Обговорюйте ці моделі разом з партнером, щоб краще розуміти процес роботи та вносити необхідні виправлення.
3. Передбачайте результати роботи за допомогою моделі.
4. Порівнюйте результати, отримані в процесі моделювання, з реальними.
   

Грай в захисті

1. Зменшуйте витрати.
2. Успіх проекту швидше забезпечується скороченням непотрібних зусиль, аніж прагненням до нових перемог.
3. Чим раніше ви припините непотрібну роботу, тим краще для всього проекту.
4. Не намагайтесь створювати нові команди без необхідності; пошукайте серед колективу команди, що вже склались і спрацювались.
5. Залишайте команди працювати разом і після закінчення проекту (якщо вони самі цього хочуть), щоб в керівників, що прийдуть вам на зміну, було менше проблем з командами, що погано спрацьовуються.
6. Вважайте, що команда, що хоче продовжувати працювати разом й надалі, - це одна з основних цілей будь-якого проекту.
7. День, який ми втрачаємо на початку проекту, важить стільки ж, скільки й день, втрачений в кінці.
8. Існує тисяча і один спосіб втратити дань дарма й жодного , щоб повернути цей день назад.
   

Підвищення продуктивності. Управління ризиками

Підвищення продуктивності

1. Не існує ніяких короткотермінових способів, які б дозволили швидко підвищити продуктивность праці.
2. Підвищення продуктивності - результат довготермінових зусиль.
3. Будь-які засоби для підвищення продуктивності, що обіцяють негайний результат, насправді є нічим іншим, як фікцією.

Управління ризиками

1. Для того, щоб керувати проектом, достатньо керувати його ризиками.
2. Складіть список ризиків для кожного проекту.
3. Відслідковуйте ті ризики, які є причиною провалу проекту, а не тільки кінцеві ризики.
4. Оцініть ймовірність виникнення і вартість кожного ризику.
5. Для кожного ризику визначте показник - симптом, за яким можна виявити, що ризик перетворюється на проблему.
6. Призначте спеціальну людину для керування ризиками, і нехай вона не підтримує девізу "Ми можемо все!", що культивується начальством.
7. Створіть доступні (можливо, анонімні) канали для повідомлення поганих новин керівництву.
   

Співбесіда і прийом на роботу

Головнокомандуючий на полі битви, як метафора управління проектами.
До початку бою робота головнокомандуючого вже завершена.
Співбесіда і прийом на роботу

1. Щоб прийняти людину на роботу, менеджеру потрібні всі його здібності: серце, душа, нюх та вміння відчувати нутром (останнє в більшій мірі).
2. Не намагайтесьнаймати людей один - значно краще задіяти в цьому процесі інтуїцію двох менеджерів.
3. Попросіть нових членів команди взятись за ту роботу в проекті, яку вони вже успішно виконували в минолому, а інші амбіції та зріст відкласти до наступного проекту.
   
4. Попросіть наводку - людина, яку ви вже вибрали собі в команду, напевне може порадити, кого вам ще варто найняти.
   
5. Більше слухайте, менше говоріть.
6. Все це спрацює ще краще, якщо ви злегка підтасуєте колоду.
   

Необхідні для управління проектами частини тіла

1. Для управління потрібні серце, нутро, душа та нюх
2. Отож:

• керувати треба серцем
• відчувати нутром
• вкладати в команду й проект душу
• мати нюх на всякі дурниці й нісенітниці

Негативна мотивація

1. Погрози - найменш придатний вид мотивації, якщо вас хвилює продуктивність працівників.
2. Чим би ви не погрожували, задача все одно не буде виконана, якщо з самого початку ви виділили на її виконання недостатньо часу.
3. Більш того, якщо люди не впораються, вам доведеться виконувати свої обіцянки.

Безпека та зміни

Якщо людина не відчуває, що знаходиться в безпеці, вона буде опиратися змінам.

1. Зміни необхідні керівнику для успішної роботи (вони також необхідні в буль-якій іншій діяльності)
2. Невпевненість змушує людину уникати ризику.
3. Уникаючи ризику, людина уникає нових можливостей та вигод, які могли б дати зміни.
4. Людину легко залякати прямими погрозами, а також можна їй просто натякнути, що в разі чого з нею можуть обійтися грубо і жорстоко. Ефект буде таким же.
   

Дедлайн. Роман про управління проектами

"Дедлайн. Роман про управління проектами", автор Том ДеМарко, - зараз читаю. Інформація викладена дуже просто, у вигляді художнього твору, роману, а найважливіші речі, підкреслюються в кінці кожної глави.
Планую по кілька речень викладати в блозі - резюме осиленого.

Управління Проектами - Це Просто

Від управління проекту залежить, чи буде він успішним, чи навпаки. В цій галузі завжди є куди рухатись, змінюватись, вдосконалюватись. Я встигла попрацювати і з добрими, і з не дуже.. керівниками, тому добре усвідомлюю їх роль в розробці проектів.

Буду вчитись і нотувати те, що варто не забувати, в цьому блозі. Якщо ви маєте досвід і бажаєте поділитись своїми історіями, ласкаво прошу коментувати, буду вдячна.

Поїхали!