标签：
第四章——流于形式的沟通
作为开发人员，我们是一定要接触客户的，通过接触客户，我们才能知道客户的需求，进而，我们才能得到客户的信任，得到一个项目。然而，作为程序员的我们，显然不能期望客户或者客户的代表用专业的编程语言来向我们描述自己的需求，在这个时候，沟通就显得尤为重要。
我们不能期待客户学会c语言，同时，我们是软件公司，显然我们也做不到谙熟项目所涉及的所有业务，也许这时候我们就需要找到一个联通二者之间的媒介——聘请行业咨询师，但是行业咨询师自然也是专业的，所以他们也有自己的语言，要咨询师们与客户接触时，客户不懂他们的语言，在咨询师与我们接触时，我们还是不懂咨询师的语言(UML)，无形之间又增加了难度。其实无论什么语言，最主要的功能就是交流沟通，c语言是程序员与计算机之间的交流语言，汉语是我们日常之中沟通的语言，而UML是模型语言，所以，只要能够沟通好关系，让彼此都明白我们的意思，就算是用甲骨文都没关系。所以，想要与客户之间有一个好的沟通，最好还是找到一种我们彼此都熟悉的语言最好，这可以通过我们与客户互相商定进而最终确定。
沟通是一门艺术，如果你能用最少的时间理解了客户的需求，进而以最精炼的语言让客户明白我们已经理解的他的需求，那么这个项目就已经是十拿九稳了。想在与客户有限的见面时间或机会完成这些任务，幕后工作一定是不能少的，这可以概括为“最简沟通”。即，首先我们要借助一切可行的手段了解相关软件成功经验，了解客户所在公司的理念和结构，了解同类公司的优秀管理模式，这样我们就可以了解客户项目中所有会产生需求的信息点。然后把这些设计成问题，回馈给客户，等到客户回复后我们再调整偏差的方向。这样我们就能确定了项目的实际目标和远期方向，然后我们再设计需求条目，即基于客户所给的数据进行需求分析，当然，这是比较苦的活，我们需要建立表格，建立数据库，了解客户的组织机构及相互关系，最后映射到各个模块，再找出模块之间的关系，最后建立系统模型，最后，珍惜每一个和客户见面的机会，利用这个机会让客户提出意见，尽量完善调研报告。一定要珍惜和客户见面的机会，不要做一些没用处的沟通。
为不存在的角色流下沟通的渠道，写程序就像历史事件一样，如果不留下记录，那么以后再次回顾时候自然就巨大的困难，众所周知，程序的维护比开发更难，所以在做项目时候就要为以后的维护做出充足的准备，当然，这里的准备不是指的代码之中的注释，而是需求阶段、设计阶段、开发阶段、测试阶段的每一条思路，每一个接触的人，每一个程序单元的构架，每一个变化，和每一个测试样例等等。虽然大多数的工具都有历史记录的功能，但是这些功能毕竟不如人为的来的详细可靠。
流于形式的沟通是不可取的，沟通不是请客吃饭联络感情，沟通是有目的性的，没有明确目的性的沟通就是浪费自己和他人的时间而已。沟通也不是仅仅存在于开发人员和客户之间，公司内部的人员也需要有效的沟通来了解彼此的思路。至于沟通的成功与否并不在于选择什么语言，而是在于选的语言是否有效，如果真的有效、你和别人又都可以理解的话，就算你真的用甲骨文沟通又有什么不妥呢？
标签：
原文地址：http://www.cnblogs.com/389629916muyachao/p/4906236.html
