|
|
- ★ 品質管理編 ★
ユーザー側でも品質を向上出来る。
ユーザーは、リハーサル試験になって初めて品質の程度がわかります。
この段階で品質が悪すぎるとわかったら大変です。
品質向上に取り組んでも、本番後の影響が心配になります。
ユーザー側も事前にわかっているはずです。
設計工程完了を迎えても、
・残っていた未確定項目の数、
確定したことにより仕様変更となった影響度
・経営者や役員の突然の要求により
急遽入れなければならなくなった仕様変更
・懸案事項が急に現実化して取り込まざるを得なくなった対応策
これ以外にも
レビュー時における指摘内容の程度によっても大体想像はつきます。
これを案外、「後はよろしく」と放っておくと当然の結果となります
やはり品質の具合は、大規模でかつ社運をかけたプロジェクトであれば
あるほど、ユーザー側も大変気になります。
そんな時は、リハーサル試験でなくても、
運用試験や総合試験、もっと前工程でのシステム試験などに
強制的に参加させてもらう手もあります。
ユーザー側の突然の参加は、開発側はとても嫌がりますが、
無理にでも押し通すと品質が改善されていきます。
故障対応や仕様変更対応の優先順位が、間違っている場合もありますので、
軌道修正も早く行えます。
なんと言っても、ユーザー側の真剣な対応にプロジェクト全体が感化
されていくことが絶大な効果を起こします。
その場合は、当然開発場所に出向く必要がありますが、
手間を掛けても行く必要があると考えます。
以前、そのような熱心なユーザーに遭遇した時、
ユーザーの熱い思いは伝染するのだと痛感しました。
品質面でも問題点が多く、協力会社においても多数の問題を
かかえたプロジェクトでしたが、予定通り本番を迎える
ことができました。
ユーザー側の思いは、
開発側にも必ず伝染します。
ユーザーの行動が成功への呼び水となります。
ユーザー側でも品質向上に貢献することが可能なのです。
少々うるさかったのですが、効果もちゃんと表れていました。
非常に参考になったプロジェクトでした。
|
