Why Nostr? What is Njump?
2024-07-01 02:13:46

DevelopersIO RSS feed【非公式】 on Nostr: 【[ゼロから始めるプロジェクトマネジメント] ...

【[ゼロから始めるプロジェクトマネジメント] プロジェクトの新規要件は工数を3倍にして請けるかどうかを判断しよう】
情報システム室の進地@日比谷です。 プロジェクト進行中に新しい要求、要件が発生する。よくあることです。そして、それほど重い要求、要件ではないと感じた貴方は直感で導いた工数で対応の可否を判断しようとする。これもよくあることです。 しかし、これはとてもx2危険なことです。 新規要件を即答して請けてはいけない理由 新規要件を即答して請けてはいけない理由はいくつかあります。 新規要件を出す側の心理的ハードルが下がり、新規要件が噴出しやすくなるから 直感で出した工数の確かさはかなり疑わしいから あなたは大きなステップを見落としているから、確実に すぐに出来ますと回答すると、相手はそれが「簡単にできることなんだ」と錯覚します。または、簡単にできることではなくても「無理を聞いてくれるんだ」と思ってしまいます。もちろんそんな人達ばかりではないでしょうが、そんな人達である可能性も勘案するとリスクヘッジとして勿体ぶらざるを得ないのです。普段から、負荷に応じたリアクションを心がけておかないと、相手によっては本当に大変な時にそれを信じてくれないといった展開も想定されますので気をつけてください。 直感で出した工数の確かさに関しては言及する必要はありませんね。不確かに決まっています。 要件が実現されるまでの最も単純なステップを考慮する 書籍「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」では、一つの要件が実現されるまでのステップを大雑把に設計、実装、テストの3工程としてとらえ、各々の工数、スケジュールをとっているかチェックすることを勧めています。 また、多少の増減はあるものの、設計、実装、テストの3工程に均一に工数、スケジュールが割り振られているかも、その見積の簡易な妥当性チェックとして使えるとしています。 さて、前段で「あなたは大きなステップを見落としている」と書きました。それがこれです。つまり、瞬間的に工数を考えるとき、あなたの頭の中にあるのは、たいてい「実装」の見積だけだということです。設計とテスト、この2工程を忘れている、またはその見積に与えるインパクトを過小評価している。意識している、していないに関わらず。 ではどうするか?簡単な方法はこれです。 ぱっと思った見積を3倍にして判断する これで、設計とテストが見積に自然に反映されます。プロセスレベルで考慮が抜けているという自体は避けることができます。 もっとゆっくりYesを言い、もっと素早くNoを言う 真面目で誠実なPMほど、様々なステークスホルダの想いを汲み取ろうとし、なるべく早く相手の要求を実現する方向で思考してしまいがちです。しかし、それが結果としてプロジェクトに良い影響をもたらすかというと疑問が付されることが多いのです。 基本的なスタイルとしてインストールしておきたいことは、即答は避ける、です。 即答して「出来ます!」だと相手の心象はそんなに悪くならないのですが1、即答して「出来ません!」は心象を悪くする可能性がままあります。それは、即答が「考えていない」というメッセージを発してしまうからです。ですので、特にパワーバランスに差がある関係性においては、即答は避け「少し考えさせてください」と言い、のちの回答にすると良いでしょう。 そして、即答しなければ、見積の妥当性も検証できますし、設計とテストの工程が工程ごと見落としてしまっているという事態も避けられるでしょう。 私たち、特にPMは「もっとゆっくりYesを言い、もっと素早くNoを言う」必要があるということです。 開発メンバーは地獄をみます ↩
https://dev.classmethod.jp/articles/road-to-pm-12-should-we-accept-3x-workload-new-requirements/
Author Public Key
npub16u6jx85wavk5n0kw5r46ma7dunupsp7acmtn3xys7keqvlsfjxpsar5q5c