マルチチームグループで問題解決の知識を共有するにはどうすればよいですか？
私はWeb開発者である限り、マルチチームグループで働いてきました。私の経験では、チームは孤独な兵士または数人の人々である可能性があります。通常、会社には複数のチームがさまざまなプロジェクトに取り組んでおり、プロジェクトが実際に公開されると、どのチームでもそのプロジェクトのメンテナンスを実行できます。
これは、プロジェクト関連の知識だけでなく、「クラフト関連」の知識についても話しているので、簡単な例ですが、私がどのように作業に慣れているかを理解できるはずです。
私たちはモジュール化されたチームで作業しているので、チームがプロジェクトに集中しすぎているように感じることがあります。 1時間の話し合いの後で、質問が声に出して尋ねられ、まったく関係のないプロジェクトの誰かがはるかに簡単な解決策を提案したケースを見てきました。
人々は常に利用できるとは限らないため、問題を解決するのは困難です。また、知識のある人は、質問者の問題を解決する時間がない場合もありますが、自分で簡単に解決できます。
SEに沿ったソフトウェアベースのソリューションについて考えましたが、このテーマに関する他のプログラマーの意見を知りたいと思います。
[〜＃〜]編集[〜＃〜]
これがウィキで解決できる問題かどうかはわかりません。ウィキはユーザーに実際に質問することを奨励するのではなく、記事を書くことを奨励していると感じているためです。それを必要としています。
私は、知識の共有の問題がすぐに問題になった、2年半で100人未満から500人以上に増えた急成長中のスタートアップ企業で働いていました。同社は、合理的に機能する戦略を構築し、次の3つの主要コンポーネントを含めました。
- ドキュメンテーション
- 標準化
- 内部トレーニング
各チームは、コンポーネントの更新とともにドキュメントをリリースする責任がありました。ドキュメントなしのコードのリリースは不完全であると見なされました。ドキュメントの品質は、「対象読者」（つまり、コンポーネントを使用した社内の他のチーム）によって個別に評価されました。ドキュメントの誤りや脱落はバグ追跡システムに入力され、一流の欠陥として扱われました。
コンポーネントに関する電子メールの質問に答えるときは、ドキュメントに言及する必要もありました。質問に答えるドキュメントが見つからなかった場合、ポリシーでは、ドキュメントを作成するか、既存のドキュメントを変更して質問に答えることを期待していました。この慣行は、社内文書をかなりの品質レベルに保つのに役立ちました。
同社はまた、定期的に開催されるコーディング標準委員会を設立し、全社的なコーディング標準の更新を公開しました。これらの標準は、社内で構築されたライブラリの使用に多くの注意を払い、アーキテクチャ的に一貫した方法で新しいライブラリを実装するためのフレームワークをレイアウトしました。
最後に、各チームは、会社の他のメンバー向けの一連のトレーニングコース資料を公開する責任がありました。内部での露出が広いチームのチームリーダーも、四半期に1〜2回内部トレーニングコースを実施しているため、内部コンポーネントのトレーニングを受けたい場合は、ソースから直接実践的に学ぶことができます。
最終的に、知識の共有はプロセスの問題であり、技術的な問題ではありません。テクノロジーは間違いなく役立ちますが、プロセスは依然として問題に対処するための主要な手段です。
プロセスを「販売」することは、特により多くの作業を行う必要がある利害関係者にとっては難しい場合があります。幸いなことに、知識の共有には大きなメリットがあります。それは、社内のモビリティを向上させることです。これは、会社が急速に成長しているときに特に役立ちます。これは、はるかに短い通知でチームリーダーに昇格したり、たまたま興味のある別のプロジェクトに移動したりできることを意味します。
プログラマーとして、私たちは時々、根本的に人々の問題であるものに対する技術的な解決策を誤って探します。大規模なグループでは常に非効率性があります。私が知っている最善の解決策は、古き良き時代の「グレープバイン」です。特定の質問に答えるのに最も適していると思う人に尋ねます。彼が答えを知らない場合、彼はそのトピックに関する彼の「教祖」などを私に紹介します。チェーンが3人を超えることはないと思いますが、ほとんどの場合1人か2人です。誰に質問すればよいかわからない場合は、グループメールを送信してください。
Wikiは一種のFAQとして提供されます。誰かが同じ質問を何度も受けると、人々にそれを紹介できるようにwiki記事を書きます。最終的に、人々は質問をする前にwikiの検索を開始し、頻繁な質問を見越してwiki記事を書き始めます。十分に大きなグループでは、他の誰かが同じ質問をしたか、あなたの質問がとにかく1対1の助けを必要とするほど具体的である可能性が高いです。
ウィキは間違いなく役に立ちますが、他の人に役立つ記事を書くには時間がかかります。私の経験では、コンテンツを追加する方法は2つあります。
特定のモジュールまたは機能についての知識を持っている人が、他の人に役立つと思うコンテンツを作成します。
上級の開発者やエンジニアがドキュメントの作成に専念する時間を見つけるのは難しい場合が多く、ドキュメントの作成を楽しんでいない人も多いため、忘れるまで延期する可能性があります。
問題を解決するために助けを必要としたり、真剣な調査をしなければならなかった人は、問題をどのように解決したかを文書化します。
このタイプの記事は、モジュールのユーザーが（既存のドキュメントを読んだとしても）特定のユースケースの落とし穴を特定した可能性があるため、非常に役立ちます。また、ユースケースが完全に同じでなくても、将来のユーザーへの一種のガイドとして非常にうまく機能します。
雇用主は両方のタイプの記事を奨励し、時間をかけて書くべきだと思います。そうすることで、特定の個人の知識に頼ることが少なくなるからです。
RedMine を使用します。これは、問題追跡、チケット、WikiなどをNiceプロジェクト管理Webアプリケーションに統合します。もちろん他にもありますが。