团队协作能够高效、高质量的前提是什么？

就是信息同步，是沟通反馈。因为沟通反馈是接收指令、执行并复命的过程。

关于沟通反馈想从两个方面聊一聊这个高效沟通的话题：
1、日常沟通，比如面对面、IM或邮件；
2、软件开发流程中的沟通反馈；

日常沟通

经过思考才发问

我们经常能够在开源技术群里见到类似这样的场景，某个同学在研究新技术，在安装或者使用的时候遇到报错了，假如好的软件，报错信息一般都很详细，指出报错的原因和代码位置，甚至有的软件解决方法都会有提示，只不过有的报错是英文，但是仍然会有人稍微遇到问题就复制报错信息发到群里，这样一般是没人愿意理会的。

抛出问题，也请交代问题的背景

每个人并不是专一负责某一项事情的，当我们遇到问题不得不向另外一个同事求助的时候，可以尝试简单的描述问题、发生时间、发生经过、相关数据。只说结果，如果是别人直接甩问题给我们，我们也会一头雾水，推己及人，思考问题可以换位想下。
如果是前后端分离的项目或者App，假如方便的，最好能确定下是客户端问题还是接口问题，如果是接口问题，可以带上相关链接参数或者响应数据，这对排查来说，再好不过。
交代问题背景的同时，都相当于自己捋了一遍逻辑，说不定就有了新的解决思路。

如何发出问题

工作时间，每个人的时间都是宝贵的，那就切中要害，简单扼要：

去掉无用的口语，比如在吗？在忙吗？现在有没有时间？有事说事，对方闲下来的时候自然会回复。
先发出文字描述，再发出佐证你问题的相关图片。我们先发了图片，对方不知道问题和背景，对方也不太会一直盯着聊天窗口等着打字，然后去做别的事，等我们发了文字，再回来看，这就相当于打断对方至少两次。
注意语气，对于大多数同级的同事，没有任何人有责任或必须帮你做什么，所以，我们是寻求帮助，不是发号施令。对方能够伸出援手最好，不管主观还是客观原因如果不能，也应该给予肯定和感谢。
问题都有优先级，适当的时候抛出适当的问题，但是假如有依赖项或者阻碍开发的问题，应该第一时间的提出来反馈给上级或同事，自己也能合理安排时间。

如何面对他人的求助

勇于承担，份内的事，肯定要主动站出来处理。份外的事儿，如果自己能解决的或顺手的事能做的就举手之劳，如果不能也可以说下具体原因或者给对方一个指引，“比如，建议你找XXX问下”。团队信任千万不能说“不关我事儿”之类。
敢于说不，对于明显不靠谱的需求或者问题，敢于说不，就事论事，凭感觉往往是不准的，对于有风险的事情，未雨绸缪，摆出自己能做的范围，讲出存在的风险，至于投入和产出的权衡和风险控制交给对方，并说在我们自己角度上专业的考虑。做能做的，不能做的有风险的也事先说明。

还有一句话是：把不靠谱或不确定的事情延迟着手，说不定事情就变了或者自己就没了。

大事小事给一个时间预估，不管是交代的事情还是做开发，对事情完成时间有一个预估，或者根据事情优先级安排，给出一个deadline，让对方心里也有底。对于一个靠谱的人：凡事有交代，件件有着落，事事有回音_。_是在职场的座右铭。
切忌承诺过满，答应做一件事，也给了时间，如果对风险评估不准，也会出现没有按时交付或者到点完成，所以在前边承诺deadline和完成情况的时候都应该合理的留有余地，因为事情往往有不可控因素。否则：1、没有按时交付，失去了信任；2、必须按时交付，只有加班。到头来都是自己消化了风险带来的后果。

及时主动反馈，沟通闭环

有阶段性进展、中间遇到问题、事情做完，对方都有知情权，并且我们也有义务主动告知对方，如果总是领导追问事情怎么样了，可能沟通或工作方式哪里出了问题。
沟通闭环，特别是领导交代的事情，如果不了了之，只能让领导觉得我们是一个靠不住的人，以后怎么还会安排事情，可能距离危机也不远了。切勿掉进反馈黑洞里。

开发流程中的沟通

写文档不是浪费时间，面向文档开发也不是可耻

在极客时间《10倍程序员工作法》中，作者多次强调“以终为始”的原则和一个概念：DoD（Definition of Done，完成的定义），不管日常沟通，还是软件开发，做事情先要知道做什么，做的事情是什么样，达到什么数据的的事情是我们想要的，先定义好事情本身，才能让我们做好充分的准备，不做无用功、少返工，降低不确定风险。把确定的东西尽量在开始前确定好、量化好，形成文档落实下来，这都是团队各个角色共同参考的唯一的标准。
在标准的软件开发模式中，前期需求搜集、需求分析、软件开发设计、数据库设计等等都是文档先行，定义好各种验收标准才动手写代码，而编码只是软件开发很小的一部分。只不过在现在很多时候，无形之中都适应了“边做边改”的开发模式。不管我们身处哪个角色，产品、设计、开发、测试，都应该了解软件开发的完整流程，有一个整体观、大局观和团队感，我们是分工不同但是为了一个目标做同一件事。软件开发是一个系统工程。

我并无意夸大开发一个产品的复杂度，但是作为一个跨部门、多人参与的项目，肯定要有依据，有定义和有资料可查、可追溯。聊天记录并不能成为严格的正式的事物标准。

“一切版本化”，不仅仅是代码、服务器配置、还包括设计稿、各种文档。
这不仅是以后要做什么、怎么做的问题，还是以前做了什么、谁做的、怎么做的问题。
不仅方便着手做事情的人，也方便人员流动和新人接受学习和重构梳理。
做好文档，百利无一害，有人会觉得浪费时间，但是欠的迟早要还的，有的还的方式是返工，是重做，是质量和体验欠缺。
写文档也是整理思路的过程，如果自己都捋不清又如何让别人能明白呢

最轻最高效的沟通方式还是面对面

为什么明明我们就几步远的距离，还要浪费时间在打字和等待中？特别是如果很紧急的情况下，为什么不打电话和去座位上找他？IM工具只是工具，不是每个人都必须分分秒秒都打开对话框等你发消息。
当然，简单的问题，IM没问题，只是针对那些几句话仍然解释不清楚的情况。

全体会议要谨慎，如果可以大家站着说

最重的沟通方式就是开会，我们都体验过开会，特别是干系人全部拉在一起。如果不能保证会议提前在议题和内容和与会人思想上有准备的情况下，开会很可能成为几个人的秀场，而剩下的人昏昏欲睡。
国外有的团队提倡站会，拉近距离，不会像坐着太舒服，发言拖沓而变成茶话会。
所以，开会要谨慎，如果不得不开，得保证开会能够有所准备，尽量形成决议，让会议有所产出，如果不能，先面对面讨论好。
更多可以参考

4个步骤助你远离低效会议

Deadline更多应该是认真评估后给出的承诺，不是成为“死期”

很多时候我们都是在有限的时间内做很多事情，所以有的时候会根据优先级取舍，但是我们在追赶上线时间的时候，我们要交付的是一个可靠的产品，**交付完整的高质量的产品特性和功能是我们的研发价值。**在保证质量的情况下适当取舍，比如功能量、工作时间。

总结

以上是关于沟通反馈话题的一个总结思考，有的是个人感悟，有的也是教训所得，还有的是其他团队分享的要点汇总。

本文的侧重点也是放在个人和团队中间的信息同步和日常交流的一些要点。并不牵扯特别繁琐的沟通技巧和语言艺术之类。大家交流更 Nice 一点，自然心情也好，效率也高，Work & Life Balance，每天工作开心，生活开心。

小结以上

凡事有交代，件件有着落，事事有回音。
推己及人。
DoD, 定义好完成标准。

扩展阅读

文章

书籍