紙の本
ちょっと実務と規模感は違いますが
2017/03/26 22:12
0人中、0人の方がこのレビューが役に立ったと投票しています。
投稿者:めいてつ - この投稿者のレビュー一覧を見る
日ごろの業務の参考資料として読んでみました。
話の中心は超大規模システム開発プロジェクトのマネジメントで、私が普段関わるプロジェクトとはスケールは異なりますが、マネジメントの参考本としてはとても有効であり、小規模プロジェクトにおいてもその考え方は通用すると感じました。
投稿元:
レビューを見る
PMBOK 的な細かい話ではなく、より実践的な話が多かった。
自分はいわゆるプロマネではないのだけど、リーダー的な立ち位置でも参考になる部分は多いと感じる。
投稿元:
レビューを見る
PMの指南本。久々にこういう内容の本を読んだ
気がします。
経験としては、著者の規定しているところの大規模の
プロジェクトは経験ありませんが、億~十数億程度規模
のPMを何度か経験させてもらいました。
PMの経験としては、数回1・2回以外は失敗していない
と思います。
この本を読むと、失敗しなかったProjectの時には、
書かれてあるいろいろな助言や考え方、PMの要点
みたいなところについて、大体が気にしていたような
気がします。ただし実行できたものばかりではなく、
こういうことが大事だよなあと思いながら、
できていない時もありますが。
それで、これについては自慢ではなくて、そういう要点
みたいなことは、ほとんどが、上司であったり、
プロジェクトのメンバであったり、パートナー企業の方であったり、から言われたこと、サポートして
もらったこと、サジェッションしてもらったことばかり
でした。
または、お客様からも指摘をいただいたり、お客様が
独自に(勝手に)そういう方向にもっていって
いただいたり、してもらったこともありました。
ということで、私の場合、PMの経験で得たのは
回りのサポートによってノウハウや経験をいただけた
ことばかりだったような気がします。
非常にラッキーであり、運がいい道筋を歩いてきたの
だと思います。
とてもありがたいことで、なんとか、この経験を
後ろに引き継いでいかなければと思っています。
投稿元:
レビューを見る
PMのお勉強。関連図書では久しぶりのヒット。実務を担当している人は、目から鱗の金言が多かったのでは。ちなみに本書は、中規模クラスのプロジェクトを想定している。
・プロジェクト計画後の優先順位
Q>D=C
・プロジェクトのクリティカルパスは「基盤」
・たとえ違う会社の製品であっても、ちゃんと自分で理解し、自分で確認して、顧客がわかる言葉で説明する。それがPMの仕事です。
・独立した疎のタスクに落とす
分解のポイントは、それぞれが独立していることです。隣にAさんがいないと仕事ができないというのは、詳細化されているとは言わない。
・PMBOKの不十分な領域
どうやってバグを出すか書いていない
現行システムを想定していない
PMBOKのメンテナンスは品質維持
・ITプロジェクトの「三種の神器」
サブシステム構成図
→サブシステムが疎になっているかどうかが大事
→人の能力の範囲を超えるとシステムは作れない
スケジュール
体制図
・課題の優先順位は3つの項目のバランスで決める
「緊急度」「重要度」「拡大傾向度合い」
→ケプナー・トリゴー法
・IT部門だけでオーソライズした最初の概要設計では、リリース品質に至らず、プロジェクトは大混乱に陥っていた
・PMはアプリケーションの主要なアーキテクチャ―を理解し、テストとメンテナンスの生産性を担保する
・パラメータ化のわな
パラメータ化は巨大化するとトラブルへの体制が非常に低くなる
・日々エンハンスしているシステムにおいても、その歴史を整理しておくことをお薦めしたい。新規構築後の大幅なシステム化案件を年表形式で整理しておくのです。システム化のトリガーとなったビジネスの歴史と並べて整理しておくとわかりやすい。この年表は新規のメンバーがそのシステムを本質的に理解するのに役立つし、次の再構築において重要なインプット情報となります。