#blog
[https://sookocheff.com/post/engineering-management/project-management-for-software-engineers](https://sookocheff.com/post/engineering-management/project-management-for-software-engineers)
# なぜこのブログを読んだか
何で見つけたかは覚えてない (多分 Twitter とか? もしかすると Feedly かもしれない) が自分のチームで一定のスコープの範囲でのプロジェクトマネジメント (正確にはデリバリーリードと呼んでいる) を移譲する場面があったので言語化のためにちょうどよかったので読んだ。
# 何が書かれているか
タイトル通りではあるけど、プロジェクトマネジメントでやるべきことなどが割と詳細まで書かれていた。
また自分自身あんまり言語化できていなかったが、「主導権を持っている人を探し出して、目的やゴールをインタビューすることで解像度を高める」というアプローチは自分自身の成功体験からもよく実践していてそこに触れているのがよかった (言語化になった) という印象を持った。
# メモ
この記事の中では、プロジェクトマネジメントは5つのフェーズがあるとしている
## Initiation
> Goal: Develop a clear and shared set of expectations.
このフェーズでは以下のような問いに明確に答えることができている状態を目指すことが大事とのこと
- Who will this project impact?
- Who determines success?
- What are their expectations?
- What are the project limitations?
### Steps
- Identifying key stakeholders
- [[Project Management for the Unofficial Project Manager]] という本で紹介されている "stakeholder DANCE" の役割を担っている人を洗い出して整理していくこと
- Decisions : プロジェクト内での予算に影響のある意思決定を行う
- Authority : 権限移譲する権限を持ってる
- Need : プロジェクトの結果として恩恵を受ける人
- Connections : プロジェクトを成功に導く上で必要な人やお金やリソース
- Energy : プロジェクトの成功に影響を及ぼすポジティブ、ネガティブなエネルギー (力学とかのイメージ)
- ここに現れる人たちにはプロジェクトの内容を定期的に伝えていくのが重要
- Interviewing stake holders
- stake holder を整理できたあとは彼らからなるべく多くの情報を集めることが重要になる
- 紹介されてるテンプレート
1. Introduction
2. Project Purpose
3. Description
4. Desired Results
5. Exclusions
6. Constraints
7. Communication Needs
- Developing a scope statement
- Getting approval
## Plannning
> Goal: Create a clear roadmap for success
### Steps
- Create a communication plan
communication plan 例
| Frequency | Audience | Method |
| -- | -- | -- |
| Daily | Project Team | Stand-up meeting |
| Weekly | Executive group | Weekly status email |
| Quarterly | R&D organization | All hands presentation |
- Create a project plan
- [[Stepping Stones not Milestones]] をまず参照するのがおすすめとのこと
- 川を渡る時には、安定した足場を見つけて一歩一歩進んでいくことが大事というような話が書かれている (安定した足場を stepping stones と呼んでる)
- ブログ著者によるおすすめ引用部分
- > Here's the problem with arbitrary project milestones: They're kinda useless. Sure you need to figure out a project plan and do some estimating and track progress and send out emails to half the company about how you just successfully completed Milestone M2b and are making great progress towards Milestone M3. Milestones are good for tracking execution, but do they actually help de-risk a project or eliminate unknown unknowns? Not really.
- 何はともあれロードマップを設計する際には、何かしらの明確なステップを設計するべきという話
- [[Stepping Stones not Milestones]]によると Stepping Stones は以下の要素を満たすとしている
- Stepping stones are a cohesive, concrete deliverable. They involve the completion of something, generally a simplified version of a final system.
- Stepping stones deliver real value. If the company decides to pull the plug on the project, we should have got something out of the stepping stone version. This could be a system that works at smaller scale or a useful standalone component.
- Stepping stones reside along that path towards the goal. The road to success will likely take a meandering path, but each step should be directionally consistent with where we want to go.
- Stepping stones allow us to learn something! By building a smaller version of the project, we drastically reduce the scope of unknown unknowns. Problems that seemed open-ended and intractable at the start now just seem like obvious next-steps once the solution space has been trimmed down.
- 要するにアジャイル開発などにおけるインクリメントの考え方に近い
- Create a risk managemnt plan
- > "Anything that can go wrong, will go wrong."
- どれくらいの確率で起こるか x どれくらいのインパクトがあるか をマッピングすることでリスクを可視化していく
## Execution
> Goal: Keep people engaged towards success with consistent accountability
### Steps
- Schedule accountability check-ins
- 定期的な共有の場の設計を行う
- またその際には、TODO ではなくゴールにフォーカスすべき
- 例えば以下のようなアジェンダを設定する
- > 1. Are we meeting the goal? Are we on schedule?
- > 2. How are we progressing on our current commitments?
- > 3. What can we do next to move forward?
- > (意訳)
- > 1. TBD
- > 2. TBD
- > 3. TBD
- Adjust to feedback from delivering stepping stones
- ちゃんと価値を見せ、Feedback に耳を傾けること
## Monitoring and Control
> Goal: Keep stakeholders happy with transparent communication
### Steps
- Regular status reports
- > A good status report will provide at a glance information on overall project health, and the status of any key deliverables. Keep in mind a traffic light. If you are reporting green, it means that everything is on schedule with no risk, yellow means we need to pay attention to make sure things stay on track, and red means something is wrong, and you need help from the stakeholders to get things back on track.
- > (意訳)
- > TBD
- 健康状態のレポートを意識する
## Closure
> Goal: Measure success and get better
### Steps
- Confrim the project is done
- 以下のような問いに答えること
- > - Did we meet the goals of the project?
- > - Are stakeholders happy?
- > - Did we deliver on time?
- > - Did we deliver on budget?
- > (意訳)
- > -
- > -
- > -
- > -
- Document lessons learned
- 学びを組織に還元するためにも以下のような簡単なレトロスペクティブを行う
- > - What was done well?
- > - What needs to be done better or differently next time?
- > - What was expected? Unexpected?
- > - How or what should we change in the future?
- > (意訳)
- > -
- > -
- > -
- > -
- Celebrate success
- 祝おう!
# 感想
- プロジェクトマネジメントについてここまで実用的に整理しているものをみるのは珍しかったのでメモした
- 言っていること1つ1つはある程度そうかなと思いつつ、「インタビューを行う」ということをかなり徹底していて自分も自分から出る will がないタイプで他人の will を膨らまして実現するたちなので共感するところが多かった