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

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. Один з побічних ефектів спотвореної політики: мати добре вкомплектовану команду стає небезпечно.