大家在做项目过程中是否遇到过这些情况：

我正在开发一个功能，这个功能的需求有那么点不清楚，要不要问下产品经理呢？算了，他坐在那边那排，懒得跑了，我猜这个功能肯定是这样的

我发现前端给我的页面和需求上的有点出入，和前端也不怎么熟，不找他了，我稍微折腾下也差不多，就按我这么办吧

那个模块是他写的，和他不太投机，我直接去改他的模块了

呃，这产品设计的有点粗糙，文案都不统一，页面绕来绕去有点晕，还有错别字呢，嗯，简单的错别字的我就先改了，其他的我也搞不定，先放着

...

功能终于做出来了，项目经理用了一遍，找到实现功能的技术说，我要的功能不是这样的啊？于是，项目经理和测试发现的问题，基本改了，没发现的，继续存在

产品终于上线了，所有潜在没修复的问题，都让客户烦躁

所以，最终客户反馈的问题，都是技术问题么？

参考上面的例子的整个过程，可以引出这样一个教训：不管客户说的问题是什么，它终归是人的问题，单单用技术解决是不够的。

阐述一下，客户反馈的大多是些 bug，只要技术上修复了，就行了，主要还是技术问题，为什么还要说终归是人的问题呢？是的，这次的 bug 修复了，是技术问题，下次呢，下下次呢 ... ，难道每次都要让客户烦躁一把，难道要把用户赶跑了才甘心，难道项目组团队最好就只能做到这个水平？

上面例子的整个过程，很大一部分是沟通问题：每当开发中出现问题的时候，通常已经有人知道了解决方法，但有权做出改变的人却不知道。

原因，上面就有很多：空间上离得太远、性格不和、自身性格问题、责任心问题；等等

那么，如何解决？最容易的，创造良好的沟通环境和机会，最好能让大家能坐到一起办公，这样能非常容易的面对面的沟通，沟通多了也会冲淡其他方面的问题（比如性格不和、和陌生点的人沟通有惰性，都是因为不了解，互相了解了就没这问题）。如果位置隔的远了，每日的站立会议就非常必要，每天有个 5 至 15 分钟，项目组成员站在一起，沟通自己的工作进展，以及遇到的问题。

上面是针对团队的，对于开发者自己，还是要培养自己养成这么个意识习惯，并去影响团队里的其他同学：每当你遇到一个问题，首先问自己这个问题是不是由于缺乏沟通引起的，你需要什么样的沟通来解决这个问题？需要什么样的沟通来使你以后避免这样的麻烦？

有兴趣的可以继续阅读《解析极限编程》

更多可关注微信公众号：PHP工程师