ここ1年くらい行っていなかったが久しぶりに見積もりを出してくれと言われた。
行っていなかったのは客先常駐勤務であり見積もる様な規模の開発が無かった為。
久しぶりだから、ちと戸惑う。
見積もり根拠 = スケジュール表
適当に数字を出すことはできる。経験から弾き出した「適当」なのでいい加減ではない。
工程単位に機能単位に細かく数字を出せもする。
昔そうやって出した見積書に対してお客さんから「根拠は?」と訊かれたことがあった。
まだ見積もりを出すなんて経験を殆どしていなかった頃のことだ。
多いに戸惑い「根拠はといわれましても…経験から大体こんなところかと…」そんな返事をした。
(実はその時の見積もりはユースケースポイント法を用いたりしてみた。お客さんが理解出来るとも思えなかったので根拠としては提示しなかったが)
経験が乏しいと分かってくれたのか「スケジュール表を出してくれれば良いですよ」と言われた。
以来、見積もり根拠としてスケジュール表を添付している。
スケジュール根拠 = ロバストネス図
大概は見積書とスケジュール表、これで通して来た。
だが自分自身でなぜスケジュール表が見積もりの根拠になるのか今一納得できていない。
仮に自分がソフト開発をまったく知らない客の立場だとしたらどうだろう。
ある工程で何人日・ある画面で何人日といわれても理解し難いのではないだろうか。
そこで、お客さんによってではあるがスケジュールの根拠としてロバストネス図を添付する様にしている。
必要に応じてロバストネス図から「この画面はこういった機能が必要なのでこの位かかりますよ」と説明を行う。
仕事をとる為か儲ける為か
同じソフトウェアの見積もりでも見積もりする側の立場によっては、内容が大きく変わることを頭に入れておく。
例えば、社内で完結する仕事の見積もりと社外に出す見積もりでは、社外に出す見積もりの方が高くなる。
客先常駐で社内案件の見積もりを作って来た人が、同じ感覚で見積もりすると痛い目にあったりする。
だいたい他所より安くなるので仕事がとれてしまう。その結果大赤字になったりする。
営業経費などを率で抜いたり利益を何%か出すと、会社のルールで決めてあれば良い。
だが、零細企業だと営業担当の感覚だけだったりする。
零細企業ならば会社全体の販管費も把握しやすい。その場合は踏まえて見積もりをするべきだ。
リスクも見なくてはならない。あまり過大に見るとおかしな見積もりになる。
おかしくない程度に少しは余裕を持たせた方が良い。
お客さんに見せるスケジュールには載せられないが調整日とでも考えて乗せておく。
お客さん都合で遅れが出ることも考えれば余裕を見ておく必要がある。
スケジュールがタイトになれば残業代で食い潰す可能性もある。
さらに請負なのだから瑕疵担保責任が発生する。
本当はどうであれ、これを盾されると只働きせざる得ない場合がある。
ひどい話だと「バグだ不具合だ」と言い続けられ１年近くエンジニアが拘束されたときもあった。
人が作るものなので、ことソフトウェアについては完璧というのは難しい。
仕事が終わったその時は感謝されても、しばらく後には「あの仕事のバグがね…」なんて云われる場合もある。
その分も乗せておきたい。
ある会社の社長からは「ぎりぎりの数字から1.5倍になるよう上乗せしておく」などと聞いたこともある。
乗せ過ぎではと思うがどうだろうか。
出精値引き
取引先にも信頼されており見積もりも適正だ。そんなときでも値引き迫られる場合はよくある。
値引きには色々な理由をつけてくるもので、時には立場をわすれて感心したりもする。
そんな中で一番信用してはいけないことは「次の案件では…」というやつである。
まず次は無い。有ったとしても同じ様な赤字案件になるものだ。
次の案件があるというから半信半疑で値引きしてみたことがある。
結果、次の案件があるといっていたその時期には、相手先が実質倒産しており次の話など無かった。
あとあとその時の担当者に聞いてみれば値引きをせまったその時には倒産することを知っていたという。
値引き交渉での「嘘」は言った側からすると「方便」ということなのだろう。
「出精値引き」とかつけようが、別段感謝されるものではない。
値引きはしないのが正解だ。
0 件のコメント:
コメントを投稿