ほぼ60年後、 Tom DeMarcoは彼の無限の知恵を共有し、Timothy Listerと共同で書かれたPeoplewareのアイデアを同様に人気のある形式で提示することにしました。 その結果、「 プロジェクトマネジメントロマンス 」が生まれました。旧友のトンプキンス氏がセクシーなブルネットのラクサフーリガンに誘andされ、神秘的な国モロヴィアに連れて行かれ、そこでソフトウェア開発のプロジェクト管理に関する実際の実験を行う機会があります。
各章の終わりに、トンプキンス氏は、DeMarcoとListerのプロジェクト管理の公理と仮定である彼の考えを要約し、書き留めています。 もちろん、本全体を読むことをお勧めします。そうしないと、これらの原則が「実際の」生活にどのように適用されるか理解できなくなります。 しかし、時間がない場合（または単に記憶をリフレッシュしたい場合）、注意が必要です...
4つの基本的な管理ルール
- 適切な人を見つける。
- 彼らに最適な仕事を与えてください。
- モチベーションを忘れないでください。
- 彼らが1つのチームに団結し、それに取り組むことを支援するため。 （それ以外はすべて管理上のナンセンスです。）
セキュリティと変更
- 人が自分が安全だと感じない場合、変化に抵抗します。
- リーダーが正常に機能するには変更が必要です（他のアクティビティでは必ず必要です）。
- 不確実性により、人はリスクを回避できます。
- リスクを避けて、人は変化をもたらす可能性のあるすべての新しい機会と利益を逃します。
- 直接的な脅威に脅かされることは簡単ですが、場合によっては無作法に残酷に扱われることを彼に知らせることもできます。 効果は同じです。
否定的な動機
- 従業員の生産性を重視する場合、脅威は最も不適切な動機です。
- どのような脅威であっても、最初から完了に時間がかかりすぎると、タスクは完了しません。
- さらに、人々が失敗した場合、あなたはあなたの約束を果たす必要があります。
プロジェクト管理に必要な身体部位
- リーダーシップには心、腸、魂、香りが必要です。 だから：
- 心を導く必要がある。
- 内に感じる;
- チームとプロジェクトに投資する。
- あらゆる種類のナンセンスとナンセンスに鼻を持つこと。
- プロジェクト管理の隠phorとしての戦場の最高司令官
- 戦闘の開始までに、最高司令官の仕事はすでに完了しています。
就職の面接と募集
- 働く人を雇うために、マネージャーはすべての能力を必要とします：心、魂、香り、そして自分の腸で感じる能力（ほとんどの場合、後者）。
- 一人で人を雇おうとしないでください-このプロセスに2人のマネージャーの直感を取り入れることは、はるかに良いことです。
- 新しいチームメンバーに、過去に既に正常に完了した作業のためにプロジェクトに参加するよう依頼し、次のプロジェクトまで他の野望と成長を延期するよう依頼します。
- ヒントを求めてください。あなたがチームに参加するためにあなたが選んだ人は、おそらくあなたが他に誰を雇うべきかをアドバイスするでしょう。
- もっと聞いて、しゃべらない。
- そして、デッキを少しリグすれば、これはすべてうまく機能します。
生産性を向上
- 生産性を急速に高める短期的な対策はありません。
- 生産性の向上は、長期的な努力の結果です。
- 即時の結果を約束する生産性の向上は、実際には鳥のミルクにすぎません。
リスク管理
- プロジェクトを管理するには、そのリスクを管理するだけで十分です。
- 各プロジェクトのリスクリストを作成します。
- 最終的なリスクだけでなく、プロジェクトが失敗する原因となっているリスクを追跡します。
- 各リスクの可能性とコストを評価します。
- 各リスクについて、インジケータ-リスクが問題に変わることを判断できる症状を定義します。
- リスク管理のために特別な人を割り当て、「私たちは何でもできる！」というモットーを支持しないようにします。
- 悪いニュースを上司に報告するためのアクセス可能な（おそらく匿名の）チャネルを作成します。
プレイディフェンス
- 損失を削減します。
- プロジェクトの成功は、新しい勝利を目指して努力するのではなく、不必要な努力を減らすことで達成できます。
- 不要な作業を早めに停止するほど、プロジェクト全体にとって効果的です。
- 不必要に新しいチームを作成しようとしないでください。既存のチームやワークアウトされたチームを探してください。
- プロジェクトが終了した後でもチームが一緒に作業できるようにします（彼ら自身が望む場合）。
- さらに協力を続けたいチームは、プロジェクトの主要な目標の1つであることを考慮してください。
- プロジェクトの開始時に失う日は、終了時に失う日を意味します。
- 1日を無駄に過ごすには1,000の方法がありますが、今日を取り戻す方法は1つではありません。
開発モデリング
- 仮定をモデル化し、作業プロセスがどのように進むかについて推測します。
- これらのモデルについてパートナーと話し合い、プロセスをよりよく理解し、必要な修正を加えます。
- モデルを使用して作業結果を予測します。
- シミュレーション中に得られた結果を実際の結果と比較します。
ひどい政治
- いつでも仕事をあきらめて計算を求める準備ができている必要があります...
- ...しかし、これは、そうすることで、あなたがひそかな政策の結果を避けることができるという意味ではありません。
- 倒錯した政治は、最も健康でクリーンな組織であっても、どこにでも届きます。
- 倒錯したポリシーの主な兆候：個人の目標と影響力であり、会社の一般的な利益ではありません。
- これは、個人的な目標が組織の目標と直接矛盾する場合でも発生する可能性があります。
- 倒錯したポリシーの副作用の1つ：設備の整ったチームを持つことは危険になりつつあります。
メトリックデータ収集
- 各プロジェクトのサイズを決定します。
- 最初に測定単位を選択することに熱心にならないでください。後で実際のデータを処理する必要がある場合、最初から抽象的な単位が表示されます。
- 単純な指標（ソフトウェア製品で簡単に計算できる指標）に基づいて複雑な指標を構築します。
- 履歴データを収集して、すでに完了したプロジェクトの労働生産性を計算します。
- 取得した結果が、アーカイブデータで指定された作業量に対する抽象単位の比率を最も正確に反映するまで、複雑な合成メトリックを計算するための式に取り組みます。
- 予想される作業量を複雑な合成メトリックの値の比として示す、アーカイブデータベース全体にトレンドラインを描画します。
- 新しいプロジェクトごとに、合成メトリックの値を計算し、それを使用して予想される作業量を決定するだけで十分です。
- パフォーマンスラインの「干渉レベル」を忘れずに、一般的なパスからの許容偏差を決定する際の指標として使用してください。
開発プロセスとその改善
- 優れた開発プロセスとその継続的な改善は、非常に価値のある目標です。
- しかし、仕事上の目標と目的もあります。たとえあなたが彼に尋ねなかったとしても、優秀な従業員はそれらに集中します。
- 既存の開発プロセスの改善を目的とした正式なプログラムは、一時的および財政的に、チームに多大なコストをかけます。 プロセスを改善するための個々の努力でさえ、チームを遠ざけることができます。 生産性の向上の可能性については、たとえこれが発生したとしても、この増加の利点がコストをカバーする可能性は低いです。
- 作業方法のバランスのとれた、慎重に選択された1つの改善から、良い結果が得られることを期待できます。 この場合、実装に必要な費用と時間をカバーできます。
- 複数の方法論の改善を実装しようとすることは悲惨なビジネスです。 多くの技術とスキルの向上を目的としたプログラム（たとえば、次のレベルのCMMへの移行）は、時間の増加につながる可能性があります。
- 標準化された開発プロセスの危険性は、日常的な運用中に、プロジェクト開発の時間と労力を節約する機会に人々が気付かないことです。
- 過度に大規模なチームに関しては、誰もが仕事で感じることができる限り、標準化されたプロセスに従います（プロジェクトに役立つかどうかは関係ありません）。
別の仕事をする
- まだ十分ではない開発時間を短縮する方法は1つしかありません。プログラムのデバッグ時間を短縮することです。
- 高性能プロジェクトでは、バグのデバッグと修正に必要な時間が大幅に短縮されます。
- 高性能プロジェクトには、はるかに多くの設計時間が必要です。
- 気にしない場合、興味がない場合は、人々に違ったやり方をさせることはできません。 彼らが変化するためには、自分自身、彼らが何をし、彼らが何を目指しているかを理解（そして評価）しなければなりません。
上からの圧力を与えるもの
- 経営者が彼らに圧力をかけるならば、人々はより速く考え始めません。
- 残業が多いほど、生産性は低下します。
- 少しのプレッシャーと残業は、問題に焦点を合わせ、その重要性を理解し、感じるのに役立ちますが、長期的なプレッシャーは常に悪いものです。
- おそらく、経営者は、状況に影響を与える他の方法を単に知らないため、または代替ソリューションが彼らにとって複雑すぎるように見えるので、圧力をかけることをとても好みます。
- ひどい予感：プレッシャーと残業は、1つの問題だけを解決するように設計されています-悪いゲームで良い顔を維持するためです。
怒っているボス
- 怒りと無礼は伝染します。 上級管理職が部下に対して怒りと無礼を示すと、中間管理職は彼らの行動を真似し始めます。 同様に、幼少期に罰せられる子どもは、しばしば暴力的な親になります。
- 一部のボスによると、無礼と怒りは部下をより良くするはずです。 これは典型的なニンジンとスティックのポリシーです。 しかし、当局からの軽視は、人々がより良く働き始めたという事実につながったことがありますか？
- 上司が部下に対して無礼を示す場合、これは彼が自分の位置を占めることができないという兆候です（そして、悪い部下がいるという兆候はまったくありません）。
霧のスペック
- 仕様のあいまいさは、プロジェクトの参加者間に未解決の競合があることを示しています。
- 着信情報と発信情報のタイプのリストを持たない仕様は、考慮に入れるべきではありません。 これは、単に何も指定しないことを意味します。
- 仕様が悪いと言う人はいません。 人々は、仕様の作者をscるよりも、書かれていることを理解できないことを自責する傾向があります。
対立
- 複数の関係者が関与するプロジェクトは、利益相反に陥ります。
- ソフトウェアシステムを作成して配布するプロセスは、あらゆる種類の競合の温床です。
- ソフトウェアが作成されるほとんどの企業では、競合解決を特に扱う人はいません。
- 紛争は理解と尊敬に値する。 紛争は、非専門的な行動とは関係ありません。
- すべての参加者の利益を考慮に入れようとすることを全員に報告し、そうであることを確認してください。
- 交渉が難しい。 調停がはるかに簡単です。
- 対立する当事者の利益が完全にまたは部分的に対立する場合、解決策の検索は仲介者にシフトされることを事前に発表します。
- 忘れないでください：私たちはバリケードの片側にいます。 反対側には問題自体があります。
プロジェクトの触媒は誰ですか？
- 触媒の人々がいます。 彼らは健全なチーム、人間関係、闘争心を作るのを助けます。 彼らが他に何もしなかったとしても（そして、原則として、彼らは多くのことをします）、プロジェクトにおける彼らの役割は最も重要なものの1つのままです。
- 調停は、人間の触媒が単にかけがえのない別の分野です。 しかし、調停は学ぶことができます、それは非常に困難ではありません。
- 調停への最初のステップは小さなセレモニーであるべきです。 たとえば、「この論争を解決するのを手伝ってもらえますか？」というフレーズを言うことができます。
誤ることは人間です
- 最悪のことは何かを知らないことだと思われます。 実際に、実際にそうでないことを知っていると確信するのは、はるかに悪いことです。
スタッフについて
- プロジェクトが最初から大規模なチームによって行われる場合、これは作業の最も重要な部分の有効性を低下させます-システムのアーキテクチャを決定します（すべての開発者にすぐに作業を与える必要があるため）。
- 製品の設計段階が完了する前に作業が人とチームに分配される場合、人とワークグループ間の相互作用の単純で効果的なモデルを作成することはできません。
- これは、独立性の喪失、集会と会議の数の増加、一般的な不満につながります。
- 理想的には、最初によく考え抜かれたシステムアーキテクチャを作成する小さなチームを入力し、開発時間の最後の6番目の部分でのみ、このチームに新しいスタッフを追加できます（コーディングに直接取り組む）。
- ひどい仮定：締め切りが厳しくないチームは仕事が早く終わるようです！
社会学の問題
- 会議は小さくする必要があります。 これを行うには、不要な会議をスキップすることを恐れないようにする必要があります。 最も簡単な方法は、事前に議題を公開し、それを常に厳守することです。
- 各プロジェクトには、何らかの儀式や儀式が必要です。
- 式典の助けを借りて、会議の主な目標と目的に集中できます。ワーキンググループの構成を減らし、プログラムコードの品質を改善するなどです。
- 当局のand辱や虐待から人々を守ります。
- 覚えておいてください：恐れ＝仕事での怒り。 部下に怒鳴り、あらゆる方法で屈辱を与え、in辱したいリーダーは、本当に何かを恐れています。
- 観察：すべての人にとって、部下に対する無礼と怒りの現れが常に上司が単に恐れていることを意味する場合、上司の誰も彼の恐怖が目立つようになることを恐れて行動することはありません！ （もちろん、これはそのようなリーダーの問題を解決するものではありませんが、少なくとも彼の部下を保護します）。
病理政策について（再び）
- この病理は下から治すことはできません。
- 自分の経験から以前の仮説を検証するために、時間を無駄にしたり、自分を危険にさらしたりしないでください。
- 状況から抜け出す唯一の方法は、待機することです。 問題が解決するまで、または問題を解決する方法を見つけるまで待ってください。
- もちろん、奇跡は起こりますが、それらに頼らない方が良いです。
怒りとケチ
- 怒りとケチ-これは、ビジネスの失敗に責任を持つ人々が悪い会社に適用し始めている公式です。
- 怒りとチクチク感は、良い会社の真の目標とは正反対です。寛大で従業員を気遣うことです。
- 会社の怒りとけちに気づいたとき、彼らの本当の理由は恐れと失敗の恐れであることを知ってください。
常識の基本
- プロジェクトには2つの期限があります-計画済みと望ましい。
- これらの用語は異なる必要があります。