ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
企業内でWiki活用の効果はどの程度? | スラド IT
営業部と技術部で違うのかもしれません... 自分達の事業部は営業チームと技術開発チームと制作チームに別れていたのですが、 ３つきれいに分かれました。 自分が居たところの実体と、それについて思ったことなので、違うパターンがあったらぜひ教えてください... 技術開発チームは積極的にネタを書きこんでコラボレーションを図る土壌があって、積極的。wikiが繁栄しやすい。 ネタ探しが辛くなると積極的にネタを突っ込んでおいて予防線を張り合うので、そこそこ情報が集まる。 営業チームはwikiで書こうがeメールで書こうが、結果 「～～について考査いたしましたのでよろしくお願いします」 という全体配信メールを打って、結果やフィードバックをメールで全部見る（メールで時系列管理したがる）ので、 あまり激しく繁栄できず、またノウハウを開示してしまうことになるので警戒しあって誰も おいしいところを書きたがらないので、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
