プロジェクト後の会議は時間の無駄ですか？

私の職場では、深刻な成長痛がありました。私たちは3から10の開発チームから出発し、会社自体はこの1年で30％成長しました。ほとんどの測定では、私たちはうまくやっています。残念ながら、ソフトウェアの品質が低下しています。

今日、部門のマネージャーとのミーティングで、製品の発売から1〜2日後にプロジェクトチームのミーティングを提案しました。予算の懸念、範囲、何がうまくいかなかったか、何がうまくいったかを話し合うことができました。理想的には、私たちの過ちから学ぶ。私たちは他の人々のためにサイト/アプリを構築しているので、私たちの時間は非課金に対して請求可能です。このような会議は後者に該当します。

私のマネージャーは、すぐにそれを打ち切りました。「その時間は請求対象ではありません。それについて話しているその時間の終わりに時間を浪費するので、私たちは別のプロジェクトに遅れをとります。」私はこの論理に不意を突かれたので、彼と戦うことさえしませんでした。

だから私の質問：私は価値がプロジェクト後の会議であると思いますが、彼はそうではありません。長期（または短期）で時間とお金を節約するのに役立つプロジェクト後の会議の証拠が文書化されていますか？直感的にはそうなるだろうと思うが、彼は明らかに、そこにいる必要がある5人の少額の請求できない時間をより心配している。

振り返ってみると、Looking Aheadは、アイデアに関する実証された証拠に近いでしょう。 プロジェクト事後：継続的改善のための貴重なツールは、それに関するブログ投稿です。

Art of The Post-Mortemには、このアイデアに関する次の点があります。

ポスト・モーテムの起源は軍隊にあり、軍隊は日常的にこの種のプロセスを使用して最前線の人々を報告します。しかし、その管理アプリケーションは、パフォーマンスの高い学習組織にとって不可欠です。

あなたのマネージャーは技術的負債の概念を理解していません。

プロジェクト後の会議は投資であり、費用ではありません。それはあなたがそれらを売る方法です。ミーティングの目的は、お金を節約し、長期にわたって会社の目標を達成する方法についてアイデアを交換することです。

あなたのマネージャーは、これらの長期目標を扱っているため、マネージャーです。ですから、私の考えでは、考えられる2つの真実があります：あなたのマネージャーは自分自身にすべてのコントロールを望んでいるか、あなたのマネージャーは仕事をしていない。会社が物事を「正しい方法で」行い、それ自体の成功に投資するという歴史と哲学を持っている場合は、問題をマネージャーの上に置くことを検討してください。

これは、基本的にはアクション後のレビューであり、軍隊だけでなく、さまざまな状況で特に役立ちます。

私自身の開発サイクルには、次のイテレーションまたはプロジェクトで行うべきことと、前のプロジェクトで改善できることの両方を分析することが含まれます。プロジェクトがしばらく棚上げになったとしても、作業するもののリストを用意しておくと、棚から出たとき（またはバックバーナー...）に役立ち、再びアクティブなプロジェクトになります。次回に触れるときは、何をする必要があるかを確認するのにそれほど時間を費やす必要はありません。

さらに、プロジェクトをレビューし、私または他の人が実装したきちんとしたトリックを見つけることで、これらが広まり、次のプロジェクトまたは次の反復がより良くなります。（繰り返しの観点から私が頻繁に考えるのは驚くことではないかもしれません。）

この値は単純なロジックであり、本質的に明らかです。以前のプロジェクトの間違いから学ばない場合、どうすれば将来のプロジェクトを改善できますか？

特にドキュメントではありませんが、プロセスのレビュー（完了時または完了後）は、私が知っているほぼすべての標準ベースの品質管理システム、特にCMMIおよびLean 6 Sigmaの主要なコンポーネントです。

たぶん、それを義務ではなく、昼食会などで自発的に行われるものとして提案することができますか？開発チームのかなりの数が新しいことを試してみたいと思う可能性が高いので、少なくとも最初の1つを振ることができれば、結果はそれ自体を物語っています。

マネージャーが予算のプレッシャーにさらされている可能性があります。短時間で3人から10人の開発者に拡張する場合、これは大きな懸念事項です。その場合は、当面の予算問題がそれほど差し迫っていないことを願って、今のところ事後会議をスキップして、数か月後に再度提案することをお勧めします。

品質が低下する理由の1つは、10人間のコミュニケーションが3人間のコミュニケーションよりもはるかに大きな問題であるということです。3！<< 10 !. しばらくの間、おそらく混乱する可能性がありますが、最終的には開発者間のコミュニケーションを促進し、元の3人の開発者が確立した原則が新しいグループに参加し、新しい大規模グループでうまく機能するように更新しました。プロジェクトの事後会議はそれを行う1つの方法です。定期的なコードレビューも別です。死後の会議が医療から製造までの産業における品質向上の重要な部分であることを指摘することは害になりません。

あなたのマネージャーが、追加の人員を雇うだけで開発チームを拡大できると信じていると想像するのは難しいです。トレーニングとチームビルディングへの投資が絶対に必要です。それなしでは、組織は自重で崩壊します。しばらく待つと、組織のコミュニケーション不足に直接起因する具体的な問題が発生する可能性があります。その時点で、マネージャーは「みんなを同じページに連れて行かなければなりません！すべての開発者とのミーティングをスケジュールしてください！」と言うでしょう。そして、それが助けになるようであれば、彼はおそらく「プロジェクトごとにこれをやるべきだ！」と言うでしょう。;-)

ですから、辛抱強く、しかし根気強くください。

私はこの傾向に逆らいます。マネージャーに同意します。

明らかになった問題を修正するために多くのことを行うには遅すぎるため、プロジェクト後のレビューはほとんど無意味であることがわかりました。

私が最も強くお勧めするのは、プロジェクト中に行われる定期的な回顧です。 月に1、2回、チームは何がうまくいったのか、何がうまくいかなかったのかを話し合う。もっとやるべきこと、やらないこと。これを行うプロジェクト期間中にあなたがすぐに提案を適用することができるように、彼らがどのように機能するかも参照してください。

会議の形式化を見てください。多くのプロジェクト後の会議は熱心であり、あなたのマネージャーはそれらをサポートしないことは絶対に正しいです。

ミーティングに招待し（議長/中級者に依頼）、議題を回覧し、具体的な結果を出します。マネージャーとして、彼は会議の価値を見ることができます。

私たちは使用しますが、de Bonoの「6 Thinking Hats」レビュープロセスをお勧めします（Wikipidiaを参照）。結果は、会議が学習した最も重要なリーソンであると会議が特定するいくつかの（2または3）アクションポイントです。最初の数回は、スターティングブロックから抜け出すのに問題がありますが、慣れると元に戻りません。

プロジェクト後のレビューを実行しないと、前のプロジェクトで行ったのと同じ間違いを犯すことになります。