プロセスについて教える

ソフトウェアプロジェクトのプロセスが本当に効果を発揮するためには、すべてのステークホルダーとのあいだに共通理解がなくてはなりません。共通理解を確実に得るための方法のひとつとして、私はプロジェクトにかかわるステークホルダー全員にプロセスを正しく教えるようにしています。ステークホルダーには、プロジェクトのスポンサー、数名の重要と思われるユーザー、プロジェクト・マネジャー、開発者、デザイナー、QA 専門家らが含まれます。彼らを同じクラスに集めて、一緒にプロセスについて講義をするのです。

私たちはプロジェクトの途中で、プロセスに関する講義をクライアントに受けるよう求めます。なぜだと思いますか？

どうやってチームを効率よく動かしているか、スポンサーにもきちんと理解してほしいためです。私たちは毎週、見積り、計画し、発表するというアジャイルプロセスを導入して、非現実的な期待と戦っています。

スポンサーは見積りのプラクティスについて学び、見積りの扱い方を知ります（見積りは固定価格ではないのです）。そして、見積りに基づいてスコープを選びビジネス価値と照らし合わせる、というシンプルな計画テクニックについて学びます。彼らを積極的に毎週の「発表会」に参加させることで、早期に誤解が判明するようになります。

かつて私がプロセスについて教えているとき、見積りに関する説明責任のルールについて説明するため、クラスに出席した2 人の開発者にこう言いました。「テッド、ケリー、あなた方開発者はたとえ見積りを間違っても会社から罰せられることはありません」

それから出席しているプロジェクト・マネジャーに向かって、「リサ、もし彼らが見積りを間違っても、開発者に無理強いしたり罰したりすべきでないことを理解していますよね」と言いました。それから部屋にいる資金を提供してくれるクライアントに向かって、「さて、ジェン、もし見積りをオーバーしたら、もっとお金を出すことを理解していますよね？」と問いかけました。

もちろん、この時点では、2 人の開発者は何だかごまかされているように感じ、クライアントはプロジェクトをキャンセルしようかと考えています。そこで私は、見積りに関する説明責任の最後の「ルール」について説明します。「ケリー、テッド、あなた方にやってほしいのは、見積りが間違いそうだと思ったら、すぐにはっきりとプロジェクト・マネジャーに伝えることです。リサ、あなたはプロジェクト・マネジャーとして、彼らとタスクについて議論してください。見積りのあと、タスクのスコープを変えていないことを確かめるのです。もし実際に見積りが間違っていれば、クライアントに電話して、どう対処すべきか尋ねなければなりません。」

最後に私はクライアントに向かって、「ジェン、これが、この授業からあなたが学ぶことです。見積りをする環境が信頼でき、自分の見積りを満たすことを楽しむ熱心なチームメンバーがいれば、積極的に見積もれば見積もるほど短時間で仕事ができるようになります。しかし、ときには間違いがあることも受け入れなければなりません。もし間違えたときには、お金を使い果たしてしまう前にあなたに知らせます。」

プロセスについて教えることは、プロジェクト強化に非常に有効な手段です。