アカウント名:
パスワード:
ソフトウェアに限らないけど、たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、それは客も理解してるのよね。事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
>たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、>それは客も理解してるのよね。
「王様の仕立て屋」読むとそうでもなさそう。
「こちら、馬鹿には見えないシステムでございます」
#必要のないシステムを作らずにすませられるのならば、十分優秀なのかもしれない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
既製品と受注品 (スコア:5, すばらしい洞察)
ソフトウェアに限らないけど、
たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、
それは客も理解してるのよね。
事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、
作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、
それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
Re: (スコア:0)
>たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、
>それは客も理解してるのよね。
「王様の仕立て屋」読むとそうでもなさそう。
Re:既製品と受注品 (スコア:1)
「こちら、馬鹿には見えないシステムでございます」
#必要のないシステムを作らずにすませられるのならば、十分優秀なのかもしれない
#存在自体がホラー