遅延に対して脊髄反応的に手当しちゃうPM

炎上レベル：たき火

今日の炎上注意報のプロジェクトはこれです。
遅延が発生して、遅れを取り戻すために、他のチームから人をひっぱってきたり、同じチームの別の人が手伝ったりと。
もちろん大事ですよ。
でも、後先のことを考えないでやると大変なことに。。

次はこっちが遅延したぞ！おっとこっちもだ！

某マーケティング系アプリ案件の設計工程のお話し。

あるエースの女性がいました。ロジックの抜け漏れなどもよく気が付く素晴らしいスキルの持ち主。当然、難しい設計書などを担当することになりました。
しかし、人間だから体調不良はつきもの。
冬ということもあり、体調不良が数日お休みすることがあり、進捗遅延が発生しました。

で、やばい、遅れた！ということで他の優秀なメンバーがリカバリーに入りました。ところが、今度はそのメンバーがやるべきレビューがおざなりに。

レビューができてないから、設計書の品質がいまいちで、要件漏れ漏れの品質がいまいちな設計書がでてきました。作り直しでさらに遅延発生。
玉突き事故のように遅延が重なっていきました。

いやぁさすがにそんなことないでしょ？と思うかもしれませんが、嘘のような本当の話。

リカバリプランは余裕度と次の予定を考慮してたてる

PMは遅れを取り戻すのにやっきになるのではなく、一旦呼吸を整えて、全メンバーの進捗状況と次のタスクと期限を確認する必要があります。

次のタスク期限も含めて、もし余裕があるメンバーがいれば、リカバリにヘルプに入るべきですが、そうでなければ安易にヘルプに出すべきではないです。

他のメンバーが余裕がなければ、対策としてはこんなのがあります。
１．遅延タスクのスケジュールをずらしてリカバリポイントを作る
２．他のメンバーの作業スケジュールをずらして、ヘルプに向かわせる
　　（ずらしたのは後でリカバれる前提）
３．その機能か別機能をスコープから落とす
４．記載レベルを落とすとか、作業量を減らす調整をする

一番やっちゃいけないのは、体調不良になったメンバーがさらに稼働をあげて対応するというものです。確実に遅延スパイラルに陥ります。

今日の炎上防止ポイント

リカバリプランを立てる時は、ちゃんと次の予定と他のメンバーの余裕を見てからたてること