あるPJでバグは日々たくさん出るが直る数も多く、頑張ればバグはなくなるように見えました。
ここでほんの少しSINを遅らせるだけで収束するように見えます。
「あと二週間徹夜すれば！！」本当にそうか？

このときの収束曲線

開発を経験しているのであれば、バグが日々出ていることに着目して、「この時期にこんなにバグって出るもんだっけ？」と疑います。さらにバグの中身を見ます。単純な表示上の問題や計算の問題に見えるものが多いです。数十の画面で表示されるべきものが表示されなかったり、別のものが表示されたり。ここで「あれ？」と感じる人も多いでしょう。「バグの数が多すぎます。別のものが表示とは？表示されなかったり？数からいう１画面あたり１回以上？」どういう作りをするとそんなことに？
実態は、あまりにもバラバラに正規化されたテーブルを集めてデータにするところを一か所に集めてルーチン化したのですが、パターンが増えるごとにそこに手を加えていって、ものすごい巨大な関数がいつの間にか出来上がっていたのでした。なので問題があると、そこだけ直せば直るのですが、影響調査がしきれず、ほかのところに影響が出て、新たなバグになり・・・・バグの収束の速さとバグが出る量が多いことはそこが原因でした。「典型的スパゲッティー・・・」
それをほぐすには！とすぐに期間の見積もりを指示しますが、１月２月ではとてもやりきれないほどめちゃめちゃに・・・仕様の整理も十分にされていないようです。たとえバグをつぶしていって機能要件を満たしたとしても、性能要件での問題が起きそうです。
これは死亡プロジェクトの例です。行きつく先は契約解除と損害賠償です。(実例かどうかはノーコメント)
仕様がはっきりしない段階から開発をはじめ、仕様が明確になるにしたがって、機能を追加していった結果のコードでした。(最初に単機能のものを作り、あとから追加された機能をその機能に追加しました。あとから予想もしない機能がどんどん言われて、それも追加していくうちに、後戻りできず、現場はさらに追加し続けてしまった)現場のプログラマに開発を任せ、ウオーターフォールを無視して、設計レビューをせずにものの完成のみを追っていったために起きたのでした。アプリケーションアーキテクチャを機能全体を見て設計していたら避けられた事態です。
サービスイン直前まで数字のみを追って、現場の報告をうのみにしてきたためにそうなってしまったのです。開発経験をしたことがある人は何となくわかると思いますが、中身を見るPMであればもっと前から問題点に気が付いたであろう、予兆が見えたと思います。
上記例では技術上がりの管理者としては火を噴いた後から「たーすーけーてー」という声を受けて支援に入ったところで事態がわかるということになるかと思います。もっと早くから事態がわかっていれば打てた対策もあるかもしれません。

本来の収束曲線

どうするか！「解(solution)」に書きます

プログラマー経験があるとわかりますが、プログラミングってズバリセンスですよね。
センスが良ければ時間をかけずにそこそこのコードが書けるようになります。経験を積むと、人に迷惑をかけないソースが書けるようになって、さらに経験を積むと人のソースをみて、相手の考えていることがわかるようになりますよね。
PMも同じです。かなりセンスが要求されます。同じように経験を積むことでいろいろな管理方法論が確立されていって、怪しいところが犬のように臭いでわかるようになります。

いろんなPJをいろんな立場で経験していると、「その時どう考えていたかな？」「こういうことはありがちだな」などと思ったところは必ず記憶しておいて役に立てます。PG経験があるとPGの気持ちや落とし穴をよく知っていますから、管理するときでも「実はこういうことなのではないか？」という話ができてPJの真のもん亜ぢ店を明らかにして対策を打ったり、課題管理においても「この問題の解決策としてはこんなことがある」あるいは「この観点で調べるといいかも」などとアドバイスができたりします。(問題解決自体はマネージメントの仕事ではないのですが・・・)

たたき上げの嗅覚で対策した例を示します。
良い例かどうかはあれなんですが・・・

①必死のバグつぶし、バグは直っていくが・・・
②データの受け渡しの無駄
③バグを隠しているのではないか

これらについて述べていきます。
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。