アカウント名:
パスワード:
この頃は単に遅れているってだけでデスマと言う人間が増えている様に思えるけどね。
私の言うエンドってのは締め切りではなく、作業終了見積りです。
これが客の指定した納期よりも先であったとしても、実際に終わる目処が立っていればそれは、それは単なる作業遅れか期間の見積り過少であって、所謂「デスマ」では無いんじゃないかと。
ですから、そういうある程度の目処が計算できるようなプロジェクトは、負担過多であったとしても「デスマ」とは言わないかと。
＃もしかしたら、この頃の人はそういう本当に目処の立たないプロジェクトって関わった事が無いのかな？ ＃であれば、「デスマ」の声は増えてはいるが、実は業界的には改善しているって事かも。
そういう時であっても、スケジュールを見直し現実的にするなり、仕様を一部変更してスケジュールをあわせるなりする事で対処出来ますから。 客のエンドと言っていても、本当の意味でのエンドってのは実はそれほどあるものではなく、実際は担当者の面子の問題だけだったりするのが往々にしてあります。 前述の例でしたら、そもそも、新システムの立ち上げと旧システムの保守切れの間が少なすぎるってのが問題だと思いますが、その辺りの問題ってのは、それであっても、旧システムを少々維持したり（それだって交渉しだいでは可能）すれば、十分に対処できます。 世の中、頭を下げて、真摯に現実的対応方法を探す気にさえなれば、方法は見付かる物です。 ＃とは言っても、客側担当責任者が真摯に考える気が無ければ無理だけど。 ＃それすら出来ない担当者と付き合うのは無意味だから、そういう場合は「なるようにしかならん」と突っぱねるしかないが。
ってよりも、その程度で致命的って事でしたら、流石に世の中は立ち行きませんって。
でもって、そういう対処を行うにしても、それがどれだけの期間を必要とするかが見積れないと出来ないし、見積れていればその対処方法は選択・実施すれば良いだけの話に過ぎません。
ってか、「デスマーチ」なんて言葉自体が、前述の「客のエンドより遅れたらアウトです。」なんてのが実は全然致命的で無い事を表している訳なんですけどね。 アウトであれば投げ出すしかないのだけども、どうにかフォローの目があるから続ける訳ですから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
普通は (スコア:3, 興味深い)
この頃は単に遅れているってだけでデスマと言う人間が増えている様に思えるけどね。
Re:普通は (スコア:2, 興味深い)
・残作業量が見合っているかに関係なく期間が決まっている
・期間的に不明確だが、残作業量は概ねわかっている
・残作業量にみあった期間が解っている
のどれなんでしょうね？
昔火消し役で、残期間1ヶ月でPG2000本修正(汎用機のDB用COBOL PGをOracleDB用に修正する程度の修正)しなきゃならないプロジェクトに投入された・・・これってエンドは見えているのでしょうか？？？
Re:普通は (スコア:2, 興味深い)
私の言うエンドってのは締め切りではなく、作業終了見積りです。
これが客の指定した納期よりも先であったとしても、実際に終わる目処が立っていればそれは、それは単なる作業遅れか期間の見積り過少であって、所謂「デスマ」では無いんじゃないかと。
ですから、そういうある程度の目処が計算できるようなプロジェクトは、負担過多であったとしても「デスマ」とは言わないかと。
＃もしかしたら、この頃の人はそういう本当に目処の立たないプロジェクトって関わった事が無いのかな？
＃であれば、「デスマ」の声は増えてはいるが、実は業界的には改善しているって事かも。
Re:普通は (スコア:1)
どんなに遅れてもその期間がくれば終了なわけで、エンドは見えていますね。
・期間的に不明確だが、残作業量は概ねわかっている
わかっているなら、それを終わらせればエンドですよね
・残作業量にみあった期間が解っている
わかっているだけじゃどうしようもない事だってありますが、
この場合２番目の「残作業量がわかっている」にも合致するので一応エンドは見えているはず。
ある時点において"本当に"エンドが見えない=エンドがない事なんて相当稀な事だと思いますよ。
# 永遠に続くかの如き仕様変更大量発生プロジェクトとかでもない限りは。
## …何？それがデフォ？そんな馬鹿な！嘘だと言ってよ！
エンドが見えない状況はまさにデスマーチだけど、エンドが見えてても「無理難題なエンドに、それとわかりつつもエンド到達のためプライベートを犠牲にしてでも尽力しなきゃいけない状況」がデスマーチであり、リソース不足はそういう状況の原因であって半分とか云々は全然意味の無い定義なんじゃないかなぁ…と思ってます。
Re:普通は (スコア:1)
>しなきゃならないプロジェクト
その2000本が2000本で済むかどうか、まだ増える可能性が高いならエンドレス（≒デスマーチ）
でしょう。仕様がFixしているかどうか。
# お客さま仕様がFixされるというのはただの幻想で、お客さまが諦めるってのが正解
---- 何ぃ！ザシャー
Re:普通は (スコア:0)
2000本修正すればエンドです。
多かろうが、少なかろうが、数えられるならばエンドは見えるでしょ？
Re:普通は (スコア:2, 興味深い)
客「コレと同じ動きをするのが絶対条件で、さらに仕様追加したものを作ってね♪あと開発言語は変えてちょ♪」
俺「以前作成したときの仕様書を見せてください。」
客「ナニソレ？そんなの無いよ。」
俺「・・・・じゃあソースコードを見せてください。」
客「ナニソレ？そんなの無いよ。」
手元にあるのは古い膨大なバイナリのみ。古すぎて開発環境が無くなっていました。
以前のソフトは数百コマンド位があり、同じコマンドでも組み合わせや入力データによって処理の仕方を変えている様でした。
過去の互換性を捨てフルスクラッチした方が、安くて短時間に高性能なソフトが出来ると訴えても、決して通りませんでした。
そして人も予算も増えず、先がまったく見えないまま、一年格闘しました。
思い出すだけで欝になる、アレこそが真のデスマーチだったと思います。
Re:新しいシステムを発注しよう会議 (スコア:0)
上司「じゃあ、今までと同じので、○○機能を追加して新規発注しろ」
発注担当「互換性なくして、新しく作り直した方が安くて早いかと」
上司「金がないのに予算が増やせるか。今のが故障する前に作れ」
担当「古い個体ですので、移植は不可能と思われますが」
上司「何を言うか！今までのものは今まで通りで、プラス新機能だ！」
担当「しかし、仕様書とソースがスパゲティ状態で」
上司「新しいことを覚えるのは嫌だ！今まで通りが絶対条件だ！」
担当「・・・・・・・・・・わかりました・・・」orz
そして、何社ものソフトウエアメーカーに見積もりを取り、
長年繰り返した機能追加と変更で、百冊以上に積み上がった仕様書とソースを前に
数多のメーカーが脱落して、最後は古いシステムのメーカーにまで断られました。
この程度の予算と納期でそんなわがままが通るかっつーの糞上司！
# 実話なのでAC
Re:中の人がデスならデスマーチ？ (スコア:1, 参考になる)
代替えシステムの場合、旧システムの保守切れ、ハード・ソフトのサポート切れが
客のエンドになり、それより遅れたら開発サイドでは対処できません。
開発が遅れまくって客のエンドにも間に合わないプロジェクトで、
まったく別プロジェクトを立ち上げて、旧システムを延命した話を聞きました。
開発部門の精鋭を引き抜きまくって、他のプロジェクトに多大な迷惑を掛け、
大赤字だしながらもなんとか社内で納めたらしいです。
以前のストーリー [srad.jp]でも話題になってましたが、
個々の社員には辞めるという選択肢があっても、
会社が受けた仕事がなくなる訳ではありません。
デスマーチは、中の人が死にそうになることじゃなくて、
企業として受けた仕事を反故にすることだと思ってました。
または、その状態に向かってプロジェクトが破綻することで、
会社の面子のために社員が犠牲になるから「デスマーチ」なのかと。
# wikipediaの定義やみなさんのコメント見たら、全然違くてびっくり。
# 死ぬほど働いたプロジェクトもなんとか間に合ったからデスマーチだと思わなかった。
Re:中の人がデスならデスマーチ？ (スコア:1)
そういう時であっても、スケジュールを見直し現実的にするなり、仕様を一部変更してスケジュールをあわせるなりする事で対処出来ますから。
客のエンドと言っていても、本当の意味でのエンドってのは実はそれほどあるものではなく、実際は担当者の面子の問題だけだったりするのが往々にしてあります。
前述の例でしたら、そもそも、新システムの立ち上げと旧システムの保守切れの間が少なすぎるってのが問題だと思いますが、その辺りの問題ってのは、それであっても、旧システムを少々維持したり（それだって交渉しだいでは可能）すれば、十分に対処できます。
世の中、頭を下げて、真摯に現実的対応方法を探す気にさえなれば、方法は見付かる物です。
＃とは言っても、客側担当責任者が真摯に考える気が無ければ無理だけど。
＃それすら出来ない担当者と付き合うのは無意味だから、そういう場合は「なるようにしかならん」と突っぱねるしかないが。
ってよりも、その程度で致命的って事でしたら、流石に世の中は立ち行きませんって。
でもって、そういう対処を行うにしても、それがどれだけの期間を必要とするかが見積れないと出来ないし、見積れていればその対処方法は選択・実施すれば良いだけの話に過ぎません。
ってか、「デスマーチ」なんて言葉自体が、前述の「客のエンドより遅れたらアウトです。」なんてのが実は全然致命的で無い事を表している訳なんですけどね。
アウトであれば投げ出すしかないのだけども、どうにかフォローの目があるから続ける訳ですから。
Re:普通は (スコア:0)
時間的なエンドは見えてます。(へたすりゃ、過ぎている)
でも、納品物のエンドは永遠に見えません。
＃その前に仕様決定のエンドが納期を越えているときが‥