毎週の技術会議？
同じプロジェクトに取り組んでいるプログラマーが次のようなことについて話し合うことができる毎週の技術会議を導入することを考えています。
- 技術面でのプロジェクトの現状
- テクノロジーのバックログ。締め切りのためにスキップしたかもしれないが、今は私たちを噛むために戻ってきたもの。
- 開発者の生産性を制限しているテクノロジーの制約
- プロジェクトに適用される可能性のある新しいテクノロジー
基本的に、ビジネス側ではなく、プログラマーの観点からプロジェクトを検討します。
-
このような会議のためのいくつかの良いガイドラインは何でしょうか？
- 会議はどのくらい続くべきですか？
- 毎週が多すぎますか？
- 各トピックに時間制限を設ける必要がありますか？
- このような会議にはどのようなトピックが良いのか、どのトピックが悪いのか。
- 10人は多すぎますか？
.。
毎週プロジェクトの現状を話し合うのは実りがないと思います。プロジェクトがどこにあるかを議論するには、毎週の会議ではなく、毎日の会議が必要です。そのような会議についての良い質問が尋ねられました ここ 。
また、私の経験では、計画中にテクノロジーのバックログに対処する方がよいでしょう。
新しいテクノロジーについては、それ自体は悪い考えではないと思います。また、毎週の形式にも適合します。しかし、そのような会議で話題から外れることは非常に簡単です。他の人が貢献したいと思っていることを確認し、あまり多くの人を招待しないでください（実際には10人が多いと思います）。
私の仕事では、金曜日に30分間の会議があり、各タスクの現在地について話し合います。ある人が遭遇した障害について話しているときに、別の人がそれについて何らかの洞察を提供できる場合があるという点で、私はそれが役立つと思いました。重要なのは、会議の前に全員が準備を整えていることを確認し、会議をできるだけ短くすることです。
毎週のプロジェクトミーティングでできることはたくさんあり、誰もが自分の意見を持っています。
あなたのリストにある私の気持ちは、これらの3：-テクノロジーのバックログです。締め切りのためにスキップしたかもしれないが、今は私たちを噛むために戻ってきたもの。 -開発者の生産性を制限しているテクノロジーの制約-プロジェクトに適用される可能性のある新しいテクノロジー
....毎週話し合うのは少し多いかもしれません。たぶん、これらはプロジェクトのフェーズの終わりにもっとよく議論されるでしょう。
- 会議は、物事を実行可能に保つために必要とされるより長く続くべきではありません。時間に余裕があり、近い将来に行う予定の改善についてのみ話し合ってください。あなたが来週のために十分に選んだことがわかっているなら、それ以上の項目について議論するのをやめてください。
- 改善に優先順位を付けることができるようにするために、通常、それらを完全に議論する必要はありません。あなたが実際にそれに行動することを計画しているときだけそうしてください。これらの改善に関する入札システムを許可して、優先順位付けをある程度民主化することができます。
- 同時に多くのことを行わないでください。並行して取り組む改善の数を制限してください。
- 策定された行動のための時間がない場合、あなたが開催する会議は価値がありません。通常のプロジェクト作業の合間にどのように時間を作りますか？
- プロジェクトに関連するものを、個人のスキル開発やチームプロセス（「jQueryを学ぶ必要がありますか？」、「ビルドサーバーが必要ですか？」など）などのよりグローバルな懸念から分離することをお勧めします。すべてのプロジェクトを改善するものは、プロジェクトのコンテキストとは別に議論するのが最善かもしれません。あなたはそれらのために小さな内部プロジェクトを作成したいかもしれません。
- 10人は少し多いように見えますが、それがプロジェクトチームの規模である場合は、関係するすべての技術者を含めてください。