ええ~い!愚痴のおまけだい! その2
調子に乗ってもう一愚痴。
あのね、君たち(わが社のシステム要員)、開発依頼が来たらちゃんと話を聞きなさいよ。
最初の要件認識がすごく甘いよ。
ちゃんと話し聞いてユーザーが何を求めてるかをしっかり認識して要件定義を文書でまとめてお互いに認識を共通化しておかないと後が大変だよ。
要件定義が甘いか ら、できたシステムをユーザーが使ってくれないとか、使いにくいってクレームが来たり、思ってたのと違うって声が出たりするのだよ。
だから君たちも不満に思うだろうし、お互いに不信感を抱き合ってしまう。
確かにみんなバックログをいっぱい抱えて時間も無くて大変だと思うよ。
ユーザー自身も自分が何を求めてるのかわかってないことも多いしね。
だけど、いきなり「できません」「ダメです」は言っちゃダメだ。
相手も人間なんだから言いようを考えて話そうよ。
たとえだめだと思っても、その場は「ちょっと考えて見ます」と引き下がって、あとで「再考しましたが、どうも難しいですね、代替案を考えましょう」って答えれば相手も話し合いに乗ってきてくれるよ。
とにかく、ちゃんと目的と目標をはっきりさせてシステム化しようよ。
あとで調整するこっちの身にもなってくれよ!
あのね、君たち(わが社のシステム要員)、開発依頼が来たらちゃんと話を聞きなさいよ。
最初の要件認識がすごく甘いよ。
ちゃんと話し聞いてユーザーが何を求めてるかをしっかり認識して要件定義を文書でまとめてお互いに認識を共通化しておかないと後が大変だよ。
要件定義が甘いか ら、できたシステムをユーザーが使ってくれないとか、使いにくいってクレームが来たり、思ってたのと違うって声が出たりするのだよ。
だから君たちも不満に思うだろうし、お互いに不信感を抱き合ってしまう。
確かにみんなバックログをいっぱい抱えて時間も無くて大変だと思うよ。
ユーザー自身も自分が何を求めてるのかわかってないことも多いしね。
だけど、いきなり「できません」「ダメです」は言っちゃダメだ。
相手も人間なんだから言いようを考えて話そうよ。
たとえだめだと思っても、その場は「ちょっと考えて見ます」と引き下がって、あとで「再考しましたが、どうも難しいですね、代替案を考えましょう」って答えれば相手も話し合いに乗ってきてくれるよ。
とにかく、ちゃんと目的と目標をはっきりさせてシステム化しようよ。
あとで調整するこっちの身にもなってくれよ!