クレームは、お手軽なチャンス。
顧客にシステムを納品するとき、多少なりともクレームが発生します。
開発手法にもよりますが、ウォーターフォールで開発した場合は、顧客が開発中に
システムを使用することはあまりないためクレームは出ることでしょう。
例えば、設計書に書かれていないことでの齟齬や、
実際に使用してみてからの使い勝手や動作など、様々です。
顧客に熟練のシステム屋が居れば、こういったことは少ないのかも知れませんが
そうではないケースが多々あります。
要件に無いからできないとか、システム全体の統一を考えて対応が難しいことがあると思います。
さらに、開発工数に関わる場合は、単純に対応することは難しいことです。
でも、このクレームこそが、私は大事だと思います。
顧客と要件を固めて、仕様書と設計書を作成し、いざ開発を行いテストまでやります。
設計書に書かれていない細かい部分での齟齬は、少なからず出てきます。
こうなればいいのになぁ〜
ここが、こうなっているほうが使い易いなぁ〜
などなどです。
開発中には気づかなかったことや、顧客担当者も含めて決めた仕様が
実際の現場の人には、使いにくいということは貴重な意見です。
全然検討違いという場合は除いて、大抵の場合は聞いているとなるほどと思わされます。
開発中には、気づかなかった仕組みが見えてきます。
むしろ、この意見をうまく取り入れていければ、より良い製品ができあがります。
顧客のクレームをはじくだけでなく、より良い形で実現できる仕組みがほしいと思う今日このごろです。
ちなみに、苦情を表す『[url=http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AC%E3%83%BC%E3%83%A0]クレーム[/url]』は、和製英語のようです。
