プロジェクトを炎上案件にしないために

訳あって炎上案件の火消しの話。⑦

最後の炎上案件の話。
「炎上案件にしない」ために何をするかという点を私なりにまとめてみた。
普通のプロジェクトマネジメントのお作法はもちろん守った上で。

まとめてみたらすごく普通になったのは否めない。
その普通ができなかったから炎上したという教訓。

という前提で。

プロジェクトを炎上させないための10個の大事な事

　①要件定義はバディ制度
　　→必ず身内に共有できる人をつくっておく
　　→2次送りはできるだけやめましょう。
　　→口頭握りは【絶対に】やめましょう（基本）

　②設計書を後回しにしない
　　→後続が死ぬ

　③テスト期間はバッファではない
　　→単体と結合が同時になってるスケジュール見て白目になった。

④報告・連絡・相談　はこまめにする
　　→お客様に対しても、上司に対しても、社内に対しても。
　　　「ダマ」が後から必ず響く
　　→仕様・スケジュール・不慮の技術的困難、人的問題、色々ね。
　　→議事録・エビデンス・ドキュメント。証拠は全て残す

⑤情報の拡散をしましょう
　　→チームメンバーに必要な情報を伝えましょう。
　　　いいことも悪い事も共有すべき

　⑥プロジェクトの開始が遅れたらエンドも遅れる
　　→これをクライアントに理解させることが大事
　　→無理は聞いて良いけど、無理を言ってる事は理解させよう

　⑦フェーズ毎に簡単でもいいので振り返りをする
　　WBSを聖典にしない
　　→実態を伴わないWBSは夢日記。
　　→なんとなく進む、なんとなくのアラートを上げているのが一番やばい

　⑧スペシャリストとジェネラリストのペアで動く
　　→システムでもいいし、技術でもいい。
　　　プロジェクトの実行推進できる人とチームを推進する人を分けて
　　　考えよう
　　→ジェネラリストは兼務でも大丈夫だと思う
　　　（基本脳みそがパラレルだから）

　⑨自分ひとりでは何もできない認識を全員が持つ。
　　→「オレサマ」もいらないし「デキナイオレ」タイプもいらない。
　　→知識不足は恥ではない。Ask much, know much

　⑩要件を決める人も、開発する人も。最終的なエンドユーザーの視点を
　　忘れずに。
　　→これをしないと、リリース後「そうじゃない」事案が多くなります…

かな。まあ全部できてたら炎上案件の要素は少なくなると思うよｗ
あとおまけとして、一次請けの会社の上層部が体制を引く時には、

　　炎上しそうなので、体力のある方から上位を集めた

という対策が取られてました。（一次請け社員から聞いたｗ）
体力とメンタルに強いメンバーがいることは大事だよね。まあ、組織としてそういうやり方もあることは理解する。

　そんな都合の良いのが何人もいるかっ！ｗｗｗｗｗｗｗｗｗｗ

あ、そうだな。次は、炎上ではなく、サービス業にサービスを提供することについて書いて見ようと思う。