The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
每个软件团队都以自己特定的方式组织沟通。有些使用Slack，Trello或GitHub；其他人只是坐在同一个房间里。有许多方法和工具。我相信可以根据它们对项目造成的“损害”程度对它们进行排序。这是目前我所知道的全部列表。
我所说的“损害”主要是由这些沟通渠道和项目文档之间的距离引起的。人们离文档越远，失去信息的风险就越大。而丢失的信息是任何项目中麻烦的第一来源。
以下是列表；它从对项目造成最大损害的沟通方式开始，然后逐渐降至最“成熟”和专业的方式，这些方式带来的麻烦最少：
电话通话。比咖啡休息好一点，但仍然是一个大问题。电话通话是完全无法追踪的。你在这些通话中交流的信息将永远消失。嗯，你可以录音，但是搜索电话通话记录是一项艰巨的任务，没有人会去做。
会议。这是咖啡休息之后的下一步，因为它有一定的结构和会议记录。会议可以被记录下来（在线和离线），其结果被归档，并且决策被记录下来。但实际上，这些都不会真正发生。会议只会浪费你的时间和赞助商的金钱。
电子邮件。如果您能在电子邮件中加入一些正式性并规范所有参与者，您的电子邮件历史可能会被视为项目的一个重要部分。这个重要部分会有多么有组织和易于浏览？这是一个很好的问题。在大多数情况下，它只会变成一团糟。
邮件列表。它们比电子邮件更好，因为一些软件会将其存档并使其可用和可浏览。但是要找到确切的讨论主题、决策的地方，以及为什么做出决策、谁提出了什么建议等将会很困难。
Slack（松弛）。有许多类似的替代品基本上都是在线聊天工具。它们的主要问题是很难对这些聊天进行分类、将消息分组或之后再找到它们。仅仅几天后，这些信息流就变得毫无用处。当然，如果你真的想在其中找到某些东西，是可能的。但这种“文档”的质量非常低。
Trello。通过Trello，我指的是任何任务/工单跟踪系统——它们是将对话和讨论立即转化为项目工件的绝佳工具。您不需要编写任何文档；一切都已经在那里。问题是它们与主要的项目工件——源代码及其提交、合并冲突、构建日志等仍然相距甚远。
GitHub（GitHub）。这是您可以使用的最佳工具。它将与产品本身的沟通集成在一起。您编写的代码和围绕它展开的讨论实际上都在同一个地方。
你的项目现在正在使用哪一个？我强烈建议你远离列表顶部的通信渠道。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:58
