谁将从本文中受益？
本文对5-10-15人的小型项目团队的领导者和成员很有用。
使用什么，为什么？
我们个人使用Slack来交流和共享信息。
下面写的大部分内容都可以用其他使者组织。
我们使用Slack的原因：
- 方便组织群聊（渠道）
- 线程的存在-创建对话框分支的能力
- 工作对话与非工作对话的区别。在Slack中工作。其他-电报/ watsap /在任何地方
- 反应可用性
- 提醒可用性
- 将Slack与许多工具集成的能力
如果有任何Slack替代方案，上述所有6点都是正确的，请在评论中告诉我。对于这种替代方法，请告诉我它具有哪些炫酷功能并且经常在您的团队中使用。
团队中的沟通规则是什么，为什么？
1.不要在下午进行交流
我们仅在以下两种情况下将通信留在PM中：
- 讨论一些需要隐私的内容。
- Memasiks /笑话等泛滥。
对于其他所有内容，我们使用通用的沟通渠道。
现在，我将告诉您它的用途。稍后我将告诉您如何组织常见的沟通渠道，以免造成混乱。
为什么需要此规则？
需要此规则以：
- 当有人偏离路线并开始做错事时，有可能会遇到这种情况。
- 当某人开始做错事时，可能会发现情况。
- 在任何情况下，两个人都同意某件事，而其他人则遭受此苦。
- 管理人员可以监视团队协作。
- 管理者可以跟踪冲突，怨恨的发生以及其他负面因素的发生。
2.标记上诉对象
任何消息都必须有一个收件人。一个或多个。
当提及某人时，您应该对其进行标记。
与多人打交道时，请标记所有人，而不是频道中的所有人。
为什么需要此规则？
需要此规则以：
- 并不是所有的聊天参与者都被群聊/话题中的消息分散注意力，只有那些被标记的人。
- 收件人弹出通知的可能性最大。例如，在Slack中，通知有时会丢失。
3.对消息做出反应
该消息 的收件人不应忽略某人发送的任何消息（不是自动发送的消息）。收件人在收到消息时必须给出答复。如果有多个收件人，则每个人都应做出反应。
为了不写短语“ ok”，“ understoder”等，Slack具有便捷的功能-反应。我们的团队成员通常会做出以下反应：眼睛：。领导者使用以下反应：eye：。
为什么需要此规则？
该规则对于发件人知道他的消息“没有丢失”是必要的。
4.使用线程
Slack具有线程等功能-创建“对话线程”并在其中而不是在主消息流中进行对话的能力。
此功能非常适合讨论单个问题。
为什么需要此规则？
该规则是必要的，以便不使消息的主要流弄乱，从而增加了信息的结构并简化了浏览过程。
5.记录在Slack以外发生的对话
如果在通话中进行了一些对话，则有必要根据通话结果抛出一个协议-一组反映对话结果的论点。
为什么需要此规则？
需要此规则以：
- 再次确保对话参与者正确理解彼此
- 我们没有忘记我们达成的共识
- 知道发生了什么，谁没有接受对话，但对对话的主题感兴趣。
- 可以参考对话的结果
- ...以及第一段中关于共同交流渠道的相同论点
协议必须有收件人并且要收到回复！
并非每个人都应被当作演讲者，而是这场对话的主题所涉及的人。
6.如果在15分钟的活动通信中仍未解决问题，则发起呼叫/会议
这里的一切都很简单：如果您看到自己必须写很多文本，并且如果聊天中出现一团糟，则需要发起呼叫并用语音讨论一切。
作为通话的结果-将协议发送给所有人。
7.举行日常书面会议
日常会议是小组会议，每个团队成员必须回答几个紧迫的问题并讨论当前问题，以使团队保持同步。日常会议的一组问题示例：
- 你昨天做了什么？
- 我今天要做什么？
- 我在途中遇到什么问题？
我们每天上午11:30至上午11:35举行专门的小组聊天会议。经理最后写信-在11:36。取消订阅后的任何人都被视为延迟。教育工作应与后来者一起进行。每个人都应根据每个人的信息贴上反应：眼睛：这种反应是对大家已经阅读每一条日常邮件的确认。
我们的每日消息模板：
- 我做了什么？
1. API方法/您好
2. API方法/ howareyou - 我该怎么办？
1. API方法/再见 - 问题：
1.爱丽丝，您认为您的任务将花多长时间？ - 问题：
1.部署失败。帮帮我！
在讨论问题时，请不要忘记第6条规则-如果问题/问题在15中没有解决，我们将其放在第一位。
在大多数情况下，考虑到准备集会的时间，我们每天需要花费每个人15分钟的时间。
为什么需要此规则？
为了有效地利用团队的工作时间，此规则是必需的。和耐心。
在实践中，无论我们的Scrum世界多么努力地努力工作，每天在一个团队成员的讲话中，剩下的整个团队都不会听他讲话，而是要听1-2个人。其余的都在等待轮到他们。通常，对于一个由10人组成的团队，这种每天的持续时间从半小时到一个小时，这意味着该团队中的大多数人只是在这个小时的大部分时间里坐着吃蛋糕。转换为文本格式可以使日常工作变得快速，简洁，并且可以固定。
8.奖励：在内部团队中，以文本格式讨论与产品及其创建过程有关的所有内容
我的个人经验是，当您进行书面讨论时，生活会变得更好：
- 需要
- 设计
- 实现
- 工作流程
- 建议和问题
实际上，这并非总是100％可能。
然后，当现场讨论上述列表中的内容时，应记录讨论结果。
为什么需要这个？
为了解决内部团队的以下问题：
- 总是：经理们认为自己随时掌握脉搏，但实际上，他们实际上看不到团队的表现。在群聊中进行交流时可以捕获的所有内容几乎都无法通过实时格式访问
- 通常：决策是在吸烟室中做出的，然后不会广播给所有相关方
- 有时：关于工作问题的讨论伴随着“无”的大量对话
如何设置Messenger？
为了方便订购频道，我们使用前缀系统。
由于我们的团队从事不同的项目，因此我们为每个项目提供一个前缀，并在渠道名称中使用它。
例如，我们有2个项目-GoldFixing和Aurrency。对于这些项目，我们使用以下前缀：gf表示GoldFixing，而aurm表示Aurrency。然后，与GoldFixing关联的所有频道都将以gf_前缀开头，并且看起来像gf_somechannel。与Aurrency相似，通道看起来像aurm_somechannel。
同时，项目内还可以有许多渠道。为了组织它们，我们根据它们的目的对渠道进行了分类。对于每个类别，它们都有自己的前缀。
渠道可分为4类：
1.杂货
这些是专用于项目内创建的产品的渠道。
前缀：prdct_
此类别中的渠道讨论了与该产品或该产品相关的所有那些问题。
因此，如果在GoldFixing项目的框架内创建了两个产品-平台和后台，那么我们为它们创建以下渠道：
- 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团队可以借鉴一些东西。
- gf_info_general-与组织部分相关的所有内容：声明，修订协议和流程。通常针对所有人，需要所有人的回应。
- gf_info_daily-此处每个人都取消订阅他们的每日消息
- gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
- gf_info_jira — JIRA
- gf_info_confluence — Confluence
- gf_info_deploy — . :
— Instance — Repository —
— Branch —
— Pipeline — gitlab
— Job — gitlab
— Triggered by — Slack ,
— Commit — - gf_info_sentry — Sentry
- team_backend — backend
- team_dlt — DLT
- team_frontend — frontend
- team_qa — QA
Advanced JIRA
如果将有关JIRA中发生的一切的通知倒入一个通道，则该通道将变成一堆消息。
为此，我们对通知进行了微调，并为JIRA设置了多个渠道，而不是一个：
- gf_info_jira_comments-用于JIRA中的评论通知
- gf_info_jira_qa-有关准备测试的任务外观的质量检查通知。该渠道只有质量检查人员和一名经理
- gf_info_jira_qa_verdict-有关从状态“ TEST”到“ DONE”或“ REWORK”的票证转移的通知
来自哨兵的高级设置通知
每个项目上都有几个项目实例（立场）：
- 开发站-开发人员站
- 测试台-测试台
- 发布架-用于运行发布候选的架
- 生产摊位-生产摊位
我们为他们每个人创建了一个单独的哨兵通道。
这样，当后端发生错误时，前端开发人员就不会抽搐，反之亦然，他们也将这些通道分为前端/后端组。
原来：
- gf_info_sentry_back_dev
- gf_info_sentry_back_test
- gf_info_sentry_back_release
- gf_info_sentry_back_prod
- gf_info_sentry_front_dev
- gf_info_sentry_front_test
- gf_info_sentry_front_release
- gf_info_sentry_front_prod
因此，前端不会由于后端的错误而抽搐，反之亦然。
对于不同的看台，开发商回应的紧迫性是可以接受的。
由于项目的生产实例位于一个群集上，而所有其他实例位于另一个群集上，我们正在考虑如何将渠道分组到群集中并获得：
- gf_info_sentry_back_dev-集群
- gf_info_sentry_back_prod-集群
- gf_info_sentry_front_dev-集群
- gf_info_sentry_front_prod-集群
渠道组织示例
给听众的问题
- 您会在我列出的规则中添加哪些交流规则？
- 您还可以在整个团队中在Messenger中配置/使用哪些其他有用的东西？