続きを書いてみようかと。。。
「ネゴる」ってなんでしょう。
- 時間を短縮
- 手戻りを防ぐ
- 手を抜く
- 後まわし
開発コストって、私の場合だいたいこういう風に考えてます。
- 要件定義 １０％
- 基本設計 ２０％
- 詳細、PG、単体テスト ４０％
- 結合テスト ２０％
- 総合テスト １０％
ひどい、という話もあるかもしれませんね。 そののち、仕様変更はいつまで発生するでしょう。
これも、経験上、総合テストまで！？ 総合テストで発生する仕様変更って一番厄介です。どうでも、いいことは捨て去られますが、このタイミングで見つかるのは、大きな問題、インパクトのある問題だからです。企業側も理解していて、初期開発を抑え、仕様変更に予算をとっていたり、総合テストから半年後にリリースするといった方策をとっているところも、あります。
ネゴるは、この総合テストでの仕様変更に備えての方策です。
たいした仕様でない事が重要であったり、総合テストで、もめて余計な時間とコストを掛けない事が肝心だと思います。
信頼関係はどうやって、築くのか。
ネゴるには、もっとも肝心な事ですよね。PMの懐の深さです。深さを出すのに一番簡単な方法は、「NO」と言わない。危険ですね。
もし、その機能が必要ならば、５０００万円かかります。やり方を変えれば５００万でできます。その場合は、これができて、これができない。運用回避であれば、画面に注意書きを入れるだけなので、無償でやります。
もちろん、こんなにすんなり行くとは限りませんけど、少なくとも、案を出すべきだし、できる、できないだけを言うのが仕事だとしたら、その仕事の存在とはなんでしょう。
（他の項目は、また時間があるときに。。。）