出典：トムデマルコ「締め切り。 プロジェクト管理小説 ''
私の意見では、プロジェクト管理に関するそれほど有名ではない本からすべての「塩」を絞り出そうとしました。 私はそれを一般に公開します。
1.自分が安全だと感じない人は、変化に抵抗します。
2.リーダーが正常に機能するには変更が必要です。
3.不確実性により、人はリスクを回避できます。
4.リスクを回避するため、人は変化をもたらす可能性のある新しい機会と利益をすべて逃します。
5.従業員の生産性を重視する場合、脅威は最も不適切な動機です。
6.何を脅かしても、最初から完了に時間がかかりすぎると、タスクは完了しません。
7.さらに、人々が失敗した場合、あなたはあなたの約束を果たさなければなりません。
8.リーダーシップには心、腸、魂、香りが必要です。
9.もっと耳を傾け、話さない
10.プロジェクトを管理するには、そのリスクを管理するだけで十分です。
11.各プロジェクトのリスクリストを作成します。
12.最終的なリスクだけでなく、プロジェクトが失敗する原因となっているリスクを追跡します。
13.各リスクの可能性とコストを評価します。
14.リスクごとに、インジケータ-リスクが問題に変わることを判断できる症状を定義します。
15.悪いニュースを経営陣に報告するためのアクセス可能な（おそらく匿名の）チャネルを作成します。
16.損失を減らします。
17.プロジェクトの成功は、不必要な努力を減らすことで達成できます。
新しい勝利。
18.不要な作業を早めに停止するほど、プロジェクト全体が良くなります。
19.不必要に新しいチームを作成しようとしないでください。 既に形成され、ワークアウトされたチームをチームで調べます。
20.プロジェクト終了後もチームが一緒に作業できるようにします（プロジェクト自体が必要な場合）。その結果、あなたを置き換えたリーダーが、ひどく作業しているチームの問題を少なくします。
21.さらに協力を続けたいチームは、プロジェクトの主要な目標の1つであることを考慮してください。
22.プロジェクトの開始時に失う日とは、終了時に失う日と同じことを意味します。
23.一日を無駄に過ごす方法は千通りあり、今日を取り戻す方法はありません。
24.仮定をモデル化し、作業プロセスがどのように進むかについて推測します。
25.これらのモデルについて議論します。
26.各プロジェクトのサイズを定義します。
27.最初に測定単位の選択に熱心にならないでください。後で実際のデータを使用する必要がある場合、抽象的な単位が最初から表示されます。
28.単純なもの（あらゆるソフトウェア製品で簡単に数えることができるもの）に基づいて複雑なメトリックを構築します。
29.履歴データを収集して、すでに完了したプロジェクトの労働生産性を計算します。
30.取得した結果が、アーカイブデータに示されている作業量に対する抽象単位の比率を最も正確に反映するまで、複雑な合成メトリックを計算するための式を作成します。
31.予想される作業量を複雑な合成指標の値の比の形で示す、アーカイブデータベース全体にトレンドラインを描きます。
32.これで、新しいプロジェクトごとに、合成メトリックの値を計算し、それを予想される作業量の決定に使用するだけで十分になります。
33.性能線上の「干渉のレベル」を忘れずに、一般的な軌道からの許容偏差を決定する際の指標として使用してください。
34.優れた開発プロセスとその継続的な改善は、非常に価値のある目標です。
35.しかし、まだ実用的な目標と目的があります。
36.複数の方法論的改善を導入する試みは悲惨なビジネスです。 多くの技術とスキルを向上させることを目的としたプログラムは、用語が増加するだけであるという事実につながる可能性があります。
37.標準化された開発プロセスの危険性は、日常の運用中に、プロジェクト開発の時間と労力を節約する機会に人々が気付かない可能性があることです。
38.過度に大きなチームに関しては、誰もが仕事を感じることができる限り、標準化されたプロセスが厳密に守られます（プロジェクトに役立つかどうかは関係ありません）。
39.気にしないなら、興味がないなら、人々に違ったやり方をさせることはできません。 彼らが変わるためには、自分自身、彼らが何をしていて、彼らが何のために努力しているのかを理解（そして感謝）しなければなりません。
40.経営者が彼らに圧力をかけたとしても、人々はより速く考え始めることはありません。
41.残業が多いほど、生産性は低下します。
42.少しのプレッシャーと残業は、問題に集中し、その重要性を理解し、感じるのに役立ちますが、継続的なプレッシャーは常に悪いです。
43.状況に影響を与える他の方法を単に知らないため、または彼らにとって代替ソリューションが複雑すぎると思われるため、経営陣は圧力をかけることを非常に好むでしょう。
44.ひどい予感：プレッシャーと残業は、1つの問題だけを解決するように設計されています-悪いゲームで良い顔を維持するためです。
45.不明な仕様は、プロジェクト参加者間に未解決の競合があることを示しています。
46.着信情報と発信情報のタイプのリストがない仕様は、考慮に入れられるべきではありません。 これは、単に何も指定しないことを意味します。
47.複数の当事者が関与するプロジェクトは、必然的に利益相反に直面します。
48.ソフトウェアシステムを作成および配布するプロセスは、あらゆる種類の競合の温床です。
49.ソフトウェアが作成されるほとんどの企業では、競合解決を特に扱っている人はいません。
50.紛争は理解と尊敬に値する。 紛争は、非専門的な行動とは関係ありません。
51.すべての参加者の利益を考慮に入れようとすることを全員に報告し、そうであることを確認します。
52.交渉するのは難しいです。 調停がはるかに簡単です。
53.対立する当事者の利益が完全にまたは部分的に対立する場合、解決策の検索は仲介者にシフトされることを事前に発表する。
54.忘れないでください：私たちはバリケードの片側にいます。 反対側には問題自体があります。
55.人間の触媒があります。 彼らは健全なチーム、人間関係、闘争心を作るのを助けます。 彼らが他に何もしなかったとしても（そして、原則として、彼らは多くのことをします）、プロジェクトにおける彼らの役割は最も重要なものの1つのままです。
56.最悪のことは何かを知らないことだと思われます。 実際に、実際にそうでないことを知っていると確信するのは、はるかに悪いことです。
57.ひどい仮定：締め切りが厳しく設定されていないチームは仕事が早く終わるようです。
58.会議は小規模でなければなりません。 これを行うには、不要な会議をスキップすることを恐れないようにする必要があります。 最も簡単な方法は、事前に議題を公開し、それを常に厳守することです。
59.当局のin辱や虐待から人々を守る。
60.覚えておいてください：仕事では恐怖=怒り。 部下に怒鳴り、あらゆる方法で屈辱を与え、in辱したいリーダーは、本当に何かを恐れています。
61.状況から抜け出す唯一の方法は、待機することです。 問題が解決するまで、または問題を解決する方法を見つけるまで待ってください。
62.もちろん、奇跡は起こりますが、それらに頼らないほうがましです。
63.怒りとケチ-これは、ビジネスの失敗に責任を負う人々が悪い会社に適用し始めている公式です。
64.怒りとチクチク感は、良い会社の真の目標とは正反対であり、従業員に対して寛大で思いやりがあるということです。
締め切り要約
All Articles