后台技术人员应该有良好的沟通习惯

大家在做项目进程中能否遇到过这些状况：

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

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

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

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

…

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

产品终于上线了，一切潜在没修复的效果，都让客户焦躁

所以，最终客户反应的效果，都是技术效果么？

参考下面的例子的整个进程，可以引出这样一个经验：以后在网站制造时，不论客户说的效果是什么，它终归是人的效果，单单用技术处置是不够的。

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

下面例子的整个进程，很大一局部是沟通效果：每当开发中出现效果的时分，通常曾经有人知道了处置方法，但有权做出改动的人却不知道。

缘由，下面就有很多：空间上离得太远、性情和睦、自身性情效果、责任心效果；等等

那么，如何处置？最容易的，发明良好的沟通环境和时机，最好能让大家能坐到一同办公，这样能十分容易的面对面的沟通，沟通多了也会冲淡其他方面的效果（比如性情和睦、和生疏点的人沟通有惰性，都是由于不了解，相互了解了就没这效果）。假设位置隔的远了，每日的站立会议就十分必要，每天有个 5 至 15 分钟，项目组成员站在一同，沟通自己的任务停顿，以及遇到的效果。

最终，还是要培育自己养成这么个看法习气，并去影响团队里的其他同窗：每当你遇到一个效果，首先问自己这个效果是不是由于缺乏沟通惹起的，你需求什么样的沟通来处置这个效果？需求什么样的沟通来使你以后防止这样的费事？