プロジェクトマネジメント現場マニュアル　のその2です。そうそう、これは日経SYSTEMSの連載がベースです。

で、2章10節から。

変更管理　ですが、変更管理ルールを守らない人、いますか。その人、ずっと前からそういう仕事していませんか。たとえば、設計フェースではどうでしたか。開発標準プロセスを遵守していました？そうなのです。変更管理プロセスばかりではない。守らない人は、最初からルールを守らない。なら、守らせるためにはどうしますか。ルールを守れ！と大声を出し続けますか。

ルールを守らないと、仕事ができないようにする。

これが一番です。整合性の取れたワークフローを定義するのは簡単ではないですが、準備をすることで何倍も楽になります。では、お客様からの変更依頼はどうしましょう。それぞれの担当に、バラバラと変更を依頼してくるのです。さぁ、どうしましょうか。

窓口を置く。

10人程度の小規模なプロジェクトなら、もう、受付はプロジェクトマネージャ自身でもいい。フォーカルポイントは、疎結合で。受付後は、お客様との協議です。

変更管理ができなくて、現場が混乱するのは、ルールと構成管理ができていないから、です。
ところで、進捗はどうだって？30%って、何？定性的な報告は、いりませんよ。

消化件数と母数と報告させる。

大体、定性的に報告するのは、あやしい。いや、もちろん定量的に管理している上で、あわせて30%というならまだよいですが。でも、消化件数と完了見通しを教えてくれれば、十分なのですけどね。
ああ、テストフェーズも作業ステップがあるので、ステップごとに%を設けて、計算してもいいけど、そこまでする？

やっぱり、消化件数とNG件数と完了見通しでお願いします。

テストの品質管理です。
そういえば、UTろくにやっていないのにSTはじめちゃった人知っています...。品質は、テストフェーズだけがんばっても意味ないです。設計フェーズもね。

さぁ、完了報告らしいです。ポイントは抑えていますね。

開発生産性
教訓

さて、開発生産性は、当初計画と実績と比較するよう書いてあります。なかなかよい。だけど、比較するときに、もうひとつ考慮する必要があるのですけど。

その3に続く...か。