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

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. Щодо надміру великих команд, там стандарти­зований процес буде неухильно притримуватись до тих пір, поки він дозволяє всім почуватись при справі (не важливо, з користю для проекту чи ні).