アカウント名:
パスワード:
＞また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを＞優先させた方がいい、と理解できているマネジメントが必要であるとのこと。
理解出来ても実行出来るとは限らん、というかムリだorz
納期破る判断って、マネジメントがそれを下すのはほんと難しいよね。一度認めると、下々がキツい時すぐそれを求めるようになるだろうし。一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。それだとなんだか別の問題も起きそうですし。
もともとの納期だって、それほど確かな下地に基づいて切ってる訳でもないでしょうから。優等生理論でいくと、最初にマネジメントが下した「リソースの見極め＋納期の切り」に失敗の原因がありましたごめんなさい、っていう反省文とセットで初めて成立しそう。→納期延長
>下々がキツい時すぐそれを求めるようになるだろうし。
なーに、キツくならないよう、最初から十分な余裕を持った納期を設定しておけば良いだけのことですよ。#やれるんならやっている！
ソフトウェアではないですが、設計レビューを十分やるために社内委託作業（社内のCAD設計担当部門への設計委託）で通常より５割長い納期（と費用）を設定したことがあります。（担当部門要求４週間に対して６週間）
結果、どうなったかというと、その分以上に前半でサボられて余計品質が悪くなりました。いつまでたっても初版のレビュー用データが出てこない。
問い詰めると、こっちから金をとっておきながら、他の部門からも金を取って、違うことをしていたらしい。結果、数百万の金を取られて、さらに外部での再設計と納期遅延で億に近い損失がでました。
社外なら訴訟ものですが、社内だからどうにもならん。
社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。 どちらかというと、「設計・レビューが～が理由でできない」というクレームが上がってきたときの対応のほうが重要なはず（それで遅れても許容する余裕もね）＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
> 社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。ダメダメだからレビューをしっかりやるスケジュールを立てたら余計にダメダメだった、ってことです。
> ＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。モノ作りだと試作ラインの確保もしなきゃいけないですし。
＞うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。 他の部署にも影響してそうだから上にあげるべきですね。＃社内にやらせるくらいなら、社外に出したほうが安くて早い！（とかｗ
＞社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。 何言ってるんですか、隠せれないなら脳内予定を作っておけばいいんですよ（苦笑） 試作ラインの確保は・・・どうしようもないですね。自分の予定に別の予定を1週間程無理やり突っ込んでずらすとかくらいしか思いつきません＞＜
もちろん上にあげましたとも。だけど、役員間の力関係で握りつぶされました。ま、こんなんだからいつまでたってもヘタレなんですけどね。
> 社外に出したほうが安くて早い！（とかｗ
どうせ２～３人での設計作業なので、早い安いよりも品質なんです。組み込み機器なんですが、後工程でソフト屋さんが安心して実機デバッグに入れるかどうか、それが最優先なんですよ。
百人以上のソフト屋さんがターゲットの動作に不安を持ちながらデバッグするのはあまりに非効率ですからね。（精神衛生上もよくないし）不安定なターゲットでソフトデバッグなんてやってたら２週間どころではなく日程オーバーするか、ソフト含めたトータル品質が大幅低下してしまいます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
言うは易く行なうは難し (スコア:0)
＞また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを
＞優先させた方がいい、と理解できているマネジメントが必要であるとのこと。
理解出来ても実行出来るとは限らん、というかムリだorz
Re: (スコア:0)
納期破る判断って、マネジメントがそれを下すのはほんと難しいよね。
一度認めると、下々がキツい時すぐそれを求めるようになるだろうし。
一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
それだとなんだか別の問題も起きそうですし。
もともとの納期だって、それほど確かな下地に基づいて切ってる訳でもないでしょうから。
優等生理論でいくと、最初にマネジメントが下した「リソースの見極め＋納期の切り」に失敗の原因がありましたごめんなさい、っていう反省文とセットで初めて成立しそう。→納期延長
Re: (スコア:0)
>下々がキツい時すぐそれを求めるようになるだろうし。
なーに、キツくならないよう、最初から十分な余裕を持った納期を設定しておけば良いだけのことですよ。
#やれるんならやっている！
Re: (スコア:2, 参考になる)
ソフトウェアではないですが、設計レビューを十分やるために社内委託作業（社内の
CAD設計担当部門への設計委託）で通常より５割長い納期（と費用）を設定した
ことがあります。（担当部門要求４週間に対して６週間）
結果、どうなったかというと、その分以上に前半でサボられて余計品質が悪くなりました。
いつまでたっても初版のレビュー用データが出てこない。
問い詰めると、こっちから金をとっておきながら、他の部門からも金を取って、違うことを
していたらしい。結果、数百万の金を取られて、さらに外部での再設計と納期遅延で
億に近い損失がでました。
社外なら訴訟ものですが、社内だからどうにもならん。
Re: (スコア:2)
社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
どちらかというと、「設計・レビューが～が理由でできない」というクレームが上がってきたときの対応のほうが重要なはず（それで遅れても許容する余裕もね）
＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
Re:言うは易く行なうは難し (スコア:1)
> 社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
ダメダメだからレビューをしっかりやるスケジュールを立てたら余計にダメダメだった、ってことです。
> ＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
モノ作りだと試作ラインの確保もしなきゃいけないですし。
Re:言うは易く行なうは難し (スコア:2)
＞うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
他の部署にも影響してそうだから上にあげるべきですね。
＃社内にやらせるくらいなら、社外に出したほうが安くて早い！（とかｗ
＞社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
何言ってるんですか、隠せれないなら脳内予定を作っておけばいいんですよ（苦笑）
試作ラインの確保は・・・どうしようもないですね。自分の予定に別の予定を1週間程無理やり突っ込んでずらすとかくらいしか思いつきません＞＜
Re: (スコア:0)
もちろん上にあげましたとも。だけど、役員間の力関係で握りつぶされました。
ま、こんなんだからいつまでたってもヘタレなんですけどね。
> 社外に出したほうが安くて早い！（とかｗ
どうせ２～３人での設計作業なので、早い安いよりも品質なんです。
組み込み機器なんですが、後工程でソフト屋さんが安心して実機デバッグに
入れるかどうか、それが最優先なんですよ。
百人以上のソフト屋さんがターゲットの動作に不安を持ちながらデバッグするのは
あまりに非効率ですからね。（精神衛生上もよくないし）
不安定なターゲットでソフトデバッグなんてやってたら２週間どころではなく日程
オーバーするか、ソフト含めたトータル品質が大幅低下してしまいます。