効果的なチーム会議

私は、約20人の技術者がいる会社の8人のプログラマーのチームのチームリーダーです。彼らはさまざまなプロジェクトに取り組んでいます。これらのプロジェクトには、私の管理下にない他のチームの人々も含まれます。私の組織は適切なアジャイル開発を行っておらず、変更に対してある程度抵抗力がありますが、私はチーム内でスタンドアップミーティングを毎日開催しており、全員が役に立っていて、誰もが関与しており、 10〜15分。また、私は毎週、チームメンバー全員と個別のキャッチアップを行い、さまざまな一般的なトピック（技術的および非技術的の両方）と、さまざまな臨時のトピックミーティングについて詳細に話し合っています。

しかし、私が苦労しているのは、毎週のチームミーティングです。それは蒸気を失いつつあり、私は人々を興味を保つことができませんでした。

2週間または1か月の会議にする必要がある場合でも、私はまだ長い会議を開催したいと思います。目的は、スタンドアップ会議では時間を要するために行うことができないさまざまなトピックについて話し合うことでした。私からの更新には、彼らが取り組んでいる現在のすべてのプロジェクトの概要（スケジュールどおり、さまざまな遅延など）、方向の変更、将来のプロジェクト、開発プロセスの変更などが含まれます。私からの講義、そして少なくとも2人は明らかに除外され、残りはせいぜい穏やかな関心を持っています。

私は彼らに彼らの週について話すようにさせることによって人々をより魅力的にさせようとしました、しかし8人の人々でそれは長い時間がかかります（そして一部の彼らの仕事はそれほど多くを越えないため）、残りのチームのほとんどはそうします彼らの同僚がより詳細に取り組んでいることを気にしないでください（彼らはスタンドアップ中に高レベルの概要を取得します）。

だから、これらのミーティングの間、少なくとも一部の人々は非常に退屈していて、私がこれらを保持し続けるのはほとんど恥ずかしいです。それは私たちの活気に満ちた朝のスタンドアップミーティングとは全く対照的です。

人々の関心と関心を維持するために私ができることについて何かアドバイスはありますか？そして、どうすれば私からの独り言ではなく、みんなに物事を提示したり、全員を巻き込んだディスカッションを始めたりすることができますか？

あなたは会議があなたが彼らを講義しているように感じていると言いました。それがあなたにとってそのように感じられ、チームがあなたが言わなければならないことに興味がないように思われるなら、それでもなぜ会議があるのですか？あなたが彼らに情報を投げかけているだけで、それが彼らの注意を引いていないなら、なぜ毎週の電子メールですべてを単に要約しないのですか？

チーム全体で持っているその時間を利用したい場合は、振り返ってみるとよいでしょう。自分の側では単純な正直さで回顧展を紹介できます。以前の会議が生産的だったと感じておらず、全員が一緒にいる時間から利益を得られるように別の方法を試してみたいと伝えます。

私は仕事retrosでは、我々は通常、例えば、上部にスマイリー、MEH、および悲しい顔を入れて、ホワイトボード上の3つの列を持つことになります:)、:|と:(。次に、チームメンバーは、グループ全体と話したいことをボードに追加します。

幸せなコラムでは、成功を祝うことができ（アリスとボブが一緒に取り組んだプロジェクトのリリースを祝福するなど）、試行している新しいプロセスで勝利を宣言することができます（新しいバグトラッカーは、古いもの）。

mehの欄には、その週にぴったりとは言えない、または悲しいことを書いています。新しいバージョンのIDEのライセンスを購入し、誰かが新しいIDEの利点を見たことがないかもしれません-ボードにそれを置いて、他の人がアップグレードに価値がないと感じているのか、他の人が持っているのかを判断できます以前のバージョンよりも実際に優れている方法を見つけました。

悲しいコラムには、その週にうまくいかなかったものを入れます。今週の問題点を特定することは、おそらく私の考えで遡及調査の最大の利点です。チーム全体が実際の問題の解決策について話し合うようになります。たとえば、すべてが単一のコードベースで作業しているチームでは、FooBarクラスは保守が不可能であり、何時間ものデバッグの原因となっていると誰かが言うかもしれません。突然、あなたはチームの他の誰もが今週FooBarで数時間を失ったが、誰もそれを片付けるために時間を費やしていないことに気付きました。その場合、チームは集合的に来週誰かがそのコードのリファクタリングに時間を費やすことが理にかなっていると判断するかもしれません。

誰もが提案したトピックをボードに書き込んだ後、各トピックについて簡単に説明し、その作成者にトピックの10〜30秒の説明をしてもらいます。会議のこのセクションは脱線しやすいため、話題を維持するように注意する必要があります。たとえば、誰かがXが問題であると言うと、誰かが問題の解決策について話し始めます。解決策は投票後まで議論されるべきではありません。トピックを紹介する際に、複数の密接に関連するトピックをグループ化する方法を見つけることがあります。

紹介の後、全員が3票を獲得し、適切と思われるトピック間で配布できます。最後に、投票が集計され、チームが議論するのは、投票数が最も多いトピックです。各トピックについて、実行する必要のあるアクションがあるかどうかを判断します。通常、成功を祝うことにはアクションアイテムはありませんが、特定のコードのリファクタリングを1人に割り当てることができます。アクションアイテムは通常、1人で完了できる必要がありますが、適切なコミットメッセージを心がけるなど、「チーム全体」のアクションアイテムである場合もあります。

ほとんどのレトロは悲しいコラムのトピックに焦点を当てる傾向があり、ボードに書かれていることすべてについて議論するレトロは事実上ありません。会議は時間切れになるたびに終了する傾向があります。会議の直後に、アクションアイテムが特定の人に割り当てられていることを確認します。これは、組織にとって意味のある方法で実行してください。

私は回顧展で大成功を収めました。これらはチームで結束を築くための優れた方法であり、前週を振り返り、プロセスを改善するための優れた方法です。あなたがこれらをあなたのチームと一緒に試してみると、彼らはあなたの会議にはるかに従事するだろうと思います。

ミドルマネジメントの世界へようこそ！

この種の問題がLOTで発生していることがわかります。

次の3つのオプションがあります。

ビッグスティック これを行うか、解雇されます-動作しません。しないでください。

所有権 会議を促進するためにそれらを取得します。一歩下がって、他の誰かを推薦してください。毎回異なる人がホストする回転位置としてそれを持っています。

暗黙話す あなたが言ったことは、誰もが退屈しているから-そして、なぜそれらのことを聞いていませんか？つまらないか ？/これは時間の無駄などです。なぜ聞こえるのですか？これの価値は何ですか？

なぜあなたがこれをしたいのかはあなたの質問では明確ではありませんでした。あなたがこれらが貴重だと感じている唯一の人なら、あなたは変えてもいいですか？彼らが欲しいものを彼らに尋ねてください。彼らはソフトウェアの人々であり、彼らの仕事は一日中問題を解決することです-これを解決してください！

会議で開発者にもっと価値を与えるようにしてください。いくつかの例は次のとおりです。

• 最近のスプリントで開発された新機能を示す短いデモ。（全員発表）
• レッスンで学んだディスカッションで、彼らはチームの作業方法を変更して改善する機会があります（ディスカッションはチームの右手を導き、管理の決定を正当化するためにそこにいます。1対1のベントセッションに似ていますしかし大きい）
• 関連する可能性のある新しいオープンソースプロジェクトに関する講義、または関数型LangやGolang、Pythonのグリーンスレッドなどの異なるコーディング言語。（おそらく、若い開発者の1人によって、またはオンラインビデオの形式で提示されます）
• セールスエンジニアが主導するディスカッションで、顧客が解決しようとしている非常に難しいエンジニアリングの問題について説明しています。（製品の使いやすさを改善することによってサポートコストを削減しようとしているサポート/サービスマネージャーと同じ取引）
• 会社が取ることのできるさまざまな戦略的代替案と、競争環境の中でエンジニアリングがどのように影響を与えるかを明らかにするマネージャー。
• すでに使用しているが最大ではない技術に関するコンサルティングセッションを提供する外部アドバイザー（通常、nosql、cep、RDBMS、ネットワーク、セキュリティ、監視...）
• 誰もが新しいコーディング、デバッグ、またはテストの生産性に関するヒントを学ぶことができるコードウォークスルー（10倍の生産性を持つ開発者による）。
• マウスが許可されていないコーディングセッション。IDEのショートカットについて学びましょう。
• 会計士によるお金に関する101の問題年金、投資の話
• ソーシャルプログラミングとキャリアについて話し合う（スタック交換、Twitter、GitHub、個人ブログ、LinkedIn、お住まいの地域の交流会）

会議を開催したり、開催する頻度を大幅に減らすことができます。講義を定期的にメールで書いて、みんなに送ってください。

会議を開くのは、参加者が実際に参加する理由がある場合のみです。そうでなければ、あなたは本当に人々の時間を無駄にしています。

長い会議を開いたり、プロジェクト管理ソフトウェアを活用したりしないでください。人々の関心を維持したい場合は、重要なことを要約して強調表示し、残りをプロジェクトログとレポート用に保存します。マイルストーン、納品、ハイライト、目標に集中し、人々の3分の1だけに当てはまる場合は、プロジェクトのディスカッションスレッドにそれを保管します。

• 会議を短くする
• プロジェクト管理ソフトウェアの活用
• 個人的で意図的なものにし、感情や目標に結び付けてください
• フォーラムではなくフォーカスグループで問題を解決する
• 仲間からフィードバックを得る

また、他の人が話したいポイントを設定していない限り、他の人が会話に飛び込んで自分の仕事を続けないようにしてください。フィードバックが必要な場合は、それを準備するか、オンラインのどこかにコメントスレッドを用意して、人々がそれに対応する時間があるようにします。これは会議で最も厄介な問題の1つです。敬意を払って仲間に時間を与える。やり取りする必要のあるすべてのことに対処した後、最後にそれらを保管してください。

プロジェクト管理アプローチに関する指示を受け入れ、例を先導して優れた開発プラクティスを奨励します。