从沟通反馈到高效能研发

企业最根本的的竞争优点既不是来自资本实力、发展战略，也不是来自技术，而是来自团队协做，由于团队协做能力是很是强大并且弥足珍贵的。 -- 《团队协做的五大障碍》

前几天逛书店翻的一本书，这是开篇的第一句话。联想了最近思考的一些东西

团队协做可以高效、高质量的前提是什么？

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

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

平常沟通

通过思考才发问

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

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

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

如何发出问题

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

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

如何面对他人的求助

• 敢于承担，分内的事，确定要主动站出来处理。份外的事儿，若是本身能解决的或顺手的事能作的就举手之劳，若是不能也能够说下具体缘由或者给对方一个指引，“好比，建议你找XXX问下”。团队信任千万不能说“不关我事儿”之类。
• 勇于说不，对于明显不靠谱的需求或者问题，勇于说不，就事论事，凭感受每每是不许的，对于有风险的事情，未雨绸缪，摆出本身能作的范围，讲出存在的风险，至于投入和产出的权衡和风险控制交给对方，并说在咱们本身角度上专业的考虑。作能作的，不能作的有风险的也事先说明。

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

• 大事小事给一个时间预估，无论是交代的事情仍是作开发，对事情完成时间有一个预估，或者根据事情优先级安排，给出一个deadline，让对方内心也有底。对于一个靠谱的人：凡事有交代，件件有着落，事事有回音_。_是在职场的座右铭。
• 切忌承诺过满，答应作一件事，也给了时间，若是对风险评估不许，也会出现没有按时交付或者到点完成，因此在前边承诺deadline和完成状况的时候都应该合理的留有余地，由于事情每每有不可控因素。不然：一、没有按时交付，失去了信任；二、必须按时交付，只有加班。到头来都是本身消化了风险带来的后果。

及时主动反馈，沟通闭环

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

开发流程中的沟通

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

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

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

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

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

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

全体会议要谨慎，若是能够你们站着说

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

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

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

不少时候咱们都是在有限的时间内作不少事情，因此有的时候会根据优先级取舍，可是咱们在追遇上线时间的时候，咱们要交付的是一个可靠的产品，**交付完整的高质量的产品特性和功能是咱们的研发价值。**在保证质量的状况下适当取舍，好比功能量、工做时间。

总结

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

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

小结以上

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

扩展阅读

文章

• 工程师文化落地的几点思考
• 高效程序员的 45 个习惯
• 无限的清单之我的平常工做的清单
• 软件的高质量意味着高成本？

书籍

• 极简工做法则 - 如何成为领先的少数人
• 软技能 -  代码以外的生存指南
• 成为技术领导者 -  解决问题的有机方法