アカウント名:
パスワード:
ソフトウェアに限らないけど、たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、それは客も理解してるのよね。事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
背広作ってくれと言われて、袖のない背広を平気でつくってくるのがエンジニア。「最短で作りました涼しいでしょ」色がどうのボタンがどうのに終始して、「袖のある背広がほしいんだ」と重要な仕様を示せないのが発注者。
要件定義担当者を間におけばいいのに
その人が、要件の優先度や、どんなユースケースを想定してるのかを把握していれば良いけどね。自分達が何をしたいのかもよく分からないからとりあえず手当たり次第に要件盛り込んで見積もりさせ、納期と予算をベースに個々の機能を取捨選択するから、ちぐはぐで作ったは良いが使えないものが往々にしてできてしまう。
要件定義後に要件が変わらないという前提ならこれでもいいんじゃないかな＃みんなが困ってるのはそういうことでしょ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
既製品と受注品 (スコア:5, すばらしい洞察)
ソフトウェアに限らないけど、
たとえば「服」なら既製服と注文服で客のほうに「も」知識が要るのは圧倒的に注文服なんですが、
それは客も理解してるのよね。
事前に金を払ったからといって、早くできるわけでも、注文になかったものまで作ってくれるわけではないので、
作ってほしいものがあれば、きっちり注文内容にそれを入れることが必要。
でもソフトウェアになると、なぜかそれが分からなくなってしまう。
既製品(パッケージソフト)で間に合わないから注文品にしているはずなのに、発注側が受注側に何でもかんでも「察する」ことを求めてちゃいけないよね。
形として見えるものじゃないから、分割受注みたいな形(アジャイル)にして「客の」リスク(と受注側のリスク)を下げようとしているのに、
それを拒否されたら、どっちも不幸になるだけなのは散々説明されていると思うのです。
Re: (スコア:-1)
背広作ってくれと言われて、袖のない背広を平気でつくってくるのがエンジニア。
「最短で作りました涼しいでしょ」
色がどうのボタンがどうのに終始して、「袖のある背広がほしいんだ」と重要な仕様を示せないのが発注者。
Re: (スコア:0)
要件定義担当者を間におけばいいのに
Re: (スコア:0)
要件定義担当者を間におけばいいのに
その人が、要件の優先度や、どんなユースケースを想定してるのかを把握していれば良いけどね。
自分達が何をしたいのかもよく分からないからとりあえず手当たり次第に要件盛り込んで見積もりさせ、
納期と予算をベースに個々の機能を取捨選択するから、ちぐはぐで作ったは良いが使えないものが往々にしてできてしまう。
Re:既製品と受注品 (スコア:2)
要件定義後に要件が変わらないという前提ならこれでもいいんじゃないかな
＃みんなが困ってるのはそういうことでしょ