1. 客户需求不清晰

有时候客户其实并不是很清楚自己具体想要什么，或者并没有很全面的考虑很多细节，只是根据自己的大概想法提出一些需求，就让我们来实施。

这 种情况是比较常见的。如果我们不能及时正确的和客户沟通，会给后续合作带来很多问题。在我的第一个项目中就有这种情况，早上和客户开会，客户说需求是怎么 怎么样的，然后具体的可以参考文档。而在会议中是没有时间来了解具体的细节问题的，和客户大体上过一遍需求，澄清一些问题，那么客户就睡觉去了，我们一天 的工作也就开始了。

而在实际开发的过程中，会发现客户的文档只是一个粗略的需求框架文档，并不是 一 份拿来就可以用的需求规格，所以在实施的过程中就会产生很多细枝末节的问题和条件分支。我当时的做法是把遇到的问题都一一列举出来，然后写邮件给客户寻求 答案，表面上看这是很正常的处理方式，没有什么问题，但是没有得到客户的回复之前，今天什么也做不了，这就浪费了大量的时间。

第二天跟客户例会的时候去澄清前一天邮件中的问题，问题澄清之后开始做，发现做的过程中又有新的疑问产生，然后又给客户写邮件，等客户回复，如此循环。日积月累，客户就会有些微词了，客户当时的一句话记忆犹新：I’m not babysitter. Blablabla…… 当时是觉得客户有些莫名其妙的，我已经尽可能详细的去描述自己的问题了，而且确实是客户提出的需求不明确，根本没办法实施开发。而现在看来这就是一个典型 的沟通问题。在之前的公司遇到类似的问题，会把问题抛出来给项目经理，项目经理去协调解决，而且因为大家都在相同的办公室，有着相同的工作时间，问题很快 就能澄清。而对欧美软件外包来说，当疑问产生的时候，已经没办法和客户即时的去澄清了，而且提问回答式的邮件，往往需要好几个来回才能彻底解决问题，这中 间会浪费大量的时间成本。

而现在如果遇到这样的问题，我自己先会去思考和分析，根据自己对项目的了解和过往的项目经验，找到一种合适的方案来处理，做一些demo出来呈现给客户，然后在此基础上再给客户提出我的问题：“在处理这个需求的时候，我遇到了这样的问题，我觉得有这样几种情况，经过分析，不同的情况我觉得应该这样去处理，这是做好的demo， 有几个地方我拿不准的，您看看我的处理方式是不是正确的，如果不正确，应该怎么做，我第二天来修改。”这是一种更积极的沟通方式，比第一种被动的提出问 题，然后等待答复好得多得多。第一，我们没有浪费一天的时间来等待客户的回复（况且有时候客户的回复会耽搁，可能就不止一天），第二，我们可以让客户看到 实际的demo来决定如何处理具体的疑问，客户也不会觉得自己是babysitter，什么事情都要劳烦他。

2. 突然的任务间断

有时候客户会因为临时有事不能参加例会或由于其他原因而导致我们一天都没有实际的项目任务。

这样的情况一般需要第一时间去联系并告知客户：现在手头上的任务都已经完成，请求新的任务。同时根据项目的情况，去安排自己一天的任务，并告知给客户，在没有收到新的任务之前我会做什么。

这 时能做的事情其实比有任务的时候更多。可以去熟悉项目代码，可以重构之前的代码，可以去深入了解一些项目中可能会用到的技术，可以去熟悉一些与自己相关联 但是平时没有涉及到的功能，可以去预测客户下一步的工作内容并提前熟悉……总之，这样的时间不是给我们放假的，而是一个很好的缓冲机会，让我们可以站在客 户的角度去沉淀和思考项目，对项目进行更深入的理解，以及对项目日后的开发内容做一个良好的积累，以便新的任务到来的时候，可以迅速的投入。

3. 客户建议的方案非很好

有时候客户安排的任务会很具体，具体到解决方案和实施计划，而这个方案其实是有瑕疵或者我们觉得不是很好的。

这是我第二个项目中经常出现的一种情况。客户经常会提一些实验性的需求给我，比如客户有一天突然要我去了解一个第三方的报表工具，并做一些图表报表的demo给他，这其实是很明确的一个指令，我可以很爽快的回答客户OK，然后做一个demo发给他。

但是根据我自己的经验来说，客户应该是无意中被第三方报表网站上的一些炫酷的报表demo吸引了，想引入到项目中来，而我们自己的项目已经在使用SSRS了，可能客户觉得SSRS的报表不够漂亮或者其他什么原因。所以我当时就询问了客户的想法和目的，和料想的一样，客户希望能有一个漂亮的图表给他的领导去看。于是我就跟客户一起分析：第一，SSRS里 面也有很多漂亮的图表，只是我们之前没有去使用过，修改下样式之后也很炫，并且可以很好的和现有的项目集成。第二，这一块的内容并不是很多，我们有没有必 要花时间和资金成本在第三方报表上。最后经过和客户的讨论，我们发现他的设想通过现有的东西都能实现，也就否定了他之前想采用第三方报表的方案，而是用现 有的技术来做几个漂亮的demo，并且最终被客户采用了。在这之后，客户就更加信任我了，有了什么想法都会主动的和我一起讨论解决方案。

这个案例说明当我们接到客户需求的时候，应该站在项目的角度，多思考，有疑问的时候应该合理的去质疑客户，并且应该第一时间去和客户沟通，而不是一味的直接接受客户的命令。

因 为我们服务的好多都是些非软件行业的中小企业，有时候客户会显得不那么专业，以上几种情况就会时常发生。而站在客户和项目的角度来分析问题，并积极的与客 户沟通会让我们在项目中有更多的主动权。当即使客户没有给我们安排工作，我们也能自己给自己找到工作内容的时候，项目的成功也就水到渠成了。

另外，平时与客户的沟通中有很多细节的问题是我们应该注意，很多时候细节决定了我们的专业水准。

1. 沟通方式的选择。一般我们与客户有三种沟通方式，电话、邮件和IM工具，其中电话是最及时有效的沟通方式，IM次之，邮件最次。所以当我们有机会去选择或者提出建议的时候，尽量按照电话>IM>邮件的方式去选择，电话里讲10分钟的内容有时候邮件需要来来往往好多次。
    
2. 每一次和客户沟通之前我们一定要想好这次沟通的目的是什么，我们需要澄清什么问题，客户可能会有哪几种答案，面对不同的答案我们会有哪些新的问题或者设想，提前多想想，尽量全面，每一次沟通都能解决更多的问题。
    
3. 邮件和IM的沟通方式都是有记录的☺，不要急着点发送按钮，写完之后自己读一遍，看看有没有什么问题，包括英文语法，单词拼写，大小写，表述方式是否合理有礼貌，内容表述是否清晰等等。
    
4. 与客户沟通的时候，一旦有机会就可以想办法从客户那里尽可能多的了解项目的整体情况以及客户下一步的想法，这样可以让我们更加从容的去面对接下来的工作。
    

几 个项目做下来，我深切感受到，在盛安德，软件工程师绝对不只是一个接受需求然后编码的coder，更是一个需要参与设计开发的engineer。需要更积 极主动的去思考项目的方方面面，从总体到细节，从大模块到单一功能；积极主动的与客户保持沟通，去了解客户的想法、思路，并且把自己的想法传达给客户，把 整个项目都当成是自己的事情来做。长此以往，我们自然就会赢得客户的信任，从而引领项目走向最终的成功。