今回は後から要望がでてくる理由を記載します。この理由を理解しておくことで後半に何か発生することは仕方なく、それを受け入れる準備や体制ができると思います。
・顧客が触ってから初めてイメージがついた
→私も20年ぐらいシステムを担当しておりますが、やはり私でも構築した後に
ここは直さないと問題だなというところはでてきます。 顧客はシステム専門のプロ
でもないとは思いますので、ある程度は許容すべきでないかと思います。
・要件定義や設計の時に考慮が漏れていた。
→本当はあってはいけないのですが、考慮漏れはあると思います。問題は考慮漏れを
全くないと思っていることや、考慮漏れがあった時に認めないことです。ここは素直
に認めてその対応を行った方がよっぽど信頼されると思います。
・期間がたったので顧客のビジネスロジックが変わった。事情が変わった。
→システムのテストアップまでは数ヶ月が普通にかかります。その間に顧客の環境は
当然変わっていきます。全く変わっていないとうことは外部環境内部環境に
適応していないということだと思います。普通の企業の場合は変わります。
なので、少しは変わる前提で考えておいた方が良いです。
また中にはテストアップ後の修正対応ということで工数とスケジュールを組んでいる場合もあるかと思いますので、その場合はその工数とスケジュールを使えば良いと思いますが、それすら超える場合結局は同じことが言えるのではと思います。
上記顧客の事情であったり開発側の考慮漏れであったり いろいろ場合はあるかと思いますが、後半には必ずバッファを使わないといけない時が来るという前提の元で前半の対応を考えていく必要があると思います。
