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