コミュニケーションツーリング
Title
コミュニケーションツーリング
Patlet
インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
状況
チームは別のチームのコンポーネントに依存しており、そのコンポーネントにコントリビュートしたいと思いっています。コミュニケーションは文書で行われる場合でも、1対1で行われています。
問題
チームは、そのコンポーネントのダウンストリームユーザーからのコントリビューションを受け入れることができます。しかし、調整とコミュニケーションはアドホックな方法で行われ、支離滅裂な情報が共有されたり、回答が遅れたり、コントリビューターが明確な回答を受け取る前に複数のホストチームのメンバーに問い合わせをしたりすることがあります。
組織に働く力学
ホストチームはコントリビューションを受けることに興味があり、コントリビューターを指導することに積極的です。
チームは口頭でのコミュニケーション文化が強く、プロジェクト特有の非同期コミュニケーションチャンネルを設定する経験は浅いです。
コミュニケーションチャネルは、連絡を取るべき特定のグループと連携しているかもしれませんが、コミュニケーションの目的によって連携しているわけではありません。
ソリューション
ホストチームは、社内で公開され、アーカイブされ、検索可能で、リンク可能なコミュニケーション・チャネルを提供することの利点を明確にする必要があります。
インナーソースプロジェクトのコミュニケーションチャネルを合理化する際の目標は、特定の人々の周りではなく、トピックの周りのコミュニケーションを調整することであるべきです。
プロジェクトは、ホストチームのメンバーだけでなく、ダウンストリームユーザーやコントリビューターもフォローできるように、構造化されたコミュニケーション、意思決定、進捗追跡が透過的に行われる独自のイシュートラッカーを持っている必要があります。
プロジェクトは、あまり厳密でない構造を持つ1つ以上のディスカッションチャンネルを持つべきです。一般的に、これはメーリングリスト、オンラインフォーラム、あるいはアーカイブされたチャットチャンネルになります。通常、プロジェクトのためのチャンネルは1つで十分ですが、トラフィックが増えすぎた場合は、プロジェクトの使用に関する議論とプロジェクトの開発に関する議論を分けることが有用です。
文章での共有のチャンネル以外でもコミュニケーションは可能ですが、できるだけ多くの情報を非同期チャンネルにつなぐべきです。
すべてのコミュニケーション・チャンネルはプロジェクトの README.md で文書化されるべきです。ホストチームのメンバーは、個人的に受けた質問を公式のコミュニケーションチャンネルに戻すよう努力する必要があります。
結果の状況
公式の非同期コミュニケーションチャネルを設定し、一貫して使用することで、同様の質問が再び出てきたときに再び参照できる受動的なドキュメントのベースレベルを作成することができます。
コミュニケーションがオープンに行われることで、他の人も簡単にプロジェクトの進捗を追うことができ、積極的に貢献することができます。また、他の参加者が潜んで読んでいることで、参加するための障壁が低くなり、コントリビューションを受ける可能性が高くなります。
質問に対する回答が公開されることで、より多くの人が自分の視点を追加し、全体像を把握することができます。これは、ホストチームのメンバーだけでなく、プロジェクトのユーザーも含みます。
非同期チャネルでコミュニケーションをとることで、タイムゾーンや会議のスケジュール、チームのルーチンなど、異なるスケジュールの参加者がプロジェクトに有意義に貢献することができます。
このようなチャンネルで質問に答えることは、他のチームメンバーがそれを聞いて追加情報を提供できるだけでなく、同じ質問をした他のユーザーが前回の回答を見る(または後で見つける)ことで、説明を繰り返す必要性を低くすることを意味します。
事例
Europace AG
Paypal Inc.
著者
Isabel Drost-Fromm
ステータス
Structured
Drafted in December 2019.
翻訳の履歴
最終更新
役に立ちましたか？