1 仕様書無しさん :2008/06/03(火) 22:07:26
当方1年目の新人です。"デスマ"と言うのを最近知りました。
勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。
2 仕様書無しさん :2008/06/03(火) 22:50:49勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。
しぬ
3 仕様書無しさん :2008/06/03(火) 22:53:06仕様変更を重ねる
ところが 追加料金取れない馬鹿
∴ 納期そのまま
おめでとう
4 仕様書無しさん :2008/06/03(火) 22:53:20ところが 追加料金取れない馬鹿
∴ 納期そのまま
おめでとう
>>1
何事も経験するのが一番。と、言う事で来週からよろしく
5 仕様書無しさん :2008/06/03(火) 23:23:47何事も経験するのが一番。と、言う事で来週からよろしく
勉強したいと思うならこれ読みな
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
6 仕様書無しさん :2008/06/04(水) 01:06:10

定数を意味ごとにまとめたクラスがあるわけだけど
必要なものは既にほぼ過不足なく列挙され、excelで管理されていて
自動生成の準備が完全に整っているのに
なぜか自動生成しない。
コーディング中に実際に必要になる都度、申請を出さなければならない。
・・日本IBMのやることはよく分からん。
7 仕様書無しさん :2008/06/04(水) 01:16:30必要なものは既にほぼ過不足なく列挙され、excelで管理されていて
自動生成の準備が完全に整っているのに
なぜか自動生成しない。
コーディング中に実際に必要になる都度、申請を出さなければならない。
・・日本IBMのやることはよく分からん。
・・↑と書き込んではみたものの
excelで管理されているのはこんな感じの日本語名だけだから
定数クラス「ラーメソの具」
名称 コード
メンマ 01
なると(右巻) 02
なると(左巻) 03
リカルデント 04
これを英訳する作業は骨が折れるだろうか。
だとすると、やっぱり、必要になる都度申請・生成した方が効率的?
うーん。。。
8 仕様書無しさん :2008/06/04(水) 02:28:16excelで管理されているのはこんな感じの日本語名だけだから
定数クラス「ラーメソの具」
名称 コード
メンマ 01
なると(右巻) 02
なると(左巻) 03
リカルデント 04
これを英訳する作業は骨が折れるだろうか。
だとすると、やっぱり、必要になる都度申請・生成した方が効率的?
うーん。。。
それは、管理できてない、と言うんだ
9 仕様書無しさん :2008/06/04(水) 08:49:28ラーメソにリカルデントは
上級者向けじゃね?
10 仕様書無しさん :2008/06/04(水) 18:47:24上級者向けじゃね?
仕様が確定しないうちに製造を始める。
顧客は何をしたいか分からないし、仕様書で要件を確認できない。
納期は決まっている。
途中で仕様がぶれる
製造者は大混乱
納期は迫る
デスマ突入
11 仕様書無しさん :2008/06/04(水) 19:27:20顧客は何をしたいか分からないし、仕様書で要件を確認できない。
納期は決まっている。
途中で仕様がぶれる
製造者は大混乱
納期は迫る
デスマ突入
まず予算が決まる。
次に納期が決まる。
ヒアリングが始まる。
要件定義が始まる。
開発言語が決まる。
基盤(OSなど)が決まる。
DBが決まる!
根回しが始まる。
(ユーザーから)クレームが出る。
予算と納期の調整が始まる(短く、少なく)
プロジェクトはとうに始まっている!!!!
12 仕様書無しさん :2008/06/04(水) 19:29:07次に納期が決まる。
ヒアリングが始まる。
要件定義が始まる。
開発言語が決まる。
基盤(OSなど)が決まる。
DBが決まる!
根回しが始まる。
(ユーザーから)クレームが出る。
予算と納期の調整が始まる(短く、少なく)
プロジェクトはとうに始まっている!!!!
とにかく納期が決まる。
仕様が固まらない。
仕様が固まらない。
・・・・・・・・・・・・・・・
納期いつだっけ?
13 仕様書無しさん :2008/06/04(水) 19:30:03仕様が固まらない。
仕様が固まらない。
・・・・・・・・・・・・・・・
納期いつだっけ?
ユーザー:『「○○は出来ない」と書いてないから当然出来るよね?』
これが始まるとデスマ突入orz
14 仕様書無しさん :2008/06/04(水) 19:36:31これが始まるとデスマ突入orz
>>13
そういうときは「何でも出来ますよ」と笑いながらCコンパイラを納品するべし。
相手にもよるが旨くかわせる可能性はあるかもしれない。
15 仕様書無しさん :2008/06/04(水) 21:42:30そういうときは「何でも出来ますよ」と笑いながらCコンパイラを納品するべし。
相手にもよるが旨くかわせる可能性はあるかもしれない。
お客様か請けた側のどちらかで権力闘争がはじまるとデスマ確率が急上昇
16 仕様書無しさん :2008/06/04(水) 23:29:50>>1
よーしパパ爆弾発言しちゃうぞー
東証次世代プロジェクトは 失 敗 す る
17 仕様書無しさん :2008/06/04(水) 23:44:36よーしパパ爆弾発言しちゃうぞー
東証次世代プロジェクトは 失 敗 す る
もうパパったらぁそれは内緒ってあれほdぐが(Ry
18 仕様書無しさん :2008/06/05(木) 00:02:15・見積もりを出す能力がない役職が、見積もりを契約するプロジェクト
・見積もり時と異なった条件になったときに、スケジュールを引き直さないプロジェクト
前者は、「良くわかんないけど、12ヶ月もあったらできるだろ」とハンコ押しちゃう場合
後者は、「納期も予算も変わらないけど、変更は沢山はいる」という場合
次点で
・はなから赤字になると判っているプロジェクト
(これはやる気の問題だから、普通に終わることもある)
デスマは、技術や能力ではなくマネジメントの問題だから、ダメ管理者が居るとダメだな。
どのレベル(営業を制御できない経営層、リソースの確保が出来ない課長)かによってデスマ度が変わるね。
19 仕様書無しさん :2008/06/05(木) 07:00:17・見積もり時と異なった条件になったときに、スケジュールを引き直さないプロジェクト
前者は、「良くわかんないけど、12ヶ月もあったらできるだろ」とハンコ押しちゃう場合
後者は、「納期も予算も変わらないけど、変更は沢山はいる」という場合
次点で
・はなから赤字になると判っているプロジェクト
(これはやる気の問題だから、普通に終わることもある)
デスマは、技術や能力ではなくマネジメントの問題だから、ダメ管理者が居るとダメだな。
どのレベル(営業を制御できない経営層、リソースの確保が出来ない課長)かによってデスマ度が変わるね。
すさまじい馬鹿が牛耳ってる会社はすごいぞ。
何しろ、販売価格3万の商品と300万の商品のコスト算出基準が一緒だ。
メンテナンスで後者は年間100万取らないと引き合わないというのにwww
もうどうにでもなあれwww
20 仕様書無しさん :2008/06/05(木) 17:00:46何しろ、販売価格3万の商品と300万の商品のコスト算出基準が一緒だ。
メンテナンスで後者は年間100万取らないと引き合わないというのにwww
もうどうにでもなあれwww
デスマの経験をしたことないマは一度経験して欲しいw
確実に何か人生変わるぜw
21 仕様書無しさん :2008/06/05(木) 17:04:05確実に何か人生変わるぜw
一回デスマを味わった結果。
プロジェクトのメンバーにバカが一人でもいると、
強い憤りを感じるようになりました…
22 仕様書無しさん :2008/06/05(木) 22:04:10プロジェクトのメンバーにバカが一人でもいると、
強い憤りを感じるようになりました…
安心しろ。お前も馬鹿だ。
23 仕様書無しさん :2008/06/05(木) 22:09:27原因はさまざまであるが、以下のいずれかのうち2つ以上が該当した場合
そのプロジェクトはデスマっていると言える。
・50%以上の工程遅延
・50%以上の予算超過
・50%以下の仕様達成率
・10%以上の離職者
・10%以上の入通院者
・1人以上の死者(過労/自殺問わず)
24 仕様書無しさん :2008/06/06(金) 00:05:49そのプロジェクトはデスマっていると言える。
・50%以上の工程遅延
・50%以上の予算超過
・50%以下の仕様達成率
・10%以上の離職者
・10%以上の入通院者
・1人以上の死者(過労/自殺問わず)
あ、大丈夫です。
予算は500%近く超過してますんでwwwwww
ふぅ・・・
25 仕様書無しさん :2008/06/06(金) 15:10:52予算は500%近く超過してますんでwwwwww
ふぅ・・・
クライアントを説得されられないプロジェクト
26 仕様書無しさん :2008/06/06(金) 17:46:53学歴があっても無知無学な人がいるとなるよ。
単に「この世はお金」と海賊並みの精神レベルの人ね。
28 仕様書無しさん :2008/06/06(金) 17:50:10単に「この世はお金」と海賊並みの精神レベルの人ね。
人間って言うのは動物だ。
きちんと次世代の事を考えて人を育てて
引き継いでいく人が生き残る。
30 仕様書無しさん :2008/06/06(金) 18:46:39きちんと次世代の事を考えて人を育てて
引き継いでいく人が生き残る。
デスマ: 対象者は死ぬ
31 仕様書無しさん :2008/06/06(金) 22:07:51デスマ? 何それ、おいしいの?
32 仕様書無しさん :2008/06/06(金) 23:28:37逢いたかったよ、ヤマトの諸君!
33 仕様書無しさん :2008/06/06(金) 23:32:50デスマって参加しなきゃ良いだけだよ。
参加する側に問題がある。
俺は6年前に「デスマはやめる」と思って転職して、
6年の間に徹夜は1回だけだ。給料は並みだけど。
デスマって自分の事だけを考えている人特有の状況。
34 33 :2008/06/06(金) 23:42:51参加する側に問題がある。
俺は6年前に「デスマはやめる」と思って転職して、
6年の間に徹夜は1回だけだ。給料は並みだけど。
デスマって自分の事だけを考えている人特有の状況。
「特攻しろ」と言われても特攻しない方が頭良いに決まってるジャン。
特攻しない方が即効性はないが待遇が良くなる。
それは中学で勉強しただろ?
単に「論語読みの論語知らず」だよ。デスマする人って。
37 仕様書無しさん :2008/06/10(火) 00:41:48特攻しない方が即効性はないが待遇が良くなる。
それは中学で勉強しただろ?
単に「論語読みの論語知らず」だよ。デスマする人って。
・参画しているのは知らない会社ばかり
・やけに若い人ばかりorやけに年寄りばかりの両極端
・デスクが足りない。パイプ椅子を使わされる。
39 仕様書無しさん :2008/06/11(水) 00:23:20・やけに若い人ばかりorやけに年寄りばかりの両極端
・デスクが足りない。パイプ椅子を使わされる。
今やっているプロジェクトのマネージャーが炎上している他のプロジェクトにかかりっきりになって
本来のプロジェクトにほとんど関われなくなった時。…今まさにそんな状況だけど。
マネージャー以外のメンバーは、俺含んで2名。しかも2人とも入社3ヶ月目w
マネージャーの指示がなければ動きたくても動けません。
41 仕様書無しさん :2008/06/12(木) 12:11:27本来のプロジェクトにほとんど関われなくなった時。…今まさにそんな状況だけど。
マネージャー以外のメンバーは、俺含んで2名。しかも2人とも入社3ヶ月目w
マネージャーの指示がなければ動きたくても動けません。
お前・・・要らない人材なんじゃないか・・・?
42 仕様書無しさん :2008/06/13(金) 01:08:02なんかね、この現場、変なんですよ。
4000行もあるソースファイル(一応ステップ数ではない)を自動生成してくれるんですけどこれを単体テストしろってさ。うん、おまえがやれ。
44 仕様書無しさん :2008/06/25(水) 22:38:394000行もあるソースファイル(一応ステップ数ではない)を自動生成してくれるんですけどこれを単体テストしろってさ。うん、おまえがやれ。
女がいる
46 仕様書無しさん :2008/07/11(金) 14:32:01I○Mは仕様の確認が硬いの?
デスマも少ない???
47 仕様書無しさん :2008/07/11(金) 17:15:36デスマも少ない???
I□Mは、顧客と条件で合意するのが難しそうだと速攻撤退すると聞いたことが
条件を折り合わせて、ちょっと安く受けるとかしないらしい?
で、そういう少々問題がありそうな案件拾ってるのが、Fとかw
48 仕様書無しさん :2008/07/11(金) 17:16:52条件を折り合わせて、ちょっと安く受けるとかしないらしい?
で、そういう少々問題がありそうな案件拾ってるのが、Fとかw
んで、火を噴くんだよな。
49 仕様書無しさん :2008/07/11(金) 21:29:23とにかく要件定義と設計につきるよな。ここがしっかりしてれば多少
現場がへぼくても大丈夫
50 仕様書無しさん :2008/07/11(金) 21:47:43現場がへぼくても大丈夫
デスマの末やっと先月納品したのに
複雑すぎて使い方が解らないという顧客からのクレームで
ログ解析して仕様頻度の低い機能を洗い出して機能削減する事になった
結局、新規追加した機能は全く使われていない事が判明
元請が顧客の要望を全部受け入れて
どう考えてもそんなの要らんだろうという
ムダ機能てんこ盛りだったから当たり前だが
追加した機能をごっそり削る仕事は
空しくて意欲が湧かないんだな〜
51 仕様書無しさん :2008/07/12(土) 16:22:07複雑すぎて使い方が解らないという顧客からのクレームで
ログ解析して仕様頻度の低い機能を洗い出して機能削減する事になった
結局、新規追加した機能は全く使われていない事が判明
元請が顧客の要望を全部受け入れて
どう考えてもそんなの要らんだろうという
ムダ機能てんこ盛りだったから当たり前だが
追加した機能をごっそり削る仕事は
空しくて意欲が湧かないんだな〜
>>50
元請けの売上げの為、元請けが主導で、全く不要な機能追加を顧客に提案していた案件かな。
顧客も本来なら不要な予算を注ぎ込み、開発現場もデスマで赤字とか。
不要な機能の提案と、形だけ進捗管理していた、元請けだけが儲けるという仕組み。
その中間の元請けをスキップしてしまえば、顧客も開発現場も幸せになれるのだけどねぇ。
52 仕様書無しさん :2008/07/13(日) 11:35:50元請けの売上げの為、元請けが主導で、全く不要な機能追加を顧客に提案していた案件かな。
顧客も本来なら不要な予算を注ぎ込み、開発現場もデスマで赤字とか。
不要な機能の提案と、形だけ進捗管理していた、元請けだけが儲けるという仕組み。
その中間の元請けをスキップしてしまえば、顧客も開発現場も幸せになれるのだけどねぇ。
>>51
その通りでした
開発中は無駄に要件が複雑になっていく機能の実装に悩まされ
必要性が全く無いので落としどころが見つからずにグダグダ設計
開発者がテスト操作に苦労する素晴らしいシステムが出来上がりました
機能を削る費用を何処が持つのかで揉めているのですが
なぜか納期だけ決まっているw
これもデスマ決定か
58 仕様書無しさん :2008/07/14(月) 15:03:17その通りでした
開発中は無駄に要件が複雑になっていく機能の実装に悩まされ
必要性が全く無いので落としどころが見つからずにグダグダ設計
開発者がテスト操作に苦労する素晴らしいシステムが出来上がりました
機能を削る費用を何処が持つのかで揉めているのですが
なぜか納期だけ決まっているw
これもデスマ決定か
>>51
それでも顧客は、会社の規模で判断するから、
丸投げしてピンハネだけしている元請に仕事を出すわけですね。
ピンハネしている元請を飛ばすと、
仕事欲しい小さい会社は、値段を安くしてでも、仕事を欲しがるから、
値下げ合戦になって、
システムの仕事は儲からない仕事になっちゃうんじゃないかな。
元請の正社員はいらないだろと思うけど、仕方がないのかもしれませんねえ。
59 仕様書無しさん :2008/07/31(木) 18:41:13それでも顧客は、会社の規模で判断するから、
丸投げしてピンハネだけしている元請に仕事を出すわけですね。
ピンハネしている元請を飛ばすと、
仕事欲しい小さい会社は、値段を安くしてでも、仕事を欲しがるから、
値下げ合戦になって、
システムの仕事は儲からない仕事になっちゃうんじゃないかな。
元請の正社員はいらないだろと思うけど、仕方がないのかもしれませんねえ。
>>58
ただその元請がものすごく、どーしようもないくらい
アタマ悪い場合があるんだよねぇ…
53 仕様書無しさん :2008/07/13(日) 20:52:18ただその元請がものすごく、どーしようもないくらい
アタマ悪い場合があるんだよねぇ…
PSSIが主導のプロジェクト
55 仕様書無しさん :2008/07/13(日) 23:03:53要求を毎回変更する顧客はよく刺されないなと感心してしまうよ
60 仕様書無しさん :2008/08/02(土) 19:29:431.成果物の署名が責任追及のためだと思っていること。(あとですぐに聞くことのできるようにするために署名する。)
2.問題点がないことを問題視すること。(報告書に書くための問題点をでっち上げる等)
3.リーダに自覚がありすぎること。(上から目線になりやすい)
4.リーダと同期の平が嫉妬していること。(プロジェクトのことよりも、言い負かすことに躍起になる)
5.徹夜明けに居眠りしているメンバを注意できないリーダ。
6.(5.)が注意できないことをわかってサボるメンバ。
61 仕様書無しさん :2008/08/02(土) 22:57:082.問題点がないことを問題視すること。(報告書に書くための問題点をでっち上げる等)
3.リーダに自覚がありすぎること。(上から目線になりやすい)
4.リーダと同期の平が嫉妬していること。(プロジェクトのことよりも、言い負かすことに躍起になる)
5.徹夜明けに居眠りしているメンバを注意できないリーダ。
6.(5.)が注意できないことをわかってサボるメンバ。
>>60
徹夜で居眠りなんて、デスマる条件じゃなくてデスマ状態じゃないかw
64 仕様書無しさん :2008/08/04(月) 01:37:49徹夜で居眠りなんて、デスマる条件じゃなくてデスマ状態じゃないかw
デスマは納期や予算などの前提条件からではなく
プロジェクトを構成する人間の精神から産まれるということに早く気づくべき
65 仕様書無しさん :2008/08/04(月) 21:43:44プロジェクトを構成する人間の精神から産まれるということに早く気づくべき
精神論ですか。一人一人が高い意識ならデスマにならないという下請けに丸投げしてあぐらくんでる人達の意見ですね。
69 仕様書無しさん :2008/08/05(火) 11:27:01人間の脳が効率よく働くのは一日4〜5時間ほどとか何かの本で書いてあったような
70 仕様書無しさん :2008/08/05(火) 21:23:19>>69
もっとも効率よく脳が働けるのって、そのくらいだよ
昔トリビアでも言ってたね
しかも集中力100%なんて、普通の人間がホイホイ出せるもんじゃない
トップアスリートでさえ、容易に到達出来るものじゃないんだから
72 仕様書無しさん :2008/08/14(木) 12:00:43もっとも効率よく脳が働けるのって、そのくらいだよ
昔トリビアでも言ってたね
しかも集中力100%なんて、普通の人間がホイホイ出せるもんじゃない
トップアスリートでさえ、容易に到達出来るものじゃないんだから
方眼紙Excelで仕様書、設計書を作っている現場はデスマる。
間違いなくドキュメントの内容が糞。
そのドキュメントが罫線だらけならもっと糞。
73 仕様書無しさん :2008/08/14(木) 13:45:11間違いなくドキュメントの内容が糞。
そのドキュメントが罫線だらけならもっと糞。
>>72
それ、俺の所だ。org
74 仕様書無しさん :2008/08/16(土) 19:13:11それ、俺の所だ。org
>>72
ww
Fとか、そういうドキュメント大好きだよなw
つまりはそういうことが言いたいのでしょうか?w
76 仕様書無しさん :2008/08/21(木) 00:01:42ww
Fとか、そういうドキュメント大好きだよなw
つまりはそういうことが言いたいのでしょうか?w
>>72
おーっと今のFの現場がそうだ…
やはりこれをデスマというのか、経験2年目で転職するか考える良い機会になりました。毎日終電でたまに土曜もっておかしいですよね。
1年目は甘やかされてたんだな…
75 仕様書無しさん :2008/08/19(火) 21:34:33おーっと今のFの現場がそうだ…
やはりこれをデスマというのか、経験2年目で転職するか考える良い機会になりました。毎日終電でたまに土曜もっておかしいですよね。
1年目は甘やかされてたんだな…
大して能力もないくせに、営業やPMやりたがるバカと
いきなりバカ企業に就職しちゃって、本物がわからないバカ社員が原因。
ソフ開レベルの知識、それなりの業務経験がないと見積りは無理。
それ以前に、インドやアメリカではPGなんて頭良くないとなれない。
77 仕様書無しさん :2008/08/21(木) 01:32:15いきなりバカ企業に就職しちゃって、本物がわからないバカ社員が原因。
ソフ開レベルの知識、それなりの業務経験がないと見積りは無理。
それ以前に、インドやアメリカではPGなんて頭良くないとなれない。
使えない奴がプロジェクトの2割を超えたらデスマる
79 仕様書無しさん :2008/08/21(木) 21:55:32デスマの直接の原因は、作業のブレークダウンが下手なSEや
見積もり能力に乏しいPMだろうな。
必要なモジュールを見落とさずに見積もらないとデスマる。
モジュールに分解する段階で、作業量の20%以上の見落としがあると限界。
モデリング・文書化・実装・テスト表作成・テストなどなど
あらゆる工程が増えるから、慢性的な残業地獄になる。
朝が最も効率よいとすると、作業効率なんてこんなもんだ。
「朝の3時間」=「13時以降の4時間」=「17時以降の5時間」
ここに睡眠不足が追加され、取り返しがつかないデスマとなる。
81 仕様書無しさん :2008/08/21(木) 23:07:32見積もり能力に乏しいPMだろうな。
必要なモジュールを見落とさずに見積もらないとデスマる。
モジュールに分解する段階で、作業量の20%以上の見落としがあると限界。
モデリング・文書化・実装・テスト表作成・テストなどなど
あらゆる工程が増えるから、慢性的な残業地獄になる。
朝が最も効率よいとすると、作業効率なんてこんなもんだ。
「朝の3時間」=「13時以降の4時間」=「17時以降の5時間」
ここに睡眠不足が追加され、取り返しがつかないデスマとなる。
まず、動くものをつくってみなければ、わからない。
これがわかってなくて、いきなり設計とかしちゃうとデスマいきですよ。
82 仕様書無しさん :2008/08/22(金) 09:01:07これがわかってなくて、いきなり設計とかしちゃうとデスマいきですよ。
いきなり作るのはまずい
91 仕様書無しさん :2008/08/24(日) 14:35:17バグなら直すけど、バグじゃないからなぁ。
92 仕様書無しさん :2008/08/25(月) 23:31:38無駄な機能とか無意味な改変を要求された時に、それを説明するのも一苦労なんだよな。
否定されるとムキになって来る人が多いから、Yes・But法で延々と話すことになる。
上のほうや歳喰ってるひとの方が、ムキになる傾向が高いのがこれまたなんとも。
93 仕様書無しさん :2008/08/28(木) 14:10:28否定されるとムキになって来る人が多いから、Yes・But法で延々と話すことになる。
上のほうや歳喰ってるひとの方が、ムキになる傾向が高いのがこれまたなんとも。
仕様決めた本人から「何を以て仕様を仕様と定義するのか?」
なんて言葉が出てくるとオワタw
94 仕様書無しさん :2008/08/28(木) 16:30:58なんて言葉が出てくるとオワタw
>>93
その場にいたら笑いを堪えきれない自信があるw
95 仕様書無しさん :2008/08/28(木) 16:53:46その場にいたら笑いを堪えきれない自信があるw
先ずは言語から規定しる。
構造主義とかどうだ?
98 仕様書無しさん :2008/08/30(土) 13:16:31構造主義とかどうだ?
「顧客に対するソフトウェアとはサービスだ。」
ソフトウェアとサービスという日本ではどちらも曖昧になりがちな言葉を=で繋いでいるところに危うさを感じる
99 仕様書無しさん :2008/08/30(土) 13:46:15ソフトウェアとサービスという日本ではどちらも曖昧になりがちな言葉を=で繋いでいるところに危うさを感じる
日本の場合は「サービス=無料」って考えるバカが多いからな。
101 仕様書無しさん :2008/08/31(日) 18:49:20大抵は
・客が「自分たちがやっていること」が解っていない
・Sヨは客の言うことに頷くだけ
・PGは仕様が変わったら、対応せざるを得ないほど
立場が弱いケースが多い
ため、
仕様確認の度に新しい後出し仕様が発生し、
確定していたはずの仕様が右往左往前進後退し、
DBの設計レベルでひっくり返ったりする
だから、デスマになるんですよ
102 仕様書無しさん :2008/08/31(日) 18:57:30・客が「自分たちがやっていること」が解っていない
・Sヨは客の言うことに頷くだけ
・PGは仕様が変わったら、対応せざるを得ないほど
立場が弱いケースが多い
ため、
仕様確認の度に新しい後出し仕様が発生し、
確定していたはずの仕様が右往左往前進後退し、
DBの設計レベルでひっくり返ったりする
だから、デスマになるんですよ
>客が「自分たちがやっていること」が解っていない
もし客が自分たちのやってることがわかってて、
仕様を100%作ってくれたら漏れらの仕事は1/10になるだろうよ。
103 仕様書無しさん :2008/08/31(日) 19:07:28もし客が自分たちのやってることがわかってて、
仕様を100%作ってくれたら漏れらの仕事は1/10になるだろうよ。
そして客内部の政治的な要素がからむと
更に迷走する
104 仕様書無しさん :2008/08/31(日) 20:28:38更に迷走する
つか、客先の担当者は業務として、例外として、
運用上のルールとしては分かってるんだけど
システム化において「それがいかに重要なこと」であるか
理解していないため、後出しになるんだろう。
105 仕様書無しさん :2008/08/31(日) 20:33:29運用上のルールとしては分かってるんだけど
システム化において「それがいかに重要なこと」であるか
理解していないため、後出しになるんだろう。
重要ポストに精神年齢が低いヤシがいる
106 仕様書無しさん :2008/09/01(月) 23:05:45全く知識のない分野のデスマに放り込まれそうだ…。
107 仕様書無しさん :2008/09/02(火) 08:33:33>>106
イキロ
俺は来週から何やるかまだ詳細を聞かされてない案件に投入される。orz
108 仕様書無しさん :2008/09/02(火) 21:41:30イキロ
俺は来週から何やるかまだ詳細を聞かされてない案件に投入される。orz
それって、ワクワクしないのか?
つか、俺デスマ好きだけどな。
マジ生きるか死ぬかの瀬戸際になったことは2度くらいしかないけど、
壊れるか踏みとどまるかのあの際のスリルはマジ楽しい。
他人に危害を加えなくとも自我の崩壊間際を体験できるwww
110 仕様書無しさん :2008/09/03(水) 18:52:59つか、俺デスマ好きだけどな。
マジ生きるか死ぬかの瀬戸際になったことは2度くらいしかないけど、
壊れるか踏みとどまるかのあの際のスリルはマジ楽しい。
他人に危害を加えなくとも自我の崩壊間際を体験できるwww
>>108
それで一回本当に壊れると、そんな笑い事じゃなくなるよ…
もう自分ではどうしようもないどん底で苦しむのは嫌だし
元気出したくても、動けないとか、もう嫌だし
111 108 :2008/09/03(水) 19:33:56それで一回本当に壊れると、そんな笑い事じゃなくなるよ…
もう自分ではどうしようもないどん底で苦しむのは嫌だし
元気出したくても、動けないとか、もう嫌だし
>>110
壊れたことがないからわからないんだけどさ。
ただ、最後まで居残っていると次からは俺の声が鶴の一声になるというのだけはガチ。
これがたまらんからデスマに突入できるw
112 仕様書無しさん :2008/09/03(水) 22:05:36壊れたことがないからわからないんだけどさ。
ただ、最後まで居残っていると次からは俺の声が鶴の一声になるというのだけはガチ。
これがたまらんからデスマに突入できるw
人間って、かなり無茶しても壊れないときもあるし、
意外と簡単にポキッと折れることもあるよな。
113 仕様書無しさん :2008/09/04(木) 08:44:18意外と簡単にポキッと折れることもあるよな。
ヒント: 勤続疲労
114 仕様書無しさん :2008/09/04(木) 11:20:36ヒントの癖に!ヒントの癖にっ!だれうま!
115 仕様書無しさん :2008/09/06(土) 00:02:45やっと今日が終わった…
また明日が始まる…
116 仕様書無しさん :2008/09/13(土) 01:00:51また明日が始まる…
今の現場でわかったデスマる条件
・横のつながりが弱いが縦のつながりが異常に強い
120 仕様書無しさん :2008/09/13(土) 15:08:16・横のつながりが弱いが縦のつながりが異常に強い
>>116
縦割りってやつなだ
組織が腐ると、そういう方向に行く希ガス
今の官公庁系がまさにそれだろうし
119 仕様書無しさん :2008/09/13(土) 14:54:16縦割りってやつなだ
組織が腐ると、そういう方向に行く希ガス
今の官公庁系がまさにそれだろうし
責任感無い人この業界多いよな?
それがデスマの原因だろ。
122 仕様書無しさん :2008/09/19(金) 02:42:34それがデスマの原因だろ。
とどのつまり、見積りの精度で決まる。
123 仕様書無しさん :2008/09/19(金) 06:57:22見積もりの精度っつーか、ウチの場合は2〜3人月規模のプロジェクトの打ち合わせで
話し終わって自分が満足したらその時点で期限を切ってしまう馬鹿次第。
仕様書?ホワイトボードに書いてる内容でいいだろ。
書きたいなら書けよ。2〜3日でできるだろ。
でも期限は決まってるからな。
とか言われる。
仕様書が一番難しいのだが。
曰く、プログラムや仕様書とは、そこらのラーメンやそのレシピと同じ感覚らしい。
ラーメンの新規開発も難しいだろうに。
130 仕様書無しさん :2008/09/20(土) 13:44:18話し終わって自分が満足したらその時点で期限を切ってしまう馬鹿次第。
仕様書?ホワイトボードに書いてる内容でいいだろ。
書きたいなら書けよ。2〜3日でできるだろ。
でも期限は決まってるからな。
とか言われる。
仕様書が一番難しいのだが。
曰く、プログラムや仕様書とは、そこらのラーメンやそのレシピと同じ感覚らしい。
ラーメンの新規開発も難しいだろうに。
人数が多くなるほどデスマるらしいが・・・
132 仕様書無しさん :2008/09/20(土) 14:21:11>>130
規模が大きくなると生産性が下がることを
認めたくない人が多いんだろう。
134 仕様書無しさん :2008/09/20(土) 15:37:58規模が大きくなると生産性が下がることを
認めたくない人が多いんだろう。
>>130
正直、新たに二人雇うより、生産性の高い一人の給料を
倍にしたほうが、生産性は上がると思う。
135 仕様書無しさん :2008/09/20(土) 19:24:58正直、新たに二人雇うより、生産性の高い一人の給料を
倍にしたほうが、生産性は上がると思う。
そういう人がなかなか見つからないので
結局二人雇ってしまう・・・・・
140 仕様書無しさん :2008/12/14(日) 08:18:26結局二人雇ってしまう・・・・・
そろそろデスマ突入っぽいな。うちのPJ。
ここのスレ読んでたらそんな気がしてきた。
141 仕様書無しさん :2008/12/14(日) 11:07:18ここのスレ読んでたらそんな気がしてきた。
全員が全員、システムの仕様を知ってるわけじゃないのに
製造が終わった段階で担当サブシステム、所属会社を無視してひとまとめにしてテスト計画、テスト実施、製造品質にもう一度分解しました。
まあいいんだ。この案件が成功すれば。現状を鑑みると…
146 仕様書無しさん :2008/12/16(火) 21:34:01製造が終わった段階で担当サブシステム、所属会社を無視してひとまとめにしてテスト計画、テスト実施、製造品質にもう一度分解しました。
まあいいんだ。この案件が成功すれば。現状を鑑みると…
のんびり構えて大して役に立てなくて早々に切られるのと
アテにされてボロボロになるまでこき使われて切られるのと
どっちがいいんだろうなぁ・・・・・
148 仕様書無しさん :2008/12/16(火) 22:23:57アテにされてボロボロになるまでこき使われて切られるのと
どっちがいいんだろうなぁ・・・・・
>>146
俺は後者だったけど、残ったのは病気と無職期間だけだ
間違いなく前者がいいだろう
147 仕様書無しさん :2008/12/16(火) 22:11:07俺は後者だったけど、残ったのは病気と無職期間だけだ
間違いなく前者がいいだろう
そこそこでそこそこの給料もらったら丸儲けじゃないか
必死こいて残業代カット+治療費とか割に合わん
149 仕様書無しさん :2008/12/17(水) 01:14:22必死こいて残業代カット+治療費とか割に合わん
のんびり構えてたらやけにアテにされて、それをむげに断れずに対応してたらあああああああ
この前、「この間はごめんねうちの社員にならない?」て電話が来たよ。
断ったけど。
この前、「この間はごめんねうちの社員にならない?」て電話が来たよ。
断ったけど。
今日の更新一覧
トラックバック
その他の記事
コメントありがとう御座います。 ⇒最新のコメントへ(42)
学名ナナシ
:2008年12月31日 00:44
#
1
年の瀬にこんな話題かよw
顧客が説明した要件 プロジェクトリーダの理解 アナリストのデザイン〜
のイラストがなかった
ガンパレ とか言おうと思ったが、あれは違った
のイラストがなかった
ガンパレ とか言おうと思ったが、あれは違った
最初に顧客の空想を聞いて(ドキュメントには残さない)、
いきなり製造を始めて、できたのを客にいじらせて、
要望を聞いて画面を修正して、最後にできたものを元に設計書を作ればいいと思う。
いきなり製造を始めて、できたのを客にいじらせて、
要望を聞いて画面を修正して、最後にできたものを元に設計書を作ればいいと思う。
年の瀬にいっきに鬱になったw
PGが顧客と交渉するようなのは間違いなくデスマるわ
交渉事やったことないのが出てくると要望をみんな請けちまう
交渉事やったことないのが出てくると要望をみんな請けちまう
プロマネがあほ
今の会社は自社ユーザーばかりだから、10年弱で徹夜したのはデータ移行とか立会いで数回。
話聞いてると、間に入って金だけ掠めて何もしない会社多すぎない?
この業界に限った話じゃないかもしれんけど。よって末端の会社は納期別にしても能力の限界まで仕事請けないと回らないとか?
話聞いてると、間に入って金だけ掠めて何もしない会社多すぎない?
この業界に限った話じゃないかもしれんけど。よって末端の会社は納期別にしても能力の限界まで仕事請けないと回らないとか?
これを思い出した。
ttp://www.projectcartoon.com/cartoon/586
ttp://www.projectcartoon.com/cartoon/586
ロバート・L・グラス「ソフトウエア開発 55の真実と10のウソ」
は面白かった。
日本固有の問題についてはいい本が無い。
久手堅 憲之「日本のソフトウェア産業がいつまでもダメな理由」
の内容は普通すぎていまいち。
は面白かった。
日本固有の問題についてはいい本が無い。
久手堅 憲之「日本のソフトウェア産業がいつまでもダメな理由」
の内容は普通すぎていまいち。
全てのプロジェクトはデスマ状態で稼動している。
運よく2,3人のスーパーマンが混ざってると彼らが処理してデスマが回避できる。
それに味を占めた上層部は似たような計画を立て、いやになったスーパーマンが
退社し、デスマが始まる。
運よく2,3人のスーパーマンが混ざってると彼らが処理してデスマが回避できる。
それに味を占めた上層部は似たような計画を立て、いやになったスーパーマンが
退社し、デスマが始まる。
日本全体がデスマわかります
誰も「発注元が官公庁」というのを出してこないのが驚きだ……。
官僚は基本的にシステム開発が分かってないから、アホみたいな期日を提示してくる。
しかも理由は「年度末までに予算を消化しなくてはいけないから」とかだぞ?
もうそれだけでデスマ確定だ。
死ね、クソ役人どもが。
官僚は基本的にシステム開発が分かってないから、アホみたいな期日を提示してくる。
しかも理由は「年度末までに予算を消化しなくてはいけないから」とかだぞ?
もうそれだけでデスマ確定だ。
死ね、クソ役人どもが。
人材配置の面から考えると遊撃部隊として自由に動けるスーパーSE,PGを一人配置すると結構そいつが処理してくれることが多い気がする。
大きなプロジェクトになるとチーム横断で見れる奴が段々いなくなって品質に悪影響を及ぼすことがあるが、それを解消するのがこういう奴等だと。
だから金銭的余裕がなくても絶対にこういう役割の奴は入れるなぁ
ただデスマーチはいろんな要因があるからなかなか防げるものでもないが、、、
『火を出さない方法』と『火を消す方法』は一流のPMになるのは必須なんっだが、難しい命題ですな
大きなプロジェクトになるとチーム横断で見れる奴が段々いなくなって品質に悪影響を及ぼすことがあるが、それを解消するのがこういう奴等だと。
だから金銭的余裕がなくても絶対にこういう役割の奴は入れるなぁ
ただデスマーチはいろんな要因があるからなかなか防げるものでもないが、、、
『火を出さない方法』と『火を消す方法』は一流のPMになるのは必須なんっだが、難しい命題ですな
> スーパーマンが混ざってると
出来る人ほど失敗プロジェクトにばかり回されるから
利益出ない→評価上がらない→給料増えない
つくづく働いたら負けに出来てるな!
出来る人ほど失敗プロジェクトにばかり回されるから
利益出ない→評価上がらない→給料増えない
つくづく働いたら負けに出来てるな!
デスマーチってアイシールドの漫画からかと思ってたんだけど違うんだね
徹夜明けで居眠りするな、はきつい
徹夜明けで居眠りするな、はきつい
ユーザー「できるだけ大きい会社に頼もう」(安心したい)
元請「できるだけ安い会社を使おう!」(利益を出したい)
下請「安くても仕事を取らないと!」(過剰競争状態)
派遣会社「人入れれば利益確定」
……誰が悪いのかわかんない。全員??
元請「できるだけ安い会社を使おう!」(利益を出したい)
下請「安くても仕事を取らないと!」(過剰競争状態)
派遣会社「人入れれば利益確定」
……誰が悪いのかわかんない。全員??
ただのインストール作業なのに、半分インストール完了してから仕様変更で
やり直しをするハメになったよ…2000台。
当然休日出勤だが、プログラム組んでた人は徹夜だったので仕事中寝てたな。
デスマーチはするものじゃなくて『させられるもの』だと思うな。
やり直しをするハメになったよ…2000台。
当然休日出勤だが、プログラム組んでた人は徹夜だったので仕事中寝てたな。
デスマーチはするものじゃなくて『させられるもの』だと思うな。
※1014
> 結構そいつが処理してくれることが多い気がする。
一時的には解決した気分になっても、マズイ方法な気がする。しわよせを一人に集めてるにすぎなくないか?
→ ※1015
> 結構そいつが処理してくれることが多い気がする。
一時的には解決した気分になっても、マズイ方法な気がする。しわよせを一人に集めてるにすぎなくないか?
→ ※1015
SEの設計が悪いとかよく言うけど
ソースコードのクソさ加減は設計とは関係ないな
ソースコードのクソさ加減は設計とは関係ないな
うちも仕様書Excelで作ってるんだが・・・
他のとこは何使ってるの?
ってか、他のとこのドキュメント見てみたい。
情報漏洩云々で厳しくて無理だろうけど。
他のとこは何使ってるの?
ってか、他のとこのドキュメント見てみたい。
情報漏洩云々で厳しくて無理だろうけど。
給料倍にしてくれたら残っても良い
って妥協案出してくれたスーパーマンを切るとかね
って妥協案出してくれたスーパーマンを切るとかね
まあ外から見てればPJの悪いとこなんか山ほど見れるだろ
問題は自分らがその立場になっても何も解決しないことだな
問題は自分らがその立場になっても何も解決しないことだな
※1019
そこはそいつに与える実行範囲の具合によるかなと思っている。
そいつに解決方法の提案、実行、定着等全ての責任を持たせると完全にしわよせがそいつに行くだけで絶対上手くはいかない。
あくまでそいつのやることは自由にチーム間を動かせて、解決方法の提案をチームリードに行い、後は各チームでやらせること。
またPGだったら共通化部品やコーディングのまずい部分、歪などを提案するにとどめる。実作業は各開発者やアーキチームが対応すれば良い。
一番重要なのは「チーム横断でバランスをとり、間違いを是正する」こと。サッカーで言うならボランチ的立場。あくまでバランサーに徹すること。意識付けを行わせること。
実行の責任までそいつに負わせると潰れるからそれは※1019の言うとおりになるかと。
ただこれはデスマーチの火消し策というよりかは予防策かなと。
デスマーチになってしまったらこういった遊撃部隊は機能しないことが多いのでPMチームがもっと俯瞰的に管理してかないといけないと思うな。
あとはこういった遊撃部隊をやる奴は『並』ではなく『スーパー』でないといけない。
じゃないと提案が明後日の方向になって混乱するだけだからねw
そこはそいつに与える実行範囲の具合によるかなと思っている。
そいつに解決方法の提案、実行、定着等全ての責任を持たせると完全にしわよせがそいつに行くだけで絶対上手くはいかない。
あくまでそいつのやることは自由にチーム間を動かせて、解決方法の提案をチームリードに行い、後は各チームでやらせること。
またPGだったら共通化部品やコーディングのまずい部分、歪などを提案するにとどめる。実作業は各開発者やアーキチームが対応すれば良い。
一番重要なのは「チーム横断でバランスをとり、間違いを是正する」こと。サッカーで言うならボランチ的立場。あくまでバランサーに徹すること。意識付けを行わせること。
実行の責任までそいつに負わせると潰れるからそれは※1019の言うとおりになるかと。
ただこれはデスマーチの火消し策というよりかは予防策かなと。
デスマーチになってしまったらこういった遊撃部隊は機能しないことが多いのでPMチームがもっと俯瞰的に管理してかないといけないと思うな。
あとはこういった遊撃部隊をやる奴は『並』ではなく『スーパー』でないといけない。
じゃないと提案が明後日の方向になって混乱するだけだからねw
これとか本当に同情する
ttp://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623&kw=%A4%DF%A4%BA%A4%DB
ttp://shippai.jst.go.jp/fkd/Detail?fn=0&id=CA0000623&kw=%A4%DF%A4%BA%A4%DB
今リアルタイムでデスマ中
家に帰りたいです
家に帰りたいです
俺の友人もヤバイことになってるしなぁ。1ヶ月で休み1日とか。
顧客がとんでもないとどんな有能なスタッフがいてもこういう状況になる。
顧客がとんでもないとどんな有能なスタッフがいてもこういう状況になる。
※1024
個人の能力差が非常に大きい業種だから出来る奴に出来ない奴をカバーさせる。
のは正しい気がする。
けど、多彩なプロジェクトを扱ってるソフトハウスならどうする?
環境や言語はともかく、複数のプロジェクトの業務知識を把握するのはキツい。
(電力関連、医療関連とか特に)
それに、遊撃部隊の評価は?
普通は「このプロジェクトはいくら儲けた」ってのを基準に評価するのに、
遊撃隊は所属プロジェクトが無い。
がんばっても評価されないのはマズイんじゃないの?
個人の能力差が非常に大きい業種だから出来る奴に出来ない奴をカバーさせる。
のは正しい気がする。
けど、多彩なプロジェクトを扱ってるソフトハウスならどうする?
環境や言語はともかく、複数のプロジェクトの業務知識を把握するのはキツい。
(電力関連、医療関連とか特に)
それに、遊撃部隊の評価は?
普通は「このプロジェクトはいくら儲けた」ってのを基準に評価するのに、
遊撃隊は所属プロジェクトが無い。
がんばっても評価されないのはマズイんじゃないの?
コンシューマゲーム開発もこんな感じだ。もううんざり
※1028
どうも想定している部隊のあり方に齟齬がある気がするなぁ。
遊撃部隊が所属するのはあくまで『1つの大規模プロジェクトのチームの一つ』じゃないなきゃいけない。
プロジェクト横断で遊撃部隊を作るとしたらそれはかなり間違ったことになる。
おっしゃる通り業務知識も不完全になるし、評価も難しい。
プロジェクト横断で管理するのはもっと上位のマネージャでなければいけない。
遊撃部隊(『部隊』って表現も悪いかな(笑))はあくまで一つのクライアント内の1つのプロジェクト内において自由に動き、バランスを保つのが役割。
なので業務知識としてはそのプロジェクト単一さえ解っていれば十分だし、評価も利益を基準にするのではなく彼等が提案した総数やそれによって改善された工数等を元にしてやればいい。
会社として遊撃チームを作って色々な所を見させるのは自分も反対です。
(まぁ品質向上部門を作って方針を決め、各プロジェクトに定着させることくらいなら有益だとは思うが)
プロジェクト間の整合性(P2Mではプログラム管理なんて定義されているが)は上位のマネージャが担保するべき領域であり、遊撃部隊は1プロジェクト内のバランスを保ってくださいって感じかな。
ただこの体制をとるならある程度デカイ規模じゃないと厳しいです。
要はプロジェクト内で想定されているタスクをこなす人員とは別に2,3人分のコストが増えるので。
そういう意味で『大プロジェクトのチームの1つ』になるのかんと
どうも想定している部隊のあり方に齟齬がある気がするなぁ。
遊撃部隊が所属するのはあくまで『1つの大規模プロジェクトのチームの一つ』じゃないなきゃいけない。
プロジェクト横断で遊撃部隊を作るとしたらそれはかなり間違ったことになる。
おっしゃる通り業務知識も不完全になるし、評価も難しい。
プロジェクト横断で管理するのはもっと上位のマネージャでなければいけない。
遊撃部隊(『部隊』って表現も悪いかな(笑))はあくまで一つのクライアント内の1つのプロジェクト内において自由に動き、バランスを保つのが役割。
なので業務知識としてはそのプロジェクト単一さえ解っていれば十分だし、評価も利益を基準にするのではなく彼等が提案した総数やそれによって改善された工数等を元にしてやればいい。
会社として遊撃チームを作って色々な所を見させるのは自分も反対です。
(まぁ品質向上部門を作って方針を決め、各プロジェクトに定着させることくらいなら有益だとは思うが)
プロジェクト間の整合性(P2Mではプログラム管理なんて定義されているが)は上位のマネージャが担保するべき領域であり、遊撃部隊は1プロジェクト内のバランスを保ってくださいって感じかな。
ただこの体制をとるならある程度デカイ規模じゃないと厳しいです。
要はプロジェクト内で想定されているタスクをこなす人員とは別に2,3人分のコストが増えるので。
そういう意味で『大プロジェクトのチームの1つ』になるのかんと
ユーザー:『「スペースシャトルの打ち上げは出来ない」って書いてないから当然できるよね』
ユーザーが自分で何言ってるかわかってない時とかは
もう撤退以外道はない
何出しても苦情が……
ユーザーが自分で何言ってるかわかってない時とかは
もう撤退以外道はない
何出しても苦情が……
みんなわかってるのになんで解消されないんだろうな。
・顧客がシステムを稼動させる気がない
予算を消化しないといけないから、トップ同士の会談で決まったから、担当者が専門じゃないなんかは、頼んでおいたドキュメントもアクションも期日までに出てこないことが多いような気がする。
でも納期は決まってるとかで見切り発車しておいて、爆弾がそこかしこに残されたまま何もかも進んでおいて、デスマーチに突入してるように思う。
・顧客がシステムを稼動させる気がない
予算を消化しないといけないから、トップ同士の会談で決まったから、担当者が専門じゃないなんかは、頼んでおいたドキュメントもアクションも期日までに出てこないことが多いような気がする。
でも納期は決まってるとかで見切り発車しておいて、爆弾がそこかしこに残されたまま何もかも進んでおいて、デスマーチに突入してるように思う。
>1032
そんなとこじゃない?
ワザとやってる訳じゃないんだけど。やっぱり顧客側の担当者自体の専門性とやる気に左右されると思うな。
顧客側も本来なら製作物の確認をチマチマやったり、本当に必要な仕様を予め予測して、その上で納期を決めるべきなんだろうけど。
その予測よりも先に予算と期限ありきで進んでしまっている。
で担当者もマズイと分かっていたとしても、責任転嫁が出来ると言うことで丸投げって感じかな。
顧客側の担当者とさらにその上の決定を下した人物との意思疎通さえ上手くいってないと言うことだろう。
だから顧客側の組織が大きくなるにつれてマズイケースが増えるんだと思うな。
そんなとこじゃない?
ワザとやってる訳じゃないんだけど。やっぱり顧客側の担当者自体の専門性とやる気に左右されると思うな。
顧客側も本来なら製作物の確認をチマチマやったり、本当に必要な仕様を予め予測して、その上で納期を決めるべきなんだろうけど。
その予測よりも先に予算と期限ありきで進んでしまっている。
で担当者もマズイと分かっていたとしても、責任転嫁が出来ると言うことで丸投げって感じかな。
顧客側の担当者とさらにその上の決定を下した人物との意思疎通さえ上手くいってないと言うことだろう。
だから顧客側の組織が大きくなるにつれてマズイケースが増えるんだと思うな。
デスマになるかならないかなんて、客(元請ならユーザ、下請なら元請)と話をする人間が頭良いか悪いかだろ
話しに行くぐらいだから当然プロジェクトには上の方の立場で関わるだろうし
でも、丸投げする元請が無くなれば、デスマのほとんどはなくなると思うわ
話しに行くぐらいだから当然プロジェクトには上の方の立場で関わるだろうし
でも、丸投げする元請が無くなれば、デスマのほとんどはなくなると思うわ
Fの件に力強く同意!
役に立たん罫線excelとか思い出してワロタwwww
今は一応笑えるけどさー、未だに余波で働くこと自体が怖いわorz
役に立たん罫線excelとか思い出してワロタwwww
今は一応笑えるけどさー、未だに余波で働くこと自体が怖いわorz
裁量労働(笑)とか実力主義(笑)を盾に使って
見積もりの失敗を下に押し付ける気が最初からまんまんだからな
課長レベルの暴走でわざと死なない程度に無理なスケジュールにしてくる
見積もりの失敗を下に押し付ける気が最初からまんまんだからな
課長レベルの暴走でわざと死なない程度に無理なスケジュールにしてくる
CTCとかNTTDとかクソの代名詞。
こいつらから降りてくるクソ会社の我々の身にもなってほしい。
こいつらから降りてくるクソ会社の我々の身にもなってほしい。
>119 仕様書無しさん :2008/09/13(土) 14:54:16
>責任感無い人この業界多いよな?
>
>それがデスマの原因だろ。
それは原因ではなくて結果。
責任感ある人は、転職するか過労死でいなくなる。
>責任感無い人この業界多いよな?
>
>それがデスマの原因だろ。
それは原因ではなくて結果。
責任感ある人は、転職するか過労死でいなくなる。
OK,全く同じ経験をした俺が通る。現在鬱病で休職中です^p^
うちの会社はFとかIじゃないけど似たようなもんだぜ?
そろそろ本気で転職を考えようとしてる俺がいる
うちの会社はFとかIじゃないけど似たようなもんだぜ?
そろそろ本気で転職を考えようとしてる俺がいる
SE時代の同期といまでも時々飲むんだが、自分も含めもう10人中8人は転職してる状態なんで
元会社の悪口で盛り上がる盛り上がるw
まぁいまは景気悪くなっちゃったから、
転職したいと思ってるやつはもうちょっと辛抱したほうがいいかも
元会社の悪口で盛り上がる盛り上がるw
まぁいまは景気悪くなっちゃったから、
転職したいと思ってるやつはもうちょっと辛抱したほうがいいかも
Nでデスマった俺は少数派?
上も下もどうしようも無いってのがIT業界の現状
中小IT会社じゃ案件をこなせないからな
それこそ1人の負担が重くなってデスマ確定
中小IT会社じゃ案件をこなせないからな
それこそ1人の負担が重くなってデスマ確定