炎上プロジェクトの火消し

私は、昔からトラブルプロジェクトに配属されることが多かった。いわゆる火消し役である。

その時の入り方を整理してみた、現状はあく。お客様に提出してる。社内のスケジュールを見せてもらう。ふつうは、スケジュールがひとつあなんであるが、こういうことが普通にある。

次に開発フェーズの時は、設計書のチェック。ソースのチェック。ソーソースのチェックは、本当にできてるのか？嘘はないかのチェックである。後、現在のフェーズと認識してる問題点

問題点は、ほとんどの場合、表面に化した問題で、本当のもんだいは、もっと奥底にある。そこを見つけ出す。ヒアリングで。体制とコミュニケーションのラインを確認する。コミュニケーションのツール方法、現状把握後に、正しいスケジュールと体制とコミュニケーションラインを作る。あとは、スケジュールのマイルストーンごとに自分の考えがただしいかをかくにんするか。

スケジュールは、完成までのイメージが持てない限り終わらない。とことんイメージできるまで引き直す。

スケジュールは、お客様を巻き込んだものを作成する。お客様の受け入れ、あと、運用のスタート。運用前に役員チェックがあるのか？運用者へのレクチャーは、どうするのか？データ移行はあるのか、とことん詰めていく。ここでまた、適当にやると結局同じ事となる。

スケジュールがゴールの道筋である。そこが完全にイメージでき、メンバーに共有する。もちろんあお客様にも。お客様からの質問も事前に想定する。

一番難しいのは、品質工程である。難しいが一番大切であり、ここでお客様の信頼と満足度が変わる。

品質工程については、別のブログにかいてるので、そちらを参照して欲しい。