开发团队如何进行“有效”沟通

沟通，在生活中是不可避免的；从每天早上的一句“早上好”，到晚上睡觉前的一声“晚安”，我们每天都在和亲人、朋友、同事进行着沟通。

但我现在想说的是公司开发团队之间的沟通：如何进行“有效”的沟通。

一个产品/项目有大有小，有的两三个人就可以完成，有的则需要几十甚至几百个人的大团队来完成，但即使是一个大的项目，也往往会拆分为一个个小的团队，常见的一般是6-10人左右的开发团队。

那么，在一个产品的开发过程中，这6-10人的开发团队如何才能真正做到"有效"的沟通呢？

开发团队如何进行“有效”沟通，我们需要明确两点：1. “有效”的沟通是为了解决问题；2. 开发团队间的沟通一般可分为日常沟通及会议。

1. 什么是“有效”沟通

“有效”沟通不是“早上好”、“晚安”，它通常有两个特征，1. 有明确的目的，2. 实现了沟通的价值。
第一点，明确的目的既指自己清楚此次沟通是为了什么，同时也让对方清楚此次沟通的内容。第二点实现沟通的价值，是指这一次沟通是有效的，两方都在这次沟通中对此沟通目的了解并围绕其展开了探讨。

2. 如何进行“有效”沟通

团发团队中，如何进行“有效”沟通，需要分为两种情形来讲：

2.1 日常沟通

团队开发不同于个人开发，很重要的一点是团队间的相互协作，既然有协作，就肯定会需要沟通。日常沟通包括开发问题的探讨、故障的实时处理、不明确需求的询问等。日常沟通一般有两种方式，面对面沟通与通讯软件沟通。

• 1. 在日常沟通中，首先，需要明确沟通内容：
     例如：A对B说“出bug了，你看一下”，那B绝对的一脸懵逼，啥bug，一定要我看吗？
     但是，如果换一种方式，A对B说“昨天你svn提交后，项目编译提示缺少资源文件，你看看是否少提交了”，B就很容易的得到了此次沟通的内容，可以明确的知道自己需要检查svn是否漏提交资源文件。
• 2. 其次：简单的语言描述：
     不要刚开始沟通就“我看了xxx模块，发现xxx问题，然后根据xxx问题，又发现存在xxx问题，最后又根据xxx问题，定位到xxx代码，然后发现svn这个代码是你提交的”，想想这一连串的语言描述，有几个人能get到重点。其实，刚开始沟通时，没人会管你怎么发现的问题，你只需要简单表达出你发现的是什么问题，然后再一起探讨解决方案。
• 3. 第三：不仅是述说，还需要有反馈，确保沟通双方信息对等：
     既然是沟通，不可能完全是一个人述说，需要尽量得到对方的反馈，以确保双方信息对等，否则，可能A说了“123”，B理解成“321”；这个，在开发与产品的沟通中经常见到，产品说一个需求，开发啥都不说，最后产品说完，开发做完，结果把一只老虎做成了一只猫。所以，一次有效的日常沟通，一定是双方或多方都参与的，并且在沟通中，需要实时注意对方的理解与自己的理解是否出现偏差。最好是能够在沟通结束后由对方复述一下，或者自己总结一下让对方听听是否理解一致。

2.2 会议

会议与日常沟通不同的是，会议一般是多人参与，因此，会议相对于日常沟通而已，更难实现“有效”沟通；但同时，相对于日常沟通，会议可以有更多的沟通辅助工具，如邮件，ppt，投影，白板，文件等，在会议前可以邮件通知会议时间、地点、该次会议的目的、参与人员等，会议中可以通过ppt展示，白板书写，分发文件/报告等方式来更形象表达所描述的内容。
进行一次“有效”的会议，需要做的比日常沟通更多。

• 1. 首先，需要确定会议的目的/类型，进而明确会议内容（一次会议最好只做一件事）：
     如，每日站会/晨会，则是为了了解团队中每个成员的开发进度及阻塞点，因此，由团队成员依次表达“昨天做了什么”、“今天准备做什么”、“遇到了什么难点”就够了，没必要说太多详细的事情，更不需要在会议上对问题进行讨论；而如果是项目启动会，则需要将项目中的需求详细的讨论，让所有团队成员对需求的理解与PO一致，同时也需要对功能的开发时间做出预估；其他如总结会、产品验收会等都需要达到相应的目的。
• 2. 其次，制定会议需要达到的目标：
     这是对上一点的补充，明确会议内容后，需要就此次会议设定需要达到的目标。
• 3. 开发团队成员的参与：
     在会议中，不能光是会议支持人侃侃而谈，更重要的是团队成员都参与进来，开发团队的会议需要团队成员之间思维的发散与碰撞，以及每个成员对项目/功能点所了解的信息进行共享。
• 4. 限制谈论范围：
     上面说到团队成员之间思维的发散与碰撞，但是，每一次发散都是基于会议内容而进行的，成员不可以在谈论“支付功能如何实现”的时候发散到“上次线上出现的bug如何解决”，如果主持人发现问题的探讨过于发散，则应当及时纸质并重新阐述该问题。
• 5. 确保团队成员真正的理解：
     在曾今的会议中，经常出现某些团队成员在探讨完毕后，仍然对探讨内容不太了解，特别是需求分析及任务分配时，这种情况出现不少，这会导致在后台开发中出现“要做老虎，结果做了一只猫”的悲剧；后来，我们是这样做的，探讨完毕后，由团队中发言最少的成员进行总结，团队所有人听是否有异议。
• 6. 会议总结，并指定会议中探讨内容的责任人，落地人及执行周期：
     会议的总结，既是对此次会议内容的回顾，也是为了确保每个与会人员对此次会议内容的理解不出现偏差，同时，将每项任务都分配到人，有利于任务的执行。
• 7. 会议纪要：
     一次“有效”的会议，肯定是由产出的，会议纪要就是本次会议的产出物。当然，因为是开发团队会议，我们主张会议纪要简化，没必要准一堆文档或者ppt等；这个会议纪要可以是对会议中白板或投影的拍摄照片，也可以是对会议的简单(关键)总结。

ps：时间晚了，写的有点急，总感觉有什么遗漏，后续再看看补充...

简书：ThinkinLiu 博客: IT老五

---