アカウント名:
パスワード:
＞また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを＞優先させた方がいい、と理解できているマネジメントが必要であるとのこと。
理解出来ても実行出来るとは限らん、というかムリだorz
偉い人たち（中間管理職ではなく、トップマネジメントの次の連中）は目の前のキャッシュフローしか興味ないですからね。
ウチの場合、ロジックやエラー処理は一切抜きのデモUIのみの営業プレゼン用ソフトウェアを見て、「なんでこれが売れないんだ！このまま売れ！」とか怒り出す人たちですから理解なんて無理なんですよ。（指示する際も「とにかく顧客デモをやれ、その部分だけ作れ」という指示だったのだが、本人が忘れてる。）
理解している上級マネジメント職も火の粉が降り掛かるのを嫌がって「お前ら、上からそのまま売れって言われてるんだから、言う通りにすればいいんだよ」って言い出す始末ですしね。
納期破る判断って、マネジメントがそれを下すのはほんと難しいよね。一度認めると、下々がキツい時すぐそれを求めるようになるだろうし。一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。それだとなんだか別の問題も起きそうですし。
もともとの納期だって、それほど確かな下地に基づいて切ってる訳でもないでしょうから。優等生理論でいくと、最初にマネジメントが下した「リソースの見極め＋納期の切り」に失敗の原因がありましたごめんなさい、っていう反省文とセットで初めて成立しそう。→納期延長
スーパープログラマは平凡なプログラマの10倍、100倍の能力があるとか、良く聞くし、実際にそうだとも思うけど、一定以上の規模の仕事の場合、彼/彼女ひとりに依存してしまうと、トラブルが発生したときに対応不能だよね。つまり、納期は彼の能力と気分次第ということになる。
それよりは普通の能力の人を多く使った方が計画的に仕事が進むし、多人数の方が途中経過を正確に把握しやすい。特定の部分や特定の人の仕事が遅れていれば、それを強化することも容易。
スーパープログラマかどうかは知らんけど、一人のプログラマに過剰に負荷がかかった結果、ダウンしてしまって、品質維持どころじゃなくなった例も知っているし、一方でプログラマ増やしすぎて、どいつもこいつもバラバラな実装やらかした結果、品質維持が出来なくなった例も知っていますんで、単純に多く使えば良いとも言い切れないなぁ。
多くの場合、プログラマよりも、旗振り役の方に高いスキルの人員が居ないと、プロジェクトはコケやすい気がする。
一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。それだとなんだか別の問題も起きそうですし。
ファーストサーバ…
最近の会議では「ファーストサーバ」という単語が万能でありがたいわ。
「オペレーションマニュアルの必要性を説くとき」「リカバリマニュアルの必要性を説くとき」「バックアップの有用性を説くとき」
今のところ、これらのケースでは「ファーストサーバ」と呟くだけで事足りた。あの事件は風化しないで頂きたい。
>下々がキツい時すぐそれを求めるようになるだろうし。
なーに、キツくならないよう、最初から十分な余裕を持った納期を設定しておけば良いだけのことですよ。#やれるんならやっている！
ソフトウェアではないですが、設計レビューを十分やるために社内委託作業（社内のCAD設計担当部門への設計委託）で通常より５割長い納期（と費用）を設定したことがあります。（担当部門要求４週間に対して６週間）
結果、どうなったかというと、その分以上に前半でサボられて余計品質が悪くなりました。いつまでたっても初版のレビュー用データが出てこない。
問い詰めると、こっちから金をとっておきながら、他の部門からも金を取って、違うことをしていたらしい。結果、数百万の金を取られて、さらに外部での再設計と納期遅延で億に近い損失がでました。
社外なら訴訟ものですが、社内だからどうにもならん。
社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。 どちらかというと、「設計・レビューが～が理由でできない」というクレームが上がってきたときの対応のほうが重要なはず（それで遅れても許容する余裕もね）＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
> 社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。ダメダメだからレビューをしっかりやるスケジュールを立てたら余計にダメダメだった、ってことです。
> ＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。モノ作りだと試作ラインの確保もしなきゃいけないですし。
＞うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。 他の部署にも影響してそうだから上にあげるべきですね。＃社内にやらせるくらいなら、社外に出したほうが安くて早い！（とかｗ
＞社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。 何言ってるんですか、隠せれないなら脳内予定を作っておけばいいんですよ（苦笑） 試作ラインの確保は・・・どうしようもないですね。自分の予定に別の予定を1週間程無理やり突っ込んでずらすとかくらいしか思いつきません＞＜
もちろん上にあげましたとも。だけど、役員間の力関係で握りつぶされました。ま、こんなんだからいつまでたってもヘタレなんですけどね。
> 社外に出したほうが安くて早い！（とかｗ
どうせ２～３人での設計作業なので、早い安いよりも品質なんです。組み込み機器なんですが、後工程でソフト屋さんが安心して実機デバッグに入れるかどうか、それが最優先なんですよ。
百人以上のソフト屋さんがターゲットの動作に不安を持ちながらデバッグするのはあまりに非効率ですからね。（精神衛生上もよくないし）不安定なターゲットでソフトデバッグなんてやってたら２週間どころではなく日程オーバーするか、ソフト含めたトータル品質が大幅低下してしまいます。
禿同！
こんなあたりまえのことが通じないのが現実。始まる前からまともなら納期遅れになるのはわかっている。それを期日にまにあわせるには真っ当な方法ではむりなのはあたりまえ。水の多いコンクリートなら工期の短縮はできるようなもの。耐久性を問われても困ります。
#納期が過ぎてから気合が入ります
>#納期が過ぎてから気合が入ります納期を細かく設定してずーっと気合を入れさせる手法をアジャイルとか呼ぶらしいな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
言うは易く行なうは難し (スコア:0)
＞また、納品の期日を守ることよりも、期日を過ぎてでも質の高いソフトウェアを完成させることを
＞優先させた方がいい、と理解できているマネジメントが必要であるとのこと。
理解出来ても実行出来るとは限らん、というかムリだorz
Re:言うは易く行なうは難し (スコア:1)
偉い人たち（中間管理職ではなく、トップマネジメントの次の連中）は目の前のキャッシュフローしか興味ないですからね。
ウチの場合、ロジックやエラー処理は一切抜きのデモUIのみの営業プレゼン用ソフトウェアを見て、
「なんでこれが売れないんだ！このまま売れ！」とか怒り出す人たちですから理解なんて無理なんですよ。
（指示する際も「とにかく顧客デモをやれ、その部分だけ作れ」という指示だったのだが、本人が忘れてる。）
理解している上級マネジメント職も火の粉が降り掛かるのを嫌がって「お前ら、上からそのまま売れって
言われてるんだから、言う通りにすればいいんだよ」って言い出す始末ですしね。
Re: (スコア:0)
納期破る判断って、マネジメントがそれを下すのはほんと難しいよね。
一度認めると、下々がキツい時すぐそれを求めるようになるだろうし。
一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
それだとなんだか別の問題も起きそうですし。
もともとの納期だって、それほど確かな下地に基づいて切ってる訳でもないでしょうから。
優等生理論でいくと、最初にマネジメントが下した「リソースの見極め＋納期の切り」に失敗の原因がありましたごめんなさい、っていう反省文とセットで初めて成立しそう。→納期延長
Re:言うは易く行なうは難し (スコア:5, すばらしい洞察)
スーパープログラマは平凡なプログラマの10倍、100倍の能力があるとか、良く聞くし、実際にそうだとも思うけど、一定以上の規模の仕事の場合、彼/彼女ひとりに依存してしまうと、トラブルが発生したときに対応不能だよね。つまり、納期は彼の能力と気分次第ということになる。
それよりは普通の能力の人を多く使った方が計画的に仕事が進むし、多人数の方が途中経過を正確に把握しやすい。特定の部分や特定の人の仕事が遅れていれば、それを強化することも容易。
Re:言うは易く行なうは難し (スコア:1)
スーパープログラマかどうかは知らんけど、一人のプログラマに過剰に負荷がかかった結果、ダウンしてしまって、品質維持どころじゃなくなった例も知っているし、一方でプログラマ増やしすぎて、どいつもこいつもバラバラな実装やらかした結果、品質維持が出来なくなった例も知っていますんで、単純に多く使えば良いとも言い切れないなぁ。
多くの場合、プログラマよりも、旗振り役の方に高いスキルの人員が居ないと、プロジェクトはコケやすい気がする。
Re: (スコア:0)
>計画的に仕事が進むし、多人数の方が途中経
>過を正確に把握しやすい。
上が「普通の能力」を持ってないと、いずれにしてもダメダメ。
無計画に多人数にして、却って全体を制御できなくなる。
ああ、さっさと抜けたい。
Re:言うは易く行なうは難し (スコア:4, 参考になる)
一定のフリーダムを許容してスーパープログラマに好き勝手させるスタイルも、品質解決策の一つな気がするけど。
それだとなんだか別の問題も起きそうですし。
ファーストサーバ…
Re:言うは易く行なうは難し (スコア:1)
最近の会議では「ファーストサーバ」という単語が万能でありがたいわ。
「オペレーションマニュアルの必要性を説くとき」
「リカバリマニュアルの必要性を説くとき」
「バックアップの有用性を説くとき」
今のところ、これらのケースでは「ファーストサーバ」と呟くだけで事足りた。あの事件は風化しないで頂きたい。
Re: (スコア:0)
>下々がキツい時すぐそれを求めるようになるだろうし。
なーに、キツくならないよう、最初から十分な余裕を持った納期を設定しておけば良いだけのことですよ。
#やれるんならやっている！
Re:言うは易く行なうは難し (スコア:2, 参考になる)
ソフトウェアではないですが、設計レビューを十分やるために社内委託作業（社内の
CAD設計担当部門への設計委託）で通常より５割長い納期（と費用）を設定した
ことがあります。（担当部門要求４週間に対して６週間）
結果、どうなったかというと、その分以上に前半でサボられて余計品質が悪くなりました。
いつまでたっても初版のレビュー用データが出てこない。
問い詰めると、こっちから金をとっておきながら、他の部門からも金を取って、違うことを
していたらしい。結果、数百万の金を取られて、さらに外部での再設計と納期遅延で
億に近い損失がでました。
社外なら訴訟ものですが、社内だからどうにもならん。
Re:言うは易く行なうは難し (スコア:2)
社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
どちらかというと、「設計・レビューが～が理由でできない」というクレームが上がってきたときの対応のほうが重要なはず（それで遅れても許容する余裕もね）
＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
Re:言うは易く行なうは難し (スコア:1)
> 社内の場合は設計・レビューがちゃんとできる環境にあるんだから、無理に納期を伸ばす必要性は皆無ですよ。
うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
ダメダメだからレビューをしっかりやるスケジュールを立てたら余計にダメダメだった、ってことです。
> ＃発注側の余裕と、受注側の余裕はずらすといいですよｗ
社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
モノ作りだと試作ラインの確保もしなきゃいけないですし。
Re:言うは易く行なうは難し (スコア:2)
＞うらやましいです。うちは社内の方がダメダメです。社内だからって甘えてるんですよ。
他の部署にも影響してそうだから上にあげるべきですね。
＃社内にやらせるくらいなら、社外に出したほうが安くて早い！（とかｗ
＞社内だと受注側が発注側のスケジュールを見れるから隠せないんですよ。
何言ってるんですか、隠せれないなら脳内予定を作っておけばいいんですよ（苦笑）
試作ラインの確保は・・・どうしようもないですね。自分の予定に別の予定を1週間程無理やり突っ込んでずらすとかくらいしか思いつきません＞＜
Re: (スコア:0)
もちろん上にあげましたとも。だけど、役員間の力関係で握りつぶされました。
ま、こんなんだからいつまでたってもヘタレなんですけどね。
> 社外に出したほうが安くて早い！（とかｗ
どうせ２～３人での設計作業なので、早い安いよりも品質なんです。
組み込み機器なんですが、後工程でソフト屋さんが安心して実機デバッグに
入れるかどうか、それが最優先なんですよ。
百人以上のソフト屋さんがターゲットの動作に不安を持ちながらデバッグするのは
あまりに非効率ですからね。（精神衛生上もよくないし）
不安定なターゲットでソフトデバッグなんてやってたら２週間どころではなく日程
オーバーするか、ソフト含めたトータル品質が大幅低下してしまいます。
Re: (スコア:0)
禿同！
こんなあたりまえのことが通じないのが現実。
始まる前からまともなら納期遅れになるのはわかっている。
それを期日にまにあわせるには真っ当な方法ではむりなのはあたりまえ。
水の多いコンクリートなら工期の短縮はできるようなもの。
耐久性を問われても困ります。
#納期が過ぎてから気合が入ります
Re:言うは易く行なうは難し (スコア:2)
>#納期が過ぎてから気合が入ります
納期を細かく設定してずーっと気合を入れさせる手法をアジャイルとか呼ぶらしいな。