プロジェクトマネジメント 現場マニュアル のその2です。そうそう、これは日経SYSTEMSの連載がベースです。
で、2章10節から。
変更管理 ですが、変更管理ルールを守らない人、いますか。その人、ずっと前からそういう仕事していませんか。たとえば、設計フェースではどうでしたか。開発標準プロセスを遵守していました?そうなのです。変更管理プロセスばかりではない。守らない人は、最初からルールを守らない。なら、守らせるためにはどうしますか。ルールを守れ!と大声を出し続けますか。
ルールを守らないと、仕事ができないようにする。
これが一番です。整合性の取れたワークフローを定義するのは簡単ではないですが、準備をすることで何倍も楽になります。では、お客様からの変更依頼はどうしましょう。それぞれの担当に、バラバラと変更を依頼してくるのです。さぁ、どうしましょうか。
窓口を置く。
10人程度の小規模なプロジェクトなら、もう、受付はプロジェクトマネージャ自身でもいい。フォーカルポイントは、疎結合で。受付後は、お客様との協議です。
変更管理ができなくて、現場が混乱するのは、ルールと構成管理ができていないから、です。
ところで、進捗はどうだって?30%って、何?定性的な報告は、いりませんよ。
消化件数と母数と報告させる。
大体、定性的に報告するのは、あやしい。いや、もちろん定量的に管理している上で、あわせて30%というならまだよいですが。でも、消化件数と完了見通しを教えてくれれば、十分なのですけどね。
ああ、テストフェーズも作業ステップがあるので、ステップごとに%を設けて、計算してもいいけど、そこまでする?
やっぱり、消化件数とNG件数と完了見通しでお願いします。
テストの品質管理です。
そういえば、UTろくにやっていないのにSTはじめちゃった人知っています...。品質は、テストフェーズだけがんばっても意味ないです。設計フェーズもね。
さぁ、完了報告らしいです。ポイントは抑えていますね。
開発生産性
教訓
さて、開発生産性は、当初計画と実績と比較するよう書いてあります。なかなかよい。だけど、比較するときに、もうひとつ考慮する必要があるのですけど。
その3に続く...か。