ホウレンソウに頼らないマネジメント - もぎゃろぐ
Twitterのつぶやきを見ていたら、わりと常識に縛られないタイプの方なのに、「新人研修で覚えてもらうのはホウレンソウとプログラミングくらいかなぁ」的なことを言われていて。そういえばホウレンソウって必須でもなんでもないことは意外と知られていないなぁ、と思ったので書いてみる。 ホウレンソウに頼ったAくんの仕事の進め方 9:00 業務開始。朝Mtgで、その日やることをみんなの前で発表。ぼく早くプログラム書き始めたいんだけどな... 9:30頃 昨日の進捗報告に上司からツッコミが。詳細な説明を書いて返信する。 10:00頃 ようやくプログラムを書き始める。 12:00 お昼休み。 13:00 再びプログラムを書き始める。 14:00 今朝のメールに上司は納得しなかったらしく、呼び出された。状況を説明してようやく納得してもらう 15:00 えーと。何してたんだっけ。あれ。このあと進捗会議か。 1
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
既存のプロジェクトマネジメント手法の落とし穴とは？
既存のプロジェクトマネジメント手法の落とし穴とは？：プロジェクトは「やる気」で成功する（1）（1/2 ページ） これまでも数々のプロジェクトマネジメント手法が考案されてきたが、現在も数多くのプロジェクトが失敗に終わっている。それはなぜか？ 制約理論を提唱したエリヤフ・M・ゴールドラット博士は工学的な視点で既存手法の問題点を指摘したが、竹之内隆氏は人間的な見地から既存手法の新たな落とし穴を指摘する。 人は論理のみでは動かない、動かせない 複数のメンバーが参加するプロジェクトをスムーズに遂行するためには、計画を策定するプロセス、それを実行するプロセスの両方において、全関係者が足並みをそろえなければなりません。そのためには、論理的な戦略と、それに基づく漏れのないWBSが不可欠とされています。しかしそうした要件を満たしていても、現実には数多くのプロジェクトが失敗に終わっています。 なぜうまくいかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
