アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
納期が厳しいのもそうですが、 (スコア:4, 参考になる)
こちらから仕様をあらかじめ提示しておいても、
我々部品屋が開発してるときは前製品の検証や量産で手一杯、
こちらの開発の後半になって、あれ変えろこれ追加してくれって
要求が来始める訳で。
なのに当然納期は変わらない(営業が納期交渉しようとも
しないのも大きな問題なのだが)
半導体は、そう簡単に修正して製造できないってのをあまり理解頂けて
ないようで厳しいです。
追加・変更に対する第一声 (スコア:2, すばらしい洞察)
これをまず言うべきです。
そして
「時間と料金を追加いただけるならば検討いたします」
作った分は使わなくてもタダではない。
これがいえるようになった初めて一人前です。
Re:追加・変更に対する第一声 (スコア:0, フレームのもと)
相手との立場(顧客、上司)や相手との関係の強弱や要件の内容にもよるでしょうが、まず「検討させて下さい」と言ってから、対応策や代替案を提示するようにします。
結果的に「できない」という状況も多いですが、顧客相手なら印象が違うと思います。
Re:追加・変更に対する第一声 (スコア:1)
# 客は自分のケツは拭かないから…
可能な物は「可能だがある程度工程が増えるので工数がかかる」と言うことで出来るだけ工数見積りの提出まで・最悪でも着手した時点で客を納得させられる様に、事前の客との打ち合わせを密にできるかどうかですわな。
逆にいえば、客と打ち合わせながらその場で頭の中でおおまかな設計をするように頭を廻しておいて、なるべく早く全体設計を済ませてまず技術的にやばいところをピックアップして対処とスケジュール配分を決めるのが理想なんですがねぇ(;´Д`)それが出来るようになったのは最近です(;´Д`)
後は途中で「本当にこれでいいですね」と何度か聞いて、客から返事を貰えると理想(だけど、そこまでやってくれる客は殆どいない)
まぁ、これがうまくいく仕事だとデバッグのイリーガルケースもポイントを押さえられるので二重にらくなんですが、後付けの仕様変更がぐちゃぐちゃだととうぜんぐだぐだに…(-_-;