失敗・炎上に名前をつけることで、僕たちはもっと強く、生産的になれる。 - Qiita
TL;DR 起きた失敗、炎上には名前を付けよう。 名前を付けることで似たような問題が見えやすくなる。 名前を付けることで問題に取り組みやすくなる。 名前を付けないと、見過ごされ対策されずに過ちを繰り返す。 「要望真に受けて無事死亡パターン」という名前の力 システム開発において、ユーザ要望を文字通り実装することは、 バッドノウハウであることは、読者諸賢は十二分にご存じかと思う。 しかし、これが意外と撲滅されない。 特に若手やリーダー1年目が良くやらかすから、組織としてごくありふれた失敗事例となる。 そんなある日、 「それってよくあるパターンで、名付けて”要望真に受けて無事死亡パターン”だよね。」 という話をしたら若手から、 「そういうあるあるパターンにキャッチーなネーミングを付けて普及させたら、 失敗も減るんじゃないですかね？」 という素晴らしい提案を受けた。 ジョシュアツリーの法則 これは
P"r"aying Manager ～節子、それマネジメントちゃう。オカルトや～ - Qiita
はじめに 最近、社内外の多くのプロジェクトマネジメント実態を調べる機会に恵まれた。 その中で、面白いことに気がついた。 問題に直面して、原因を分析しなければ、対策も取ろうとしないマネージャ達。 彼らはマネジメントしていない。ただ祈ってるだけ。 つまり、P"r"aying Manager じゃね？と。 ※Pray ・・・ 祈る Praying Managerの生態 [ケース1] 進捗をPGが自力で回復してくれることを祈る あるプロジェクトでは、3ヶ月の工期のうち、1ヶ月が経過したが、進捗が半月分しか出なかった。 つまりプロジェクトとしては破綻状態であるわけだ。 このことについてマネージャは、 プロジェクトの最初は立ち上がりが悪く、進捗が出ないものなんです。 対策はいずれメンバのスピードが上がってくればという感じですね。 と回答し、なにも手を打たなかった。 （最終的には会社が介入して正常化を図
もしかしたらコードメトリクスこそが、僕たちを救ってくれるかもしれない。 - Qiita
結論 コードメトリクスの一つ、保守容易性指数と、バグ発生率とに、相関の兆候を見つけた まだ下調べの段階だけど、大規模調査および統計的検定の結果、 保守容易性指数とバグ発生率との相関が認められたら、 保守容易性指数をKPIにすることで、数値的品質評価・管理ができるかもしれない バグをまき散らすけど手が早いエンジニアの影に隠れて、 丁寧にモノづくりをしているけどいまいち評価されていないエンジニアに、 日の目をあてられるかもしれない。 バグ対処コストと保守容易性とを掛け合わせることで、 技術的負債を金銭的評価ができる可能性がある 金銭的に評価できれば、返済に関して、ビジネスサイドと有意義な議論ができる可能性がある はじめに 僕ら(@gakuri、@ahera、@yukke7624)は、とあるSI会社で横断的にプロジェクト支援をしている。 マネジメント状況の監査、支援、テコ入れから、技術的アドバイ
Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita
初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
