1

標準的な日には、プロジェクトの優先順位が競合する状況がいくつもあります。経営陣は従業員の生産性を最大限に高めたいと考えています。マーケティングは、最大の販売可能性と迅速なターンアラウンドを望んでいます。所有者は最大の利益を求めます。顧客は使いやすさと低コストを求めています。要求の出所に関係なく、時間とお金は常にビジネスの制限要因です。

プロジェクト要素には、金銭的手段で測定する困難で迅速な方法がない本質的または善意の利点がある場合があります (たとえば、魅力的な UI の魅力と機能的であるが単純な理由の議論)。ソフトウェアの他の要素には、開発者に「精神的な休憩」を提供したり、他のより大きく複雑な問題を軌道に乗せるための「クールな要因」を与える方法がある場合があります。短期的にはプロジェクトを脇道に置くかもしれませんが、長期的には仕事の満足度の向上などにより、より大きな結果が得られる可能性があります。継続的なトレーニングは必須ですが、トレーニングに取り組むことで進歩を取り戻すことができます。

  • 優先順位を設定するための提案は何ですか? プロジェクトの要求/要求をどのように評価しますか?
  • チームが集中力を維持できるように、それらを伝えてチームに伝えるための提案は何ですか?
4

2 に答える 2

2

簡単に言えば、これがまさに、PM をソフトウェアや方法論の一部で置き換えることができない理由です。さまざまな制約間のトレードオフを見つけて、それらを機会やチームの能力と一致させることが設計を構成し、プロジェクトはソフトウェアと同様の方法で設計されます。スコープと品質の要件は、PM のパーソナリティ、知識、経験、影響力、交渉力、ビジョンを伝える能力によって異なります。特に、規制や厳格なルールがほとんど存在しないソフトウェア開発の世界では異なります。さらに、プロジェクトの範囲設定は、合理的な実行と同じくらい政治的です。

そのため、プロジェクト計画は個人の視点を反映した知的な人工物であり、プロジェクトの概念の整合性は常に少数の重要人物の肩にかかっています。

特定の要件とは別に、スコーピング プロセスで使用される通常のインプットとツールは次のとおりです。

  • コストと利益の分析、および特定の要件がどの程度収益性が高いか、または賢明であるかを示すさまざまな財務指標。
  • 方向性を示し、取り組みに焦点を当てることを目的として正確に存在する組織戦略。
  • 各種規制。ソフトウェアでの彼らの役割は、たとえば建設よりもやや目立たない. ただし、金融、娯楽、安全上重要なソフトウェアはすべて規制の対象となります。
  • 業界ガイドライン
  • 会社の原則（悪意を持ってはいけない、顧客を公正に扱うなど）
  • 人的要因
  • 環境要因。

異なる会社内の同じ名前の部門であっても、通常、プロジェクトの要件に影響を与える力は異なります。これは組織構造に依存し、PM はそのような権限構成を十分に認識して理解する必要があります。たとえば、マーケティングとセールスに非常に影響力のある企業もあれば、主に財務部門が方向性を担当する企業もあります。政治的要件は、次の 3 次元スケールを使用して分析できます

  1. 正当性— 請求が有効であり、請求者が実際に何かを行うよう求めることに合法的な利益を持っているかどうかを示します。
  2. 力— 請求者が物事を自分の思い通りにする権限と力を持っているかどうか。
  3. 緊急性— 請求者が実際にその必要性を持っているか、またはその請求が重要であると考えているかどうかを示します。

正当性、権限、緊急性の 3 つすべてを備えた要件を無視することは非常に困難です。ただし、この分割の影響を見ると、最も興味深いのは、要素の 1 つまたは 2 つが欠落しているシナリオです。

  • 正当性のない緊急性と権力の組み合わせは、いくつかの非常に悪い非常に政治的な要件をもたらします。
  • 力に欠ける緊急性と正当性は、組合を作るか、強力なプレーヤーを味方につけて、要件が確実に聞き出され、行動することを検討することになります。より有利な条件で取引される可能性が高いため、事前に取引を行った方がよい場合があります。
  • 力と正当性は、緊急性が生じるまで特定の要件を追求する可能性は低い. PM は、これらの要件を安全に無視できるか、優先順位を下げてよいかを賢く判断する必要があります。
于 2010-03-22T14:45:05.373 に答える
2

1 つのメカニズム (Joel が Fog Creek で使用されていると説明したメカニズムと類似している) は、基本的にオークションです。

発言権を持つべき全員を集めることから始めましょう。これは、営業、開発、サポート、マーケティングなどの各担当者が 1 人か 2 人である可能性があります。

これらの代表者またはチームには、それぞれの発言に応じて「予算」が与えられます。予算の配分方法が均等である可能性は低いです。売上高は、ユーザーまたはより多くのお金の見通しを代表するため、おそらくはるかに大きな発言力を持っているはずですが、それはあなた次第です. 私が提案する唯一のことは、どのチームも予算の 50% 以上を持つべきではないということです。

次のリリースで考えられるすべての変更点を表に挙げ、それらの利点と開発にかかる時間を説明して、全員が理解できるようにします。可能な限り同じサイズのチャンクに分割する必要があり、次のリリースで使用可能な時間の 50% 以上を 1 つのチャンクが占めないようにする必要があります。

今、人々は予算を使うことができます。各チーム/個人は、やりたいことの間でお金を分割します。すべてを 1 つのことに費やすことも、複数に分割することもできます。

それが終わったら、何がリリースに適合するかを考え出し、それに対して合計で最も多くのお金がかかるものから始めて、リリースの時間がなくなるまで下げていきます.

次に、彼らが「入札」を調整して繰り返すことを許可したい場合がありますが、通常は 3 ラウンド以内にする必要があります。

なぜこれが機能するのですか？

私にとって最も重要なことは、何が重要かについて人々が持っている知識を活用し、それに基づいて選択できるようにすることです。

開発者および/またはサポートが、たとえばデータベースのリファクタリングが重要であることを知っている場合、予算全体をそれに費やすことができます (注: これが、予算の 50% 以上を割り当てて単一の変更を行うべきではない理由です。リリースの 50% 以上である必要があります。これらに違反すると、個々のチームが「これは本当に重要です」と言う能力が失われます。他のすべてを犠牲にしても、それを実現する力がないためです)。

あなたがしていないのは、彼らにとって本当に意味のない方法で利益を定量化することを強制することです.それ以外の場合は、それを行うために他のすべて (または他の多くのこと) を犠牲にします。」

同様に、販売担当者がそのホログラフィック インターフェースをどうしても必要とする場合は、そうすることができますが、それを得るために (販売を促進すると信じている他のものに入札するための資金が少なくなるという形で) 犠牲を払う必要があります。

于 2010-03-23T11:40:07.183 に答える