Manage It! 現場開発者のための達人式プロジェクトマネジメント

プロジェクトマネジメントに関する良書。正直言うとアート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)のほうがいいとは思うが、それと比べるとTipsやハウツーが豊富というかテクニカルな印象がある。
なかなか示唆に富むというかニヤリとするような箇所もある。たとえば以下のような感じ。

どのケースでも、チームメンバー自身は作業の90%が完了したと思い込んでいるが、実際には終わらせなければならない作業があと90%残っている。これが「90%完了」のスケジュールゲームだ

あー、あるある。。。

彼はさっと舞い降りてきて、PowerPointによるアーキテクチャ図という糞をどっさり放出すると、すぐに去っていった。

これは見たことないな。

うまくやれていない人がいたらチームから外せることがプロジェクトマネージャには必要だ。それができないなら代替策を検討しよう。あなたが別のプロジェクトに移るとか、その組織から出ることを考えたほうがいいかもしれない。

これができる人はあまりいないんじゃないかと思うが。。。

結局、たいして聞く話もないし自分が貢献することもない会議の末席に連なっていたって、自分の職務を果たしていないだけだ。

確かに。

メンバーたちの間の距離が30メートル以上あるプロジェクトは、すべて地理的に分散したプロジェクトである

確かに。

マルチサイトチームの黎明期には次のように考えるマネージャが大勢いた。「私のチームはグローバルに展開して作業している。プロジェクトが24時間前進してるってことだ」甘い話はない。世界中に展開するチームで進捗できるのは、イノベーションを起こすつもりがなく、開発コストを気にしないプロジェクトだけだ。

実を言うと、このセクションは「アウトソースを成功させる方法」というタイトルにしたかった。しかし、そうするわけにはいかない。これまで筆者はアウトソースしたプロジェクトで本当に成功を収めたとは言えないからだ。

やっぱ難しいよね。

生産性は必ずしも経験に比例しない。優秀な開発者とテスターは年長者とは限らず、経験年数が長いとも限らない。生産性は自己鍛錬と理解力による部分が多く、解決策のドメインに精通していることも重要だ。スタッフの能力にはかなり幅がある。

だよねー。