本文约2100字，建议阅读5分钟。
为什么外企或国企的职业经理人空降创业公司多数都会折戟沉沙？十有八九是因为他们不懂“过度沟通”。在敏捷化的企业或团队里更是如此，应对瞬息万变的市场和业务需求，消除闷骚程序员和技术“小白”客户间的鸿沟，力求产品做到最优，可以说唯一的方法就是时时地沟通，不断地沟通，反复地沟通，过度地沟通！
就像大话西游里唐僧的经典台词：
“你想要啊？悟空，你要是想要的话你就说嘛，你不说我怎么知道你想要呢，虽然你很有诚意地看着我，可是你还是要跟我说你想要的。你真的想要吗？那你就拿去吧！你不是真的想要吧？难道你真的想要吗？……”
这段貌似搞笑的“废话”，在敏捷开发中，却是一条真理——沟通务必明确、透彻，穷尽所有疑问！宁可矫枉过正，不可闭门造车！
沟通！沟通！沟通！
敏捷开发多采用短迭代，要求尽快交付可以工作的软件，所以项目的需求文档就很难像原来的瀑布开发模式一样面面俱到。这就要求我们多进行沟通以确保双方的理解一致。根据以往很多项目的经验来看，失败的项目大多都是缺乏沟通，成功的项目必然是沟通做的比较好的。
很多人做项目，拿到客户需求以后，自己简单看了看，然后就开始做了，等到做完一个迭代拿给客户看时，完全不是客户要的东西。这就像女朋友说喜欢吃水果，你不由分说就买了十斤香蕉送过去，因为你喜欢吃香蕉。结果被骂了，女朋友喜欢苹果樱桃火龙果……就是不喜欢香蕉。这都是对需求的理解比较片面，又不提前沟通，自以为是的后果。
还有的人，尤其是新入团队的人，客户写的东西或者说的需求，他没有完全理解，但不敢问，总觉得客户已经说过了，已经写过了，再去问是不是不妥？显得不专业，没面子……如果按自己的理解或者猜测万一对了呢？于是就碰运气。事实上我们主观的猜测常常都是错误的，尤其是在我们对项目没有全面了解的情况下。想想你被女朋友骂过多少次？“女孩儿的心思你别猜”，对客户也是一样的。
还有一种情况，就是我们自己发现了问题，需求上的，或者客户的流程上的，但是我们总是想等到明天再沟通，明日复明日，其实内心希望这个问题自动消失，但最终的结果往往是滚雪球一样，越来越严重。回忆一下分手的前女友，有没有恍然大明白的感觉？问题是不可能自动消失的，发现问题要主！动！沟！通！
很多时候，我们都不敢对客户说“no”。比如我们觉得客户的需求太碎片化，UI改来改去，业务细节不够明确，希望客户能提供一个比较接近Final Design的设计，但是总觉得给客户提意见不好，显得对客户不够尊重，会影响满意度和结账“效率”。实际上我们提出问题和自己的想法才是对客户最大的尊重，因为在项目中双方利益是一致的，就是把结果做到最好。女朋友需要的是值得依靠的男友，而不是言听计从的奴才，一味的顺从换不来爱情！
我们很多人习惯了一种沟通方式，不管什么问题都这一招，所有的问题都写邮件或者所有的问题都用语音，这也是缺乏沟通效率的方式。约会、情书、电话粥、语言留言、啪啪啪……十八般武艺轮番用，绝对比你只会聊QQ好使。
敏捷开发的正确沟通方式
首先，要树立平等的意识，统一立场，统一战线。敏捷项目里的沟通，不管是与客户还是与团队成员，大家都是平等的，沟通项目相关的问题都是平等的，应该把客户当作自己团队中的一员。客户花了钱，目的只有一个——希望项目做好，双方的目标利益是一致的。在此前提下，沟通应该知无不言，言无不尽，即便争执都是沟通方式之一，所有不以把项目做到最优而藏着掖着“打死不说”的行为都是可耻的。
小平同志说： “白猫黑猫，抓住老鼠就是好猫”，沟通也一样。下面是常见的几种沟通方式：
面聊
视频
语音
IM 文字沟通
邮件沟通
这几种沟通方式的效率一般是由上到下递减的。当我们与对方面对面的时候，根据对方的表情就可以看出他是否真的理解了我们的意图。
在实践中我们需要多种沟通方式的有效结合，比如离岸团队面聊的机会比较少，可以用视频和语音，但是视频语音由于强调及时性，需要大家的时间都合适才行。而且视频语音也有缺点，就是内容很难搜索，也较难在组内传播。而IM文字沟通在这两方面就体现出了优势，有历史记录，可多人分享等。
邮件沟通的优势是不需要客户立即回复，而且可以图文并茂加附件，给客户更多的时间思考，格式化的文档也更容易把一件事情描述清楚。
所以，我们在沟通的时候，要结合具体情况选择最适合、最有效的方式，多快好省地把问题沟通清楚。
一图胜千言
很多时候，图形化的沟通非常重要，对项目的设计、架构如果开发人员难以达成统一的认识，就是缺乏图形、设计图或者架构图。我们都知道，人对图形的理解和记忆力要好于文字。
系统之间的交互，软件如何部署，项目的架构封层等，这些用图形来表示往往一页纸就可以，而且大家都能一目了然。而只有别人对你的想法理解了，才能够发现你的问题，才能给出建议。我觉得软件项目，非常重要的两张图，一个是 Architecture Diagram, 一个是Use Case Diagram, 这两张图可以大大节省项目开发的沟通时间。
敏捷项目流行边做边改，我个人对此不太认可，因为客户付钱是让我们把事情做对，而不是把事情改对。那么如何避免不断修改？那就是先做一个原型，我说的原型是不需要花太多时间的，如果花太多时间就得不偿失了，比如UI我们可以在开发之前先画出Wireframe, 如果需要交互，我们可以先做交互的Prototype。现在有很多工具比如说Invision都可以建立静态图形之间的交互，这样可以大大减少返工的可能性。
很多人只问问题，导致客户回复的很慢，因为客户需要思考。然而有时候客户思考后给我们的方案仍不适合，一来二去浪费了很多时间。
我们上学的时候都喜欢做判断题，其次是选择题，再次是填空题，最不想做的就是问答题。那么将心比心，我们要想得到客户的快速反馈，是不是也应该尽可能给客户出比较容易做的题呢？
所以好的方法是，我们给客户提问之前，先想想我们是不是有其他可行方案？或者我们有多个方案，只是不能确定用哪一个？很多时候，其实我们是有可选项的。
实践证明，凡是我们提的方案被客户采纳的，自己做起来也更顺手，也就更有效率。
敏捷之美 ∣这里只有干货
联系客服
