> > > ) どーせ仕様なんてころころ変わるんだから提示された期間にお互い
> > > ) 合意した機能を開発することにはコミットしましょう。そのかわり、
> > > ) 前倒しで開発できたら前倒しした期間分の報奨金をください。
> > > ) あなたがたの案件ははやければはやいほど価値を増すんですよね。
> > > ) もちろん、開発が遅延すればその遅れた期間分の罰金をこちらが
> > > ) 払います。ええ、私の胃なり内臓を売ったりしてでも必ず払います。
> >
> > それは、計画開始時点では必要な機能やそれを実装する工数が実
> > 用的な精度で予測できない、あるいはプロジェクトの性格として
> > 予測すべきではない場合ですから、多段階に分けて、1段階目の成
> > 果を見て2段階目以降の仕様や期間を決めましょう、ということに
> > なるのではないでしょうか。
> >
>
> ですね。
>
> 締め切り後に、欲しいものが決まったらもちろんやりますよー、ただし
> 別料金で、とコミットする必要はあるかと思います。(「ここから先は別
> 料金になります」という、ちょっと前のKDDIのコマーシャルみたいです
> が(^^;。)
> # 最初に欲しい「価値(他社に先駆けたい)」と次に欲しい「価値(機能が
> # 欲しい)」は違うでしょ、ということで説得することになるかと。
そうしてもよいですが、かならずしも1段階目と2段階目の間に販
売が挟まらなくてもよいんではないでしょうか。期間の半分で原
型をつくり、それができたら最終的にどの程度のレベルの製品を
どれくらい期間で作るをかを再度ソフト開発&商品戦略の点から関
係者で決めることになるでしょう。「ドラ太郎」のように革新的
なものであれば、さらにその前に基礎研究の段階を設けるのが望
ましいと思います(状況がゆるせばですが)。
ただ、これはプロジェクトの目的がやたら斬新で、事前に最終的
な製品が予測できない場合には有効と思いますが、開発期間を短
縮するためにも有効かはわかりません。
> 締め切り後に、欲しいものが決まったらもちろんやりますよー、ただし
これだと予想外の変更に対して柔軟に対処するニュアンスになる
気がしますが(それも必要ではありますが）、私が述べたかったの
はどちらかといえば1段階で予測できないのであれば、2段階に分
けて予測できるように変えたうえで進めましょう、という方です。
--
Michitaro Horiuchi / Access Co.,Ltd.
horiuchi@....jp / horiuti@....jp