一、有效沟通

对于沟通，这个我们再也熟悉不过的词眼，也许你会认为很简单，不就是与客户打交道嘛，只要英语好，描述清楚问题，与客户保持良好和密切的沟通，每天发好Daily Report，每天Skype/MSN保持畅通，要是口语好，那立马高大上，各种膜拜与羡慕，但岂不知这一切都是沟通的最基本的先决条件，具备这些条件并不意味着我们就能很好沟通和有效沟通。

1. 尽力表述清楚问题，把握重点




2. 集中一个任务或问题
   在A任务没有讨论完之前，不要急于下一个任务




3. 分条描述
   写一大段各种逻辑相互缠绕的描述，结果客户只回了一句：I don’t understand. 不如有条絮的分段阐述问题，按逻辑顺序列出1), 2), 3)来，用简练且明确的词汇表达清楚每一段问题，所有串联起来不就是一个完整的逻辑，且这样更有条理性




4. 图片，链接外加关键字
   有些问题很难用语言去阐述，那就附带图片或链接的方式去说明




5. 举例/画图/截图
   以最直观的图表形式，配带解释性说明，图文并茂，即便是英语不好，从图表中也能分析出一二




6. 提出自己可行的解决方案
   在和客户沟通之前，要先理出来自己的一套思路，把自己的理解告诉客户，让客户帮你纠正，即便这个思路还不是很正确，且不可盲目无头绪的去问。 如果是比较确定的任务，客户拿不定主意，至少应该提出自己的可行方案去建议客户




7. 永远不要问客户How to do?

二、梳理任务

事有轻重缓急，开发也不例外，不论是大任务还是小任务，其实我们都能把它拆分成不同优先级和不同阶段的小任务，把需要做的所有点梳理成一个任务结构：

1. 任务优先级一目了然




2. 条理性清晰




3. 不易遗漏




4. 团队进度很容易掌控，也容易评估时间，客户也容易掌握项目的进展情况

对于一个大任务来说，这样的任务计划就显得至关重要，好记性还不如一个烂笔头，如果这个任务的周期很长，谁也难保证我们不会遗漏。我们完全可以借助一个工具，协助我们去管理任务列表，对于大中型团队性质的项目，我们可以使用TP之类非常专业的项目软件管理任务；对于中小型1-2人的项目，Trello是完全可以胜任的，我们在之前的项目中与客户大量使用这个协同软件，效果甚是明显。

三、周密的时间与计划安排，拒绝拖延症

四、注重细节，充分测试

项目不同，有的项目客户要求写Test Case，有的则并没有，当然Test Case并不是万能的，这就要求我们在提交之前做到充分的测试。
大家稍加留意就不难发现，有的程序员写的程序很少出错，客户满意率极高；但有的却频频出错，被客户打回来的几率很高，从而客户的满意度在直线下降。当我们去Review这些代码的时候，也许解决问题的思路真的是很不错的思路，但往往就差在最后两个关键环节——细节与测试。变量未声明，数据未做过滤，大篇幅的COPY代码，接口紊乱，浏览器不兼容，写完代码不测试，或者只测一次等等，然而，当我们再去多问一句：你到底测试过来？听到的永远都是很斩钉截铁的回答：“……我当然测过了……怎么可能有BUG呢……”
一个完整的任务，如何去定义，可能每个人都会说出自己一套规则来，举个很简单的例子：
比如一个INPUT框，用户希望输入的是一个1-9的自然数，而我们在开发过程中往往会想当然的认为这个框就应该输入自然数，因为我们对需求很清楚，也在测试中想当然习惯性输入自然数，结果是测试都统统过了。
但提交之后，在客户输入0，-1，1.5，10，9.5后，大家想象会是什么样的表情？
如果一个任务代码写完，只能说是完成了80%，没有细节只能算是60%，没有充分测试也仅仅只是个半成品而已。一个这样的看似完成且很高效的任务，到头来我们甚至得花双倍的时间去FIX。

1. 团队内部相互Review，指正不规范的代码




2. 有把握的小任务至少测试3-5次，大任务几十，甚至上千次测试




3. 预想各种可能出现的问题，用各种可能出现的模拟数据排查测试




4. Partner之间交叉测试，自己发现不了问题别人可以发现




5. 任何一次改动，都要考虑到当前接口改变是否会影响到其它功能，并且每个涉及到的功能都应测试




6. 任何一次UI的变化，都应在每个浏览器上进行测试它的兼容性




7. 站在非开发者的角度去试用功能




8. 谨慎且按时交付

 五、从客户身上学习我们所欠缺的

做国内项目，大多面对的是终端客户，大多数对技术也不甚了解，但对于我们ODC模式的国外项目，我觉得这是我这几年感触最多的一方面。 有的客户懂技术，而且技术素养也很高，这其实对于我们程序员来说是一个绝佳的学习机会，从他们身上我们了解到国外目前流行且常用的领先技术，或者是一种先进的开发里面，一个完整的软件开发体系，除了我们每天自己不断的学习，从客户身上我们也能了解和提升自己的眼界。
比如说：2011年底我们接手挪威客户的ODC，项目负责人本身懂技术，只要是他看到的好的技术就会推荐给我们，比如说Git、Twiiter Bootstrap，Backbone.js、Angular.js、SendGrid、Laravel、Slim等等，而现在这些都成为了我们团队主流的开发技术体系的一部分。 还比如2012年的某国外项目，客户期望一个严格且完整的开发体系，开发，测试，代码规范，代码冗余检测等等，我们从中发现了我们很多的不足，在此之后我们针对这个项目进行过很多次的反思，调整，专项培训，那里不行就专补那里，直到那些劣势被我们转化成优势。
客户高要求，不仅会让我们找出自己的不足，更有利于我们凝聚一个严谨，高质量高效率的团队，从另一方面说，其实也在侧面成就着团队的成长。

六、总结项目、分享心得

一个项目结束，但对于团队或者个人来说，还有一个重要的事情需要我们去做，那就是总结。
那些方面我们做的好，那些方面我们又做的不好？
客户最满意我们什么，又最不满意我们什么？
我们的代码质量是否有长足提高，我们的效率是否高效？
我们的团队或者个人进步有多少？
我们是否竭尽全力，需要改进那方面？
……
我觉得这些都是我们在项目结束之余应该思考的问题，如果一个项目做完，没有留下些什么值得我们改进或者骄傲的东西，那将是多么可悲的事情。当然这有些言重了，重点在于我们在总结中，找出每一个我们做的不到位的地方，扬长补短，在接下来的项目中，让自己做的更好；找出做的好的地方，分享给其他团队，或者让后来人借鉴。