9月2日的下午接到通知去JCZB上班。目标是使用SSH框架实现一个全新的系统。由于SSH刚学完，有没有做过项目，所以心里比較发慌。可是，毕竟对于自己而言是一次非常难得的机会，所以就欣然接受了。
9月3日是正式上班的第一天。下午经理安排每人做一个小项目。
我拿到的是“企业社保欠费查询系统”，领到手的需求文档。仅仅有一页纸。另一份相应的原型。于是，我開始充分发挥自己的想象力，来理解客户的需求。并在原有的基础之上进行扩充。
曾经做项目都是需求已经确定好了，仅仅要照着做就能够了。
这次可不一样，需求也是须要和客户来确定的。
交流方面也是一大挑战！
就像是曾经常常听说的：客户仅仅懂得业务，不懂得怎么来实现。
而作为程序猿的我们，仅仅懂得用代码来实现功能，不一定了解客户真正想要的是什么。事实上，客户也不知道自己想要什么，所以在和客户沟通过主要业务以后，仅仅需画原型并确定需求文档，找客户确定就能够了。尽管。说起来非常easy，可是真正实现的时候并没有想象中那么简单。
9月11日，带着自己设计的原型和需求文档，随同经理来和客户确定需求。在沟通的过程中，越来越发现自己太想当然了。
仅仅顾得依照自己的思维方式去想问题，并没有站在客户的角度来理解业务。
反而是客户在诉说业务的过程中，帮我梳理了需求。
这也充分说明：一纸文档害死人呀！仅仅有静态的文档和原型。easy让人产生歧义。当然不如当面和客户交流，更能直观清晰的明白需求。
可是。由于各种原因导致交流不便。
由于文档，也成了客户和我们之间交流的一种方式。这也更加说明写文档的重要性！文档一定要丰富。用户须要什么功能？先后运行顺序？每一步有什么限制？一定要屡清晰思路。
经理这时也意识到，先前仅仅顾得忙工作，没有把和客户之间的交流跟我们交代下去。
本来以为非常easy的业务，结果被我们理解的有偏差。
导致此行无果。最不愿让经理看到的是：我本着学习的心态来做项目。把功能扩展了。而对于经理而言，价钱已经谈好了。功能上仅仅要简单实现就能够了。立场不同，所以……
还真是惊喜不断呀！
本来应该是由PM确定需求后，我们仅仅负责开发的。
结果，PM却说这个项目由我和客户直接沟通。沟通后的结果须要整理成需求文档反馈给PM。
恰好锻炼一下和客户的沟通能力，这倒是挺好的。
接下来的一个星期，就是依照客户的要求进行设计原型界面，同一时候依照PM给定的模板编写需求说明书。然后反馈给PM，PM修订文档后，通过文字+电话+视频指导的方式，和我进行交流。并指出一些须要和客户确定的问题交给我来做。再加上经理的初步验收和指导，这三人和我的耦合度实在是太紧密了，终于导致了需求文档和原型界面修订了十五多个版本号。这叫一个纠结了。
怪不得设计模式总是说：解耦合、解耦合。这样的高耦合性，恐怕仅仅有身在当中的人才深有体会吧！
以下和大家分享一下，我在确定需求的过程中的几点建议：
大体的流程是这种：
1.先和客户沟通想要实现什么功能？
2.整理一份粗粒度的需求文档，并设计原型。
3.找客户确认原型，并在需求文档上签字画押。
4.循环上述步骤
