与软件开发团队的良好沟通小小书 XXshu

大多数软件开发人员一整天都在与同事或什至与客户进行交流。

这种交流大部分时间都是通过书面形式进行的，在某些情况下，即使是在良好的交流者之间，也可能导致一些误解。

GitHub，聊天，视频会议/电话和电子邮件是我们使用的一些媒体。有时被遗忘的是每个人都有其优点，缺点和特定目的。如果使用不当，它们会产生很多噪音：无用的对话有时会损害开发人员对真正重要的活动的关注。

这篇文章是有关改善软件开发团队成员之间沟通的一些技巧，重点是“何时”使用每种媒体来达到每种目的，并且主要是有效地使用。

总体而言，聊天是团队之间大部分沟通的媒介。

媒体分为公共渠道（有一群人）和私人渠道（只有两个主题），由于媒体的大量使用，很可能会发出噪音。

这里的黄金法则很简单： 尝试进行交流时尽量少惹恼别人 。我们作为开发人员的工作需要大量关注，而在我们的思维过程中被打断会降低我们的生产力。

以下是有关如何善用聊天功能的一些技巧：

确保每个频道的主题划分都很好 。例如，请勿将一个项目与另一个项目混在一起。
不要把严肃的事情中的 “乐趣”混在一起 。重要的是要有一个能防止洪水，gifs等的替补山羊通道。这通常可以防止严重的渠道被“污染”。
避免一直都提@所有人 。如今，大多数聊天都具有提及功能，该功能会向某些用户发送特殊通知。这也可以用于通知某个频道的所有成员。请谨慎使用此功能：大多数情况下，您实际上并不需要戳所有人来回答您。
忽略（或离开）无关紧要的频道 。如果有人“只是”因为“邀请”了您（我的意思是让您到那里），并且主题并不重要，请不要在此上浪费您的时间和精力。
避免过多的机器人 。如今，大多数聊天都允许您添加从其他服务发送通知的漫游器（例如，GitHub，允许您添加漫游器以在某些存储库上发生某些操作时发出警告）。乍看之下听起来很棒，但如果发布的次数过多，很快就会变得混乱。示例：通常，当某个回购发生某些事情时，用户已经收到了一封电子邮件。现在，假设您在聊天中也收到相同的警报。这种事情通常比帮助麻烦得多，应该避免。
如果主题仅在两个人之间，请进行私人聊天 。这只是对“尝试在尝试交流时尽可能少惹恼人”规则的加强。

如果您的团队在您的项目上使用开源软件开发过程（具有拉取请求，评论等）（如果没有，则可能应该这样做），经常会有来回反馈。

在此基础上，至关重要的是，沟通要清晰，直接，明确地进行（我们在谈论可交付的代码）。

以下是有关如何对请求请求注释提供良好反馈的一些技巧：

这篇文章提供了一些有关如何在请求请求审查中表达自己的好技巧，值得一试。

这可能是这里提到的媒体中最“史前的”和被低估的，但是它在您的工作流程中仍然有价值。

电子邮件具有两个非常重要的功能： 它是异步的 （通常您不需要在收到电子邮件时立即回复电子邮件）和永久的 （如果您不删除电子邮件，它将留在那里）永远）。 GitHub注释也提供了这两个功能，但是通常很难检索到。

如果您要交换一些非常重要的信息，例如与客户达成共识的关键决策，文档或将来您基本上需要的任何东西，那么在这里提到的所有媒体中，电子邮件都是带有搜索和检索工具的电子邮件。从今天起，所有电子邮件客户都拥有良好而高效的搜索系统。

聊天通常总是有大量的信息交流，这使得搜索任何东西变得更加困难。同时，许多聊天工具限制了可搜索和可恢复消息的数量，这也是一个问题。

当然，如果您是一个有组织的云存储系统（Dropbox，Google云端硬盘等）非常有条理的人，则不需要使用电子邮件来存储信息。如果您是这种人，那就太好了！否则， 请为您组织索引的电子邮件服务😉 。

当对话不够清晰或花费时间太长时，一个好的解决方案是与所涉及的人发起视频（或只是音频）呼叫。

这些呼叫通常非常消耗，因为它们取决于参与者的大量关注（通常避免在呼叫时执行多任务）。 这是必须以小剂量但有效剂量使用的东西，以避免浪费所涉及剂量的时间。

要讨论代码审查，屏幕共享是基本的。 Google Hangouts，Zoom和ScreenHero（我最喜欢这份工作）之类的应用程序都具有此功能。

这样，该媒体非常适合以比这里提到的其他方式更快，更有效的方式解决长时间的讨论，从而大部分时间都在弥补其成本。