トム・デマルコのレビュー一覧
-
Posted by ブクログ
いいパターンとアンチパターンがまぜこぜになっているのに気づくまで、ちょっと混乱というか読みにくかったです。
読んでいる最中にtwitterに書いたのをまるっとコピー。
「 "いい本"だと思うけど、自分の耳に心地好いパターンだけにうなずいているだけと"役に立った本"にならない予感。86パターンの中には耳が痛いものがあるはずで、それについて考えないと。 自戒を込めて。」
で、読むだけだと「あー、あるある！」で終わっちゃいそうなんだけど、この本を使ってMorning Beeをやったらなかなか良かったです。というわけで、読んだ後に人と話すのがオススメ。
-
-
-
-
Posted by ブクログ
2006年に一度読んだことがあるみたいだが記憶になかった。2016年に再読。プロジェクト管理をそこそこしてきた今だから納得できるし発見がある、読んでよかった。トムキンス、ラークサー、NNL、ベリンダ、無理矢理な導入と結末。
・正しい管理の本質、適切な人材を適所にあてはめ人々の士気を保ってチームの結束を強め維持する。
・リスクを管理することによってプロジェクトを管理せよ。
・プレッシャーをかけても思考は速くならない。
・管理者の怒りと侮辱は伝染する。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・入出力の完全なリストのない仕様書は、見込みなしであ -
Posted by ブクログ
以下、ポイント
マネージャーの役割は、人を働かせるのではなく、働く気にさせること。
精神集中状態、フロー状態になるには15分以上の精神集中過程が必要。電話が鳴る、誰かが話しかける職場では困難。
何カ月、何年の作業時間が、右脳のアハたいけアイデアにより解決する場合がある。音楽は右脳を占拠するので閃きを邪魔する。
人は基準から外れた人を恐れる。だから会社は同じような人を採用する。
チームの誇りはメンバーか成し遂げた成果。服装や髪型は関係しない。
リーダーシップとはサービス。自ら仕事を引き受け、準備をし、メンバーに価値を与える。ユーモアと善意の元に事にあたる。
結束したチームは、一体感がある。楽しい -
Posted by ブクログ
ネタバレ物語形式で展開される、とあるソフトウェア開発の物語。
さまざまな出来事により、プロジェクトマネジメントの要衝のおさえかた、実行の仕方、ものごとの進め方を学べる一冊でした。
読者がソフトウェア開発プロジェクトに関与しているなら、とても共感できる部分が多いと思います。
たとえば残業時間と生産性の話や、無駄な会議を減らす方法など。
また私自身、自分の経験をうまくあらわせなかったことが整理されていて役立ちました。特に設計段階は少人数で進め、製造で一気に人を投入するあたりは、うまくいったプロジェクトでも同じでした。頭を使うフェーズは、人が多すぎると「船頭多くして・・・」になりかねないと再認識です -
Posted by ブクログ
備忘録。
部下に大きなプレッシャーをかければ、もっと働くようになる。
→違う。ヤル気をなくすだけだ。
フロー状態に入るのに15分の精神集中課程が必要なため、作業を中断する行為が継続的に発生する場合には、実質的な仕事はできない。
サービスとしてのリーダーシップ
自ら仕事を引き受ける
明らかにその仕事に向いている
あらかじめ必要な準備を済ませ、万全の態勢で仕事に向かう
全員に最大限の価値を与える
ユーモアと明らかな善意のもとに事にあたる
大変興味深い、そして、自分の職場がチーム殺しにあっていることを知る。大きな企業であるがゆえにうまくいかなくなっていることが多いのだろう。ペーパーワークや -
-
Posted by ブクログ
ソフトウェア開発のマネジメントにおいて重要なのは、技術よりも人。という話。
そんなの当たり前だろ？おれもそう考えてるぜ。と、大部分のマネージャは言うだろうが、多くの場合それは思い込みだ。
こう考えてみるといい。
この仕事はこの人にしかできないといったことがあった場合、その手順を標準化して、急にその人が抜けても大丈夫なようにしよう。。。って発想になったらもう怪しい。
それじゃ、その人よりも標準化(という名の技術)のほうが価値があるってことになってしまう。そんなことで仕事が運ぶんだったらそりゃラクだけど、実際そうはいかない。その人しかできない仕事なんてものが、そう簡単に標準化なんてできるわ -
-
-
-
-
-
-
-
-
Posted by ブクログ
計画に対する乖離を早い段階で把握し、手遅れになる前に適切な対策を打てるかどうかが、プロジェクトの成否に大きく関わってきます。そのために、プロジェクト・マネージャーはプロジェクトのQCDに関するデータを収集して現状を分析しようとします。（監視・コントロール）
しかしながら、こうしたQCDデータに現れない事象がプロジェクトを思わぬ方向に導くことも少なくありません。
本書は、こうしたプロジェクトの「兆候」を86のパターンに抽象化してユーモラスな名前を付けて紹介しています。
中には自分の身に覚えのあるパターンも沢山あって耳が痛い限りですが、ありがちなものをピックアップして目に見えるところに書き出して -