この4月からプロジェクトマネージャーのお仕事が降ってきた。
正確には3月から準備していて、いろんな引き継ぎとか覚えることとかで忙しかった。
そんな中で早速正直失敗だなと思えるプロジェクトにぶち当たったので、これはチームメンバーでちゃんと振り返って次のプロジェクトでは同じ轍を踏まずに済むようにしたいねと話したんだが、よく考えてみると何でもって成功・失敗を判断してるんだろう?と自分でも思ったので試しに書き下してみる。
プロジェクトを進めてる途中の基準
期日
最初はいつを締め切りにしていたかとかユーザー、ステークホルダーのニーズに依存するが以下かなと思ってる。
- 前倒しできた
- ちょうどに終わった
- ちょっと過ぎた
- 大幅に過ぎた
- そもそも終わらなかったので中止した
機能
多ければいいの?減らすことは悪いことなの?という問題もあるけどひとまず
- 当初考えていたより多くの機能をリリースできた
- 過不足なくリリースできた
- 少し減らした
- 大幅に減らした
- そもそも仕様が破綻した
人数
途中で人が増えたり減ったりすることもあるので、一律で言えるものではないけどとりあえず
- 多すぎた
- ちょうど良かった
- 少なかった
チームワーク
- とても協力できていた
- 協力できていた
- あまり協力できてなかった
- 全然協力できてなかった
フェーズの切り方
- ちょうど良かった
- 細かすぎた
- 大雑把すぎた
- 切ってなかった
- どこで切ればいいかわからなかった
終了条件
- 何ができていれば終わりか明確だった
- なんとなく終わりがわかった
- 何が何だかさっぱりだった
プロジェクトが終わってから
ユーザーインパクト
お金、ユーザーからの意見などいろんな軸があるかもしれないけど
- とても良かった
- まぁまぁ
- あまり良くなかった
- やらないほうがマシだった
コード
コードを書くプロジェクトとは限らないから、人によってはドキュメントとかに置き換えればいいかな
- 見通しが良い
- ちょっと読み込む必要がある
- 意味がわからない
だいたいこんな感じに分かれるんじゃないかなと思ってる。
足りない軸もあるかもしれないが、それって全部のプロジェクトに共通して言えることなのかは疑問。
書いてて思ったけど、ちょっと考えただけでもこれだけの軸があるので、部分的に良い悪いがきっとあるはずで、良いところは次も続けたいけど悪いところこそ積極的に共有していくべきかなと思う。悪いところも治そうとしすぎて返ってより悪くすることがあるから程度問題は難しいんだが。
様々なご意見お待ちしています。
