誰が情報を所有しているのか-彼は世界を所有している。プロジェクトに関する情報の伝達と普及をどのように組織するか？

十分に構築されたコミュニケーションとプロジェクトに関する情報のよく組織された普及は、よく調整されたチームワークのための最も重要な条件です。すべてのチームで、離れているかどうかに関係なく、「なぜ彼らは私に言わなかったのか」、「しかし、私たちは何か他のことに同意した」、「くそー、私は見なかった」などの問題に直面したと思います。残念ながら、このような状況を完全に回避することはできません。ただし、それらが発生する可能性を最小限に抑えることができます。この記事では、これらの問題を解決したコミュニケーションのルールとメッセンジャーの設定について説明します。

この記事の恩恵を受けるのは誰ですか？

この記事は、5〜10〜15人の小規模プロジェクトチームのリーダーやメンバーに役立ちます。

何を使用するのか、そしてその理由は？

私たちは個人的にSlackを使用して情報を伝達および共有しています。



以下に書かれていることのほとんどは、何らかの形で、他のメッセンジャーで整理することができます。



Slackを使用する理由：

1. グループチャット（チャネル）を整理するのに便利
2. スレッドの存在-ダイアログブランチを作成する機能
3. 動作しているダイアログと動作していないダイアログの違い。Slackで作業します。その他-電報/ watsap /どこでも
4. 反応の可用性
5. リマインダーの可用性
6. Slackを多くのツールと統合する機能

上記の6つのポイントすべてが当てはまるSlackの代替案がある場合は、コメントで教えてください。そして、そのような代替案については、それが持っていて、あなたのチームでよく使われているクールな機能を教えてください。

チーム内のコミュニケーションのルールとその理由は何ですか？

1.PMで通信しない

PMに通信を残すのは、次の2つの場合のみです。

• プライバシーが必要なことについて話し合う。
• Memasiks /ジョークおよび他の洪水。

それ以外の場合は、共通の通信チャネルを使用します。

それが何のためにあるのかをお話しします。混乱や混乱がないように、一般的な通信チャネルを編成する方法については、少し後で説明します。



なぜこのルールが必要なのですか？



このルールは次の目的で必要です。

1. 誰かがコースから外れて何か間違ったことをし始めたときの状況を捉えることは可能でした。
2. 誰かが何か間違ったことをし始めたときの状況を捉えることは可能でした。
3. 二人が何かに同意し、他の誰かがそれに苦しむという状況はありませんでした。
4. マネージャーはチームワークの調整を監視できます。
5. 管理者は、競合、恨み、その他の否定性の発生を追跡できます。

2.アピールの対象となる人にタグを付けます

すべてのメッセージには宛先が必要です。1つ以上。



誰かに言及するときは、タグを付ける必要があります。



複数の人に対応する場合は、チャンネルの全員ではなく、全員にタグを付けます。



なぜこのルールが必要なのですか？



このルールは次の目的で必要です。

1. すべてのチャット参加者がグループチャット/スレッドのメッセージに気を取られたわけではなく、タグ付けされた参加者だけが気を散らしました。
2. 宛先が通知をポップアップする確率は最大でした。たとえば、Slackでは、通知が失われることがあります。

3.メッセージに反応する

誰かが（自動的にではなく）送信したメッセージは、このメッセージの受信者が無視してはなりません。宛先は、メッセージを受信するときに応答する必要があります。宛先が複数ある場合は、全員が対応する必要があります。



「ok」、「understanded」などのフレーズを書かないようにするために、Slackには便利な機能（リアクション）があります。私たちのチームメンバーは通常、反応を示します：目：。リーダーは反応を使用します：目：。



なぜこのルールが必要なのですか？



このルールは、送信者が自分のメッセージが「失われなかった」ことを知るために必要です。

4.スレッドを使用する

Slackには、スレッドなどの機能があります。これは、メインのメッセージフローではなく、「会話スレッド」を作成してその中で対話を行う機能です。



この機能は、単一の問題について話し合うのに適しています。



なぜこのルールが必要なのですか？



このルールは、メッセージのメインフローを混乱させないようにするために必要です。これにより、情報の構造が向上し、情報のナビゲートが容易になります。

5.Slackの外部で行われた会話をログに記録します

たとえば、通話中に何らかの対話が行われた場合は、通話の結果に基づいたプロトコル（会話の結果を反映する一連のこれら）をスローする必要があります。



なぜこのルールが必要なのですか？



このルールは次の目的で必要です。

1. 対話の参加者がお互いを正しく理解していることをもう一度確認してください
2. 合意したことを忘れませんでした
3. 対話を受け入れなかったが、対話のトピックに興味を持った人が何が起こっているのかを知っていました。
4. 会話の結果を参照することができました
5. ...そして一般的な通信チャネルについての最初の段落からの同じ議論

プロトコルには宛先があり、応答を受信する必要があります。



すべての人を宛先として配置する必要はありませんが、この対話のトピックに関係する人を配置する必要があります。

6. 15分間のアクティブな通信で問題が解決しない場合は、電話/会議を開始します

ここではすべてが簡単です。たくさんのテキストを書かなければならないことがわかった場合、チャットで混乱が始まった場合は、電話をかけ、すべてを声で話し合う必要があります。



そして、呼び出しの結果として-全員にプロトコルを送信します。

7.書面で毎日の会議を実施する

毎日の会議は、チームを同期させるために、各チームメンバーがいくつかの燃える質問に答え、現在の問題/問題について話し合う必要があるグループ会議です。毎日の会議に関する一連の質問の例：

• 昨日は何をしましたか？
• 今日は何をしますか？
• 途中でどのような問題がありますか？

専用のグループチャットで、毎日午前11時30分から午前11時35分までミーティングを開催しています。マネージャーは最後に11:36に書き込みます。それが遅れたとみなされた後に退会した人。教育的な仕事は後発者と一緒に行われるべきです。誰もがそれぞれのメッセージの下で反応を添付する必要があります：目：。この反応は、誰もが毎日のメッセージを読んだことの確認です。



私たちの毎日のメッセージテンプレート：

• 私は何をしましたか？ 1.API
  
  メソッド/こんにちは
  
  2.APIメソッド/ howareyou
• 何をしたらいいでしょう？
  
  1.APIメソッド/さようなら
• 質問：
  
  1。アリス、あなたの仕事にはどれくらい時間がかかると思いますか？
• 問題：
  
  1。デプロイが失敗します。助けて！

質問/問題について話し合うときは、ルール番号6を忘れないでください。15で質問/問題が解決されない場合は、それを重要視します。



集会の準備にかかる時間を考慮に入れると、ほとんどの場合、私たちの毎日は全員の時間の15分かかります。



なぜこのルールが必要なのですか？

このルールは、チームの作業時間を効果的に費やすために必要です。そして忍耐。



私たちのスクラムの世界が実際に毎日どんなにバラ色にしようとしても、1人のチームメンバーのプレゼンテーション中に、残りのチーム全体ではなく、1〜2人が彼の話を聞きます。残りはちょうど彼らの順番を待っています。通常、10人のチームの場合、このような1日は30分から1時間続きます。つまり、ほとんどのチームはその時間のほとんどを座ってケーキを作ります。テキスト形式に変換すると、毎日が速く、簡潔になり、とりわけ修正されます。

8.ボーナス：社内チームで、製品とその作成プロセスに関連するすべてのことをテキスト形式で話し合います

私の個人的な経験では、書面で話し合うと人生が良くなります。

• 要求
• 設計
• 実現
• 作業プロセス
• 提案と問題

実際には、これは常に100％可能であるとは限りません。



次に、上記のリストの何かがライブで議論されるとき、議論の結果を記録する必要があります。



なぜこれが必要なのですか？



社内チームで以下の問題を解決するために：

1. 常に：リーダーは自分たちが「脈動に指を置いている」と考えていますが、実際にはチームがどのように行動しているかを実際には見ていません。グループチャットで通信するときにキャッチできるものはすべて、ライブ形式では実質的にアクセスできません。
2. 多くの場合：決定は喫煙室で行われ、その後、すべての利害関係者に放送されるわけではありません
3. 時々：仕事の問題の議論は、多数の「何もない」の会話を伴います

メッセンジャーを設定するにはどうすればよいですか？

チャネルを便利に順序付けるために、プレフィックスシステムを使用します。



私たちのチームはさまざまなプロジェクトに従事しているため、各プロジェクトのプレフィックスを考え出し、それをチャネル名に使用します。



たとえば、GoldFixingとAurrencyの2つのプロジェクトがあります。これらのプロジェクトでは、次のプレフィックスを使用します：GoldFixingの場合はgf、Aurrencyの場合はaurm。次に、GoldFixingに関連付けられているすべてのチャネルは、gf_プレフィックスで始まり、gf_somechannelのようになります。Aurrencyの場合と同様に、チャネルはaurm_somechannelのようになります。



同時に、プロジェクト内には多くのチャネルが存在する可能性もあります。それらを整理するために、目的に応じてチャネルを分類しました。また、カテゴリごとに、独自のプレフィックスが付けられています。



チャネルは4つのカテゴリに分類できます。

1.食料品

これらは、プロジェクト内で作成された製品専用のチャネルです。



接頭辞：prdct_



このカテゴリのチャネルでは、この製品またはその製品に何らかの形で関連するすべての問題について説明しています。



したがって、GoldFixingプロジェクトのフレームワーク内で、プラットフォームとバックオフィスの2つの製品が作成された場合、それらのために次のチャネルを作成します。

• gf_prdct_platform
• gf_prdct_backoffice

2.情報

このカテゴリのチャネルは、通信ではなく、情報の普及を目的としています。



プレフィックス：info_



組織的な目的で、あらゆる種類の通知とメッセージがこのカテゴリのチャネルに届きます。たとえば、タスクマネージャからの通知はここに正確に届きます。



したがって、GoldFixingプロジェクトでJIRAを使用すると、gf_info_jiraチャネルが作成されます。

3.チーム

これらは、職業に基づいたチーム専用のチャネルです。



接頭辞：team_



このカテゴリのチャネルでは、特定の専門分野（フロントエンド/バックエンドなど）に関連付けられており、他の分野とは関係のない問題について説明しています。



たとえば、GoldFixingプロジェクトに複数のフロントエンド開発者がいる場合、gf_team_frontendチャネルがあります。



同じ人が複数のプロジェクトに関与している場合は、プロジェクトプレフィックスを省略して、チャネルにteam_frontendという名前を付けることができます。

4.一時的

これらは、関係のない人にロードしたくないことについて話し合いたいチャネルです。



接頭辞：tmp_



たとえば、GoldFixingプロジェクトで、プロジェクトのロゴが付いたカップの購入について話し合う必要がある場合は、チャネルgf_tmp_brand-cupsを作成します。



特定のプロジェクトに関連付けられていないことについて話し合う必要がある場合は、プロジェクトのプレフィックスを省略します。

情報チャネルの基本設定

この設定はITチーム向けに行われたものですが、IT以外のチームが何かを借りることができると思います。

1. gf_info_general-組織の部分に関連するすべてのもの：宣言、合意の修正、およびプロセス。通常は全員に宛てて、全員からの応答が必要です。
2. gf_info_daily-ここでは、全員が毎日のメッセージの購読を解除します
3. gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
4. gf_info_jira — JIRA
5. gf_info_confluence — Confluence
6. gf_info_deploy — . :
   
   — Instance — Repository —
   
   — Branch —
   
   — Pipeline — gitlab
   
   — Job — gitlab
   
   — Triggered by — Slack ,
   
   — Commit —
7. gf_info_sentry — Sentry
8. team_backend — backend
9. team_dlt — DLT
10. team_frontend — frontend
11. team_qa — QA

Advanced JIRA

JIRAで発生するすべての通知を1つのチャネルに注ぐと、そのチャネルはメッセージの混乱に変わります。



これを行うために、通知を微調整し、JIRA用に1つではなく、いくつかのチャネルを作成しました。

1. gf_info_jira_comments -JIRAのコメント通知用
2. gf_info_jira_qa-テストの準備ができているタスクの外観に関するQAの通知用。このチャンネルにはQAとマネージャーしかいません
3. gf_info_jira_qa_verdict-「TEST」ステータスから「DONE」または「REWORK」へのチケットの転送に関する通知用

セントリーからの通知の高度な設定

各プロジェクトには、いくつかのプロジェクトインスタンス（スタンド）があります。

• 開発スタンド-開発者向けのスタンド
• テストスタンド-テスター用スタンド
• リリーススタンド-リリース候補を実行するためのスタンド
• 生産スタンド-生産スタンド

それらのそれぞれについて、個別の歩哨チャネルを作成しました。



また、フロントエンド開発者は、バックエンドでエラーが発生したときにひねらないように、またその逆に、これらのチャネルをフロントエンド/バックエンドグループに分割します。



それが判明：

1. gf_info_sentry_back_dev
2. gf_info_sentry_back_test
3. gf_info_sentry_back_release
4. gf_info_sentry_back_prod
5. gf_info_sentry_front_dev
6. gf_info_sentry_front_test
7. gf_info_sentry_front_release
8. gf_info_sentry_front_prod

したがって、バックエンドのエラーが原因でフロントがピクピクすることはなく、その逆も同様です。



スタンドが異なれば、開発者の対応の緊急性も許容されます。



プロジェクトの本番インスタンスは1つのクラスターにあり、他のすべてのインスタンスは別のクラスターにあるため、チャネルをクラスターにグループ化して次のようにする方法を検討しています。

1. gf_info_sentry_back_dev-クラスター
2. gf_info_sentry_back_prod-クラスター
3. gf_info_sentry_front_dev-クラスター
4. gf_info_sentry_front_prod-クラスター

チャネル編成の例

聴衆への質問

1. 私がリストしたものにどのようなコミュニケーションルールを追加しますか？
2. チーム全体のレベルでメッセンジャーで構成/使用できる他の便利なものは何ですか？