经历了一年的折腾，一直跟随的项目终于走到了尾声，尽管最后的结局是向好的，但我依然将其划归为失败！心中的苦楚虽然在时间这个最具魔力的工具下渐渐平复，但是写下这个题目依然是鼓起十足的勇气。
前提
其他类型的项目不好说，我这里只说说软件定制的项目。
1.客户，客户
现实世界很难将过错推给客户，毕竟客户是上帝吧。但是经过这次，真心觉得如何利用好客户是项目成败的关键。
为毛这么讲？
第一，需求
举例来说，我们这次项目本来大家是摩拳擦掌，跃跃欲试，在时间紧任务重的情况下，希望把事情做到可以做到的最好！客户给的需求说明，非常详尽，A4双面打印纸，打出来有两个大拇指的厚度。但是非常不幸的是：
全文字！全文字！全文字！唯一的图表是各种逻辑图！
真的！真的！真的！我没有读完（当然程序员未必真的要读完客户需求，因为还有顾问呢啊，但是，但是。。。程序员看consultant的分析就等于吃了人家嚼过的馍，已经少了一层意思）
第二，抽象和具象
接下来，坏结果水到渠成，为啥？
客户的需求是抽象的，而非具象的。需求只体现在了功能上面，而不是具体的画面。
客户第一次见到成品的时候，非常不满意，为何？因为我们所呈现的东西不是他们脑子里想像的哈姆雷特！我们呢觉得就是按照他们的意思编的，他们认为他们的需求被扭曲了。。。当然，这里是否有语言的问题，也不好说。也就是说当客户的母语不是文档中的语言，不可否认，某种程度上出现歧义是非常有可能的。
另外，为什么文艺作品搬上荧屏，不管演员如何努力，总会有人跳出来说演的不好，不是心中的（或者说是小说中的）XXX？但是现实中的客户不满意就是大事儿了，不是斗斗嘴皮子的闲聊天儿
但是无论怎么样，客户是衣食父母，咋办？
具象化对客户需求的理解
画图或者模型是目前我看到的唯一解决办法，同时这也是我们梳理思绪和逻辑的过程。另一方面，在客户需求中很难表现的是他们现实的工作环境以及流程（这部分有所表现，但是还不充分）。这样就容易造成程序员按照自己的开发习惯做出来的东西，客户觉得并不方便他们的使用！
第三，测试
千万别和我说，客户不是测试中的一部分，恰恰相反，客户应该包括在测试中，而且不是最终测试中。客户的测试需要从第一个试运行版本开始，这样客户的意见可以及时加入到下一部分的修改中。避免成品后再改动，因为这样容易造成对代码的毁灭性打击，或者说是对花了心血的程序员朋友们的自信心造成重大打击！把客户嵌入在测试+反馈中也是现下流行的敏捷开发中所提倡的。
未完待续
