6年ぶりに前線に復帰したので、初心に戻ってITプロジェクトマネジメントの再学習。デスマーチとはプロジェクトが火を噴いている状態であり、技術やマネジメントの方法論ではデスマーチプロジェクトは解決できないことが多いのです。最新の開発ツール・方法論のようなハードなエンジニアリングアプローチではなく、優れた人材や効率の良いチームのようなソフトな要素が大事なのです。アメリカのITプロジェクトをベースにしている&初版が古いのですが、参考になる要素は多いのです。


↑気になったらここからポチっと↑
↓気になったらここからポチっと↓
↑気になったらここからポチっと↑
この本を読むとわかること
- デスマーチプロジェクトの定義(スケジュール・要員数・予算・要求事項)
- デスマーチに陥ったらまずとるべきアクション
- トリアージ
- 20/80の法則
- 要求事項管理の勘所
- プロジェクトマネジャーとしてのユーザーとの交渉術・交渉すべきこと
- ソフトウェア開発プロジェクトにおける時間と人数の関係性(人月の神話)
- デスマーチで上からプレッシャーをかけられた際のプロジェクトマネジャーとしてのふるまい方
- モチベーション・忠誠心が高く、効率的なチームを作るという「ピープルウェア」の神髄
- プロジェクトマネジャーが任命時に上層部に掛け合うべきこと・必要な政治力
- メンバーのやる気に大きく影響する報奨と残業
- プロジェクトメンバーの役割分担
- チームの生産性を落とす要素と、生産性の上げ方
- ベストプラクティス導入の危険性
- 米国国防総省が提唱する「ワーストプラクティス」という概念
- デスマーチへの対処に大きく影響するプロジェクトマネジャーのメンタルモデル
- どのような開発プロセスを選ぶかも大事だが、メンタルモデルのようなソフトな問題も重要
- ソフトな要因は数字やメトリクスには表れない
- WindowsNTや95で使われた「毎日の構築」という概念
↓気になったらここからポチっと↓