arsro.net

見積もりという言葉のあやふやさとコミットメント


見積もりやスケジュール管理のような、なにやらあやふやなものが多いプロジェクトマネジメントをしていく中で、以下のように明確化したコミュニケーションは大事だなと改めて思う。 (特に以下はシンプルに言語化されていて、身体化しやすい)

見積もり 見積もりというのは予測。 ある条件の場合、これくらいの時間がかかると思われますというもの。 約束ではなく予測であり、確率だということが重要。   コミットメント 自分たちが、いつ、何を届けるのを約束すること。 ビジネスパーソンとして約束。    ターゲット ビジネス上の目標。 X月にはリリースしないとネガティブインパクトがあるとか。     見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる より

スケジュールを気にする人間から見ると、開発が関わるプロジェクトは油断するとふわっとしてしまいがちであるように思う。

見積もりやスケジュールの話を、定期的にエンジニアやデザイナーとやっているはずなのにだ。

自分自身が元々開発をしていた人間だったからか、見積もりやスケジュールのようなものをテーマにしてエンジニアやデザイナーとコミュニケーションを取るときには、見積もりという言葉の中に含まれる見積もり・コミットメント・ターゲットを暗黙的に解釈している気していたのかもしれない。

プロジェクト不確実性コーンは開発プロジェクトに関わらず、全てのプロジェクトにあると思っているので、見積もりが正しいかどうかは極論どうでもいいと思っている。

(正当なものであれば)ターゲットが大事なのは言うまでもない。

個人個人が最も大事にすべきはコミットメントなんだろうな。

プロジェクトの中で、コミットメントすること。コミットメントに対してできたかどうか。できなかったとしたら何が悪かったのか。を繰り返し続けることが大事だと思う。

実行の4つの規律とかは、まさにそういう話だった気がするので、今度またアウトプットするかもしれない。

最近のポスト