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

　　以下和大家分享一下，我在确定需求的过程中的几点建议：
　　大体的流程是这种：
　　1.先和客户沟通想要实现什么功能？
　　2.整理一份粗粒度的需求文档，并设计原型。
　　3.找客户确认原型，并在需求文档上签字画押。
　　4.循环上述步骤

　　该怎样和客户进行交流？
　　1.用户须要什么功能？用户提供了哪些数据？这些数据是否可以实现用户所须要的功能？
　　2.注意聆听客户的要求。并用自己的语言反复给客户听。
　　建议：录音保存后整理。
　　3.软件的使用频率、使用周期、数据量是多少（比方：每月最多上传多少条记录），以便于后期优化。
　　以及谁使用本系统？涉及到权限的管理。
　　4.专业领域的术语一定要明白。类型、是否唯一。如："代码证号"=="组织机构代码证号"
　　怎样写文档？全部人都能看懂。并正确理解就是好文档。
　　1.最主要的要求是：文档的格式、字体、分级、缩进、字体大小……。
　　须要的基本功：批注、修订。
　　最最重要的是：不要有错别字！
　　2.用通俗的语言来描写叙述、逻辑要清晰、简明扼要、不要有歧义。尽量用图片/原型+文字描写叙述的形式向客户展现。
　　3.重要的是：突出重点。如：是否保存历史数据？一定要找客户确认。否则就会遇到这样的情况：客户要求扩展功能。可是原始数据都不存在了。
　　1)另。“已上传”未“确认”的文件。“删除”后可又一次上传。经过“确认”的文件，不可删除，请确保操作无误后。进行上传。
　　2)另：系统中以每月上传的最新文件为准，均不保留历史文件。
　　4.对照清晰。
　　描写叙述一种现象有非常多种情况。能够?用提取公共部分，对照差异部分的方式来比?。
　　1)每月上传两次四险文件（第一次为欠费文件，第二次为已缴费文件）
　　2)每月上传两次医保文件（第一次为欠费文件，第二次为仍欠费文件）。
　　5.举例说明：假设非常难描写叙述业务。不防通过举例的方式来解释清楚。
　　6.提示信息模板：有必要的话?用。提示信息由客户给定模板，或者由客户手动输入。
　　如：设置欠费提示信息模板、不欠费提示信息模板。
　　7.上传文件：假设是上传Excel之类的，上传前要注意版本号兼容问题、有哪些字段、数据的格式有哪些要求。上传错误的分类情况须要一一列举，并和客户确定
　　8.容错处理。
　　系统中的全部东西都是能够手动改动的，不要写死了。
　　9.流程图一定要保持思维逻辑严谨。
　　先有图，后有说明。
　　怎样画原型？这里使用的是AxtureRP
　　1.风格要统一：
　　假设是子系统（小的模块），一定要仿照基础系统的风格来处理。
　　本系统内部样式、色调也要统一，这些都是最主要的。
　　假设是一个独立的系统。还须要了解客户平时经常使用什么办公软件。操作风格、布局之类的。最好要符合用户的使用习惯。
　　2.页面之间的交互：
　　不只要显示静态的页面，更要注重界面之间的交互。
　　使用假数据模拟真实场景。尽管。仅仅是一个原型，可是一定要让客户感觉是在真实操作系统一样。
　　3.友情提示不可少：
　　此处能够标注本界面用来干嘛的？怎样操作？有什么须要强调的地方？
　　工作中的一些经验拿出来，整理了一下。希望可以帮助您高效的工作。做好需求调研是战略上的决策，其重要性就不言而喻。