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

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

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

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

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

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

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

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

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

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