上司様、どうか家に帰ってください。 フロアの半分以上が22時以上に残っていないでください。 見てる、私の将来も不安になります。
嫁や子供が居る人はソフトウェア開発の仕事をするなという警告
上司様、どうか家に帰ってください。 フロアの半分以上が22時以上に残っていないでください。 見てる、私の将来も不安になります。
その後の顛末 - ブログは死なず、ただ放置されるのみ。
そういえば、この件は触れたくなかったような気もするが、とりあえず書いておく。 今の前のプロジェクトで見事にデスマーチを演出してくれた某社のプロジェクトマネージャーさんが、今の案件から担当を外されたそうです。 風の噂レベルの情報なので、想像するしかないのですが、その某PMさんは体育会系で「とにかくなんとかするんじゃあ」みたいな人で、仕事のやりかた（アウトプットではなく）も細かいところまで「こうしろ」と強制する方で、自分の得意技が封じられた状態で仕事をさせるという、結構最悪な方でした。紳士でしたけどね。 で、担当を外された理由を聞いてると、どーも話を聞いてると、顧客要求に対し「それはできない」を連発したからなんだそうですが、前のデスマーチ経験を生かして実際に作ることができないと見えていることを率直に具申されたから外されたのなら、寂しい話だと思いました。「やります」という担当がでてくるまでぐるぐ
デスマーチの中で演じるべきは「火消し」ではなく…… / ただただし＠「ただのにっき」のエンジニアいとをかし／Ｔｅｃｈ総研
興味深い体験談を読みました。デスマーチについて考える前にデスマーチの経験を書くとその続編デスマーチについて考える(デスマーチ経験のエピローグ)です。 デスマーチ経験者がその「当時」を振り返るのは、戦争経験者が体験談を語るかのようなもので、懐かしがっているようにも感じられる面があるものの、やはりその悲惨な状況は、涙なくして読めません。同じ経験者がそれを読んだり聞いたりすると、なんだか戦友の話を聞いているような気になってしまうものですね。 さて、このkshさんはいわゆる「火消し」としてプロジェクトに投入されたわけですが、「火消し」といってもいろいろあるものです。一番ひどいのは現場に爆発物を仕掛けて一気に消火を狙うタイプで、跡地には何も残らなかったりします。一方、火の出ているところをきちんと見極めて、地道にかつ確実に火を消していくタイプの人は、多少時間はかかっても結果的によい成果を残す、よい火消
デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ！ ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが（幸運にも！）教えてくれても、それが議事録に書かれることはなかった。 受けたプ
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
