>>922 時間があればあるほどクライアントの要求はすさまじくなる罠。
彼らの欲望は果てしない……
時間が無くても要求だけは出続ける。
奴等の欲望は果てしない……
>>922 低脳も、時間が足りなくなる原因なんだよ。
最初からそれを計算して予算を取ってるなら確かにデスマになりにくいけど、
低脳価格じゃ他社に仕事持って行かれないか?
>>921 そもそもわれわれは人間扱いされて '`,、('∀`)'`,、
休憩時間中です。
デスマの原因はかなりの会社のマヌケさが原因です。
1.スケジューリングが無茶なのに人員をさいてくれない。
2.開発環境がないため別ユーザの開発環境を間借りしている。
3.顧客の要望が絶えず変化する。(仕様書は凍結し承認を得ているにもかかわらず。)
もうどうしたらいいかわかりません。
>3.顧客の要望が絶えず変化する。(仕様書は凍結し承認を得ているにもかかわらず。)
契約違反。裁判所へどうぞ。
例えプロジェクトが打ち切りになっても凍結後の仕様変更に関する追加料金は取れる
つ[三十六計逃げるにしかず]
>>930 俺なら、まず最初の仕様(凍結承認済)をまず作りあげる。
で、途中に発生した仕様変更・追加案件は打ち合わせだけ
して、現在の開発物には絶対反映させない。
#先を見越して組み入れる事はあっても、客先からは
#絶対見えない様に留意する。
こうすれば、凍結仕様に対する納品は予定通りに
出来るだろうし、変更・追加分に対する見積もりも
出しやすくなるだろう。
絶対やってはいけないのは、
「.仕様変更をいつまでも受け入れて、開発完了がドコか
#ドコまで作成すれば完成なのか?
が曖昧になる事。」
こうなってしまうと、最初の受注金額の中にすべての
仕事が織り込まれてしまい、大赤字プロジェクトへ
真っ逆さまに落ちるはめになる。
客先との力関係、その他しがらみで全てこう言う
訳には行かないとは思うが・・・・・・・
>>934 とはいえ、そこまでして実行しないと、客は絶えず仕様変更を出してくる。
なんでも言うこと聞く
>>934 はどのような対策をしてるんだ?
ただの煽りか?
おまいら、もう少し建設的な科白を吐けんのか?
>>933 たとえば、凍結したはずの仕様がどうしようもなく間違ってたら?
個人的な経験の範囲では、設計だけで妥当性が証明できたケースはなかった。
(必ず後で直しが必要だった。妥当性を確認する現実的な手法を持っている人もいなかった。)
完璧に設計してそれで凍結、というのは難しい。だからXPやアジャイル。
仕様変更はあって当然と言う認識の人もやはり多い。そもそもなぜなのか?
前述したとおり、設計だけで確認する方法がない。訓練もされてない人が設計する。
仕様変更は、顧客のわがままだけでなく、再設計の作業でもある。
だから、あって当然できないと困る、実装段階で吸収させればよい、という対応が一般的。
実装段階で吸収?赤字にならないのか?仕様変更は本当に赤字の要因なのか?
デスマーチはサービス残業や外注締付でバッファリングされるので、
デスマ即赤字とはならない。
「システム開発は(末端作業者なんてむしろ)デスマーチで当然」と平然と言う人間もいる。
部下や外注など立場の低い人間を終端の作業に配置しているのにはわけがある。
釣られて書いてみた。
わからんでもないが、当事者の身にもなってみろと。
えー…
もう2ヶ月ほど家族の顔みてません。
付き合っていた彼女には振られました。
(ちなみに婚約してました…)
オレの精神が崩壊するのも時間の問題です…
934=936=938の罵倒の結果が
>>940か?
人間社会に暮らしていける自信ある?
>>940 やってみなければわからんからデスマは当然だということですね?(笑
せめて
やってみにゃわからんからウォーターフォール型開発は糞っつー結論ならわかるんだがなぁ
>>946 940書いたけど、934とか936は関係ないよ。
自分は仕様変更でデスマにおちいらされるPG側の人間。
仕様変更なければそれは良いんだが、現実なくならない理由を書いてみたんだが・・・。
他にもたくさんの理由があると思う。
>やってみなければわからんからデスマは当然だということですね?(笑
ニュアンスが微妙だけど、今の設計手法ではその通りなのではないかと思う。
そうでなければ、小さくイテレーションを繰り返すXPやアジャイルのような
発想は生まれなかった。
けっこう建設的に書いてみたつもりだったけど、
結局煽りしか返ってこないようなのでもうやめ。
言ってる事が中間管理職だからなー
現実書くだけで自分なりの解決策をださなけりゃ、煽られた連中から煽り返されて当然だろ。
これで建設的な書き方なら、もちっと色々本読んだほうがいいぞ。
>> 948
「建設的」とはどういうことか、今一度確認してみる必要がありそうだ
なにやら盛り上がっている様で、
>>940 あなたの言っている事も理解は出来る。
私もかつては(今も似たような物だが)
末端PGとしてデスマの先頭をひた走った事もあった。
その時のデスマの原因では
1.SEの書いためちゃくちゃな仕様書
#要求定義どころか、システム規模も把握
#していなかった。
2.客先打ち合わせに入る前に納期・受注金額決定。
が多かった、昔話はこれくらいにして個別の私の考えです。
>たとえば、凍結したはずの仕様がどうしようもなく間違ってたら?
間違っていると言う認識を、客先にも持ってもらう事が肝要です。
仕様定義は客先と共に作り上げる物、結果が間違っていたら
双方が責任を取る、つまり客先は追加料金を、我々は割り引いた
追加料金や、納期に間に合わせる為のデスマ状態を受け入れる、ですね。
とは言え、客先からは
「お前ら、プロなんだろ?、なんでこんな事が判らなかったんだ?」
とか
「私ら素人なんだから」
とか、責任を何とか回避すべくあれやこれや画策してきます。
客先のこれら逃げ口上を、事前に防ぐ事を常に頭に置いて行動する様にします。
=============本文が長すぎる、と怒られましたので、2つに分けます================
952 :
933:04/10/16 20:36:05
続きです。
>仕様変更はあって当然と言う認識の人もやはり多い。そもそもなぜなのか?
>だから、あって当然できないと困る、実装段階で吸収させればよい、という対応が一般的。
基本的に私は、「仕様変更の無くなったシステムは、もはや死んだシステムだ」
と思っています。
#生きてるシステムなら、仕様変更があるのは当たり前。
実装段階で変更になった部分については、先に書いた通り双方が責任を取れる
様にし向けて置きます。
>デスマーチはサービス残業や外注締付でバッファリングされるので、
この一文については、賛同できません。
こんな事をしていればいずれ共倒れします。
#現実には発生している事だとは知っていますが、出来ればなんとかしたいと
#考え、行動し続けてはいます。
>「システム開発は(末端作業者なんてむしろ)デスマーチで当然」と平然と言う人間もいる。
末端作業者の「デスマ上等」は有り。と思います。
#そう言う経験もある程度必要、と考えます。
ですが、いずれ末端より地位が上がった時の事を少しづつでも考えておく事
は無駄ではないと思います。
主張の中心と思える部分を抜き出して引用しましたが
ココの部分の回答がねぇ!、と言う部分がありましたら
指摘下さい。最後に長文失礼しました。
全ての国民は健康で文化的な生活をする権利を有する
955 :
仕様書無しさん:04/10/17 02:16:01
携帯スレに約1名、このスレと間違えて迷い込んでいる者をハケーン。
956 :
仕様書無しさん:04/10/17 02:58:08
>947
んじゃ、俺が今この時刻に会社ではまっている
「ウォーターフォール型人海戦術インパール作戦」
なんかどうなっちゃうの?
人海戦術というだんかいで、インパールじゃないだろう。
人海戦術なんて取れるのは人民軍くらいじゃないか?
WW2ならソ連軍くらい?
>957
それでも現在の方が恵まれてるよ。
PCは一人一台だからね。
あの当時は二人に小銃一丁だからね。
デスマーチとかけて
デスマッチととく
そのこころは
死ぬまで抜けれない
>>960 デスマッチはレフェリーいるからまだイイ・・・・
長 征 λ............
会社で氏んだってのは聞いたこと無いな。
漏れの周りでは家に帰って安心したとこで氏んでる。
まぁ死人が普通に出てる時点で酷い会社なんだが。
開発の環境設定を含むソフトウェア管理やネットワーク設定を行う香具師が逃げた。
月曜日から連絡をしないで出勤してこない。
今日はサブリーダーが倒れて休んだ。明日は出勤すると話していた。
・・・やばい前兆かな?
>966
チョト憧れないでもない
そういえば同僚が朝冷たくなってたことがありました。
会社は過労死を認めませんでしたが…
もうだめだねあの会社は…
ども。休憩中です。(何日ぶりだ?)
相変わらず上司がフォローに入らずまったく不眠不休で孤軍奮闘してます。
なぜか倒れないのですが医者にいくべきでしょうか?
倒れてから入院をすると上司がきっと喚いて、使えない奴だ。頸にしてしまえ。
と言うのが目に見えているので、先行して辞表を書くべきだと思う。
>>970 何のために、そんなに頑張ってるのでつか?
ここ数週間土曜出勤が続いている。
日曜日はビルがロックアウトされるために入れないのでその分確実に1日休める。
でもなぜか韓国人と中国人は土曜に出てこない。
理由をリーダーに尋ねた。
「文化が違うからね。」
とかえってきたよ。
俺も違う文化で育ちたいと思ったorz