意外と難しい進捗報告 - 進捗報告で気をつける事 -
進捗報告とはその名前のとおり進捗を報告することです。しかし、お客様や上長に報告する際は、朝会などの日々のミーティングで報告する内容(やったこと、やること、課題)とは異なります。
アジャイル開発における朝会は日々の作業のコミットしても、イテレーションのスコープの達成にはコミットしません(タイムボックスが終わればそこまでしかしない)。
#プロダクトオーナーの方に同じような苦労が集中するのでしょう。
しかし、従来型の開発では全体のスコープと納期にコミットしているので、その実現に向けての対策を説明しないといけません。また、進捗報告をきっかけに上長や顧客、関連組織は、問題の解決に向けてそれぞれの権限を行使しようとしますので、適切な報告が求められます。
進捗報告では(必要なら全体の中の現在の作業の位置づけを簡潔に説明したあと)、作業の状況(遅れ進み)とその理由を説明します。遅れていればそのリカバリ策とリカバリの見込みを説明します。
その際には、以下のような点に注意した方が良いでしょう。
必要以上に不安を与えない
課題の共有をする場合は、それが自分たちで解決できるか、それとも誰かの助けが必要なのかを明確にします。自分たちで解決できる事に上長や顧客が関与し出すと作業が遅れてしまいますのでお互いにメリットがありません。
逆に助けが必要な際は、手遅れにならない様に早めに連絡します。上長に掛け合ってもらいたいのに、出張に行ってしまってタイミングを逃すなんてことの無い様にします。対応の必要性が見えてきた状況で説明しておくと、相手もその準備ができるでしょう。
必要以上に不安を与えたり、手当が遅れない様にするには、状況説明の際にその理由をきちんと説明すると良いでしょう。
例えば、増員が2週間遅れたものが1週間の遅延までに取り戻したものを、単に「1週間の遅れ」と言うと不安をあおってしまいますが、「2週間の遅れを半分取り戻した。今月中にはリカバリできます」と言えば、不安はあまりないでしょう。
見積もりミスと思われない
予定よりも進捗が進んでいるからと、お客様に自慢げに話すのもよくありません。当初の見積もりに対してお客様は費用を払っているからです。きちんと説明する必要があります。
これから問題になりそうなリスクがあって、残業して少しでも前倒しにしようとしているなら、そのように説明すれば良いでしょう。本当に見積もりミスならお詫びするしかないですが、間違った理由は説明すべきです。
責任をなすり付けられない
複数チームで開発する際にありがちなのが、責任をなすり付けられることです。特にライバル会社がいる場合は、相手を出し抜こうとチョットした事でもとんでもない事の様に言われる事があります。
負けずに言い争っても何も解決しませんので、謝るべきは誤ってゴールに向けてどうすべきかを話します。責任を押し付けるようなチームは大抵は問題を隠していますので、結合時期を遅らせる等の譲歩を求めると意外と合意してくれるものです。
相手によって表現を工夫する
同じ状況でも相手によっては表現を工夫した方が良い場合もあります。長期的な視点からアピールする事も必要ですし、予算措置が必要になるなら早めに言った方が良いでしょう。
危機感をあおりすぎてもいけませんが、リスクは共有しないといけません。相手の立場や個性にあわせて、表現の工夫は必要です。初めてのお客様なら、周りの人の話し方を参考にすると良いでしょう。
嘘をついてはいけない
そのような場合でも守らないと行けないのは、嘘をつかない事です。一度、嘘をついてしまうと、状況が変わらない限り嘘に嘘を重ねることになります。
見積もりが甘かったのに嘘をついて残業以外の対策をとらないなら、いずれ破綻します。自分で解決できない問題は早めにデシジョンして、対策を取らないといけません。
多くの対策には調整が必要で、時間がかかるものが多いです。追加予算には稟議が必要かも知れませんし、仕様の削減ならステークホルダーに納得してもらわないといけません。タイミングを逃さず報告すべきです。
相手に合わせて表現を工夫しても、嘘をついてはいけません。
おわりに
若い人の指導を始めると色々と気になるものです。 自分ではそれほど経験値が高いと思ってなくても、それなりにあった様ですのでまとめてみました。少しでも参考になれば幸いです。
« 完璧なプロジェクトなんてない | トップページ | 実装者のための計算量のはなし - O(logN)などをわかり易く説明しました - »
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「仕事術」カテゴリの記事
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
- BABYMETALに見るマネジメントの工夫(2016.05.24)
- 「モノ書き」 - 山口 英先生をしのんで -(2016.05.13)
- 懇親会は補習以上の価値がある - 勉強会だけではもったいない -(2016.05.05)
- 「なんで?」と「自分だったら」が属人化を防ぐ1 - 必要な時に、必要なものを、必要なだけ -(2016.04.27)
« 完璧なプロジェクトなんてない | トップページ | 実装者のための計算量のはなし - O(logN)などをわかり易く説明しました - »
コメント