二、充分和用户沟通 互联网的一些事
首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定;负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。有些业务部门不希望自己的业务数据被太多人知道，有些项目甚至会让一些部门失去权力，一些领导丢掉职位。所以在一个项目里，需求讨论会上往往会有各种各样的声音。声音后面是立场，立场后面是利益。缺乏经验的需求分析人员很容易迷失在这些声音里，最后做出来的需求成了四不像，而这正是某些用户希望看到的结果。
这时候怎么办呢?老码农俺有一个祖传秘方：找用户最大的领导讨论项目的整体思路，然后按大领导的意见把用户需求筛选一遍，凡是和大领导思路明显冲突的一律扔到一边，把符合大领导思路的那些需求充分细化。啥叫大领导?不是什么IT部经理、信息处处长、客户项目经理之类的，而是能拍板决定和这个项目相关的业务问题的人，比如做人事系统，大领导至少是人力总监，做财务系统至少是财务总监，当然能再往上让一把手积极参与进来就更好了。和大领导讨论的过程，既是了解大领导思路的过程，也是筛选需求的过程，更重要的是，获取大领导支持的过程。有了大领导的支持，再开会的时候，底下吵吵嚷嚷，你也能气定神闲，胸有成竹。
有人可能又要嘀咕了：大领导你想见就见，你以为自己是谁啊?这就又联系到我刚才谈的第一个问题，对业务理解的深度。项目启动的时候，大领导一般例行是要接见一下项目组的，你也会给大领导留下一个印象。如果你张口闭口就是数据库、表单、Java框架什么的，大领导和你没有交集，自然懒得见你，要是你能聊到们最大的竞争对手在这个项目相关的业务领域有哪些优势劣势，国外的业务管控经验等等，你也许能经常成为大领导的座上宾。所以说，对业务理解的深度是项目成功非常关键的。 互联网的一些事
和用户的沟通有多种形式，比如需求讨论会、高层访谈、用户讨论什么的。我觉得应该先做很多的一线用户讨论，问很多问题，把所有的业务环节都彻底摸清，顺便收集一些表单和数据作为需求分析的依据。然后再去做高层访谈，了解整体思路、战略、目标一类的宏观问题。需求讨论会一般在后期开，主要是针对某些争议比较大或者定义不清晰的问题，集思广益，实际上就是一种头脑风暴方法。在这些讨论中，需求分析人员都不应该只是做一个记录者，而应该多提问题和建议，用自己的思路去启发用户，大胆设想小心求证。但也要注意尊重用户的意见，不能觉得用户不懂技术所以我随便听听就行了，怎么实现是技术的事情，和用户没多少关系，这样往往在后期会出问题。 yixieshi.com
三、具备深厚的技术背景和严谨的思维
需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，就需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。当然，这是建立在前面与用户(包括技术人员)充分沟通的基础之上的。 互联网的一些事
有的需求分析人员技术背景不是很强，是不是就做不好需求分析了呢?我觉得倒也未必，这时候就需要团队的力量了。如果有一个技术很强的开发人员作为后盾，能够和你搭档一起去讨论需求，并为你提供技术方面的意见，让你能充分发挥自己对业务的理解和沟通的能力，也会是不错的组合。 互联网的一些事
写文档就考验需求人员的文字功底了，有时候一句话、一个字都需要反复推敲，一不小心就有可能给自己挖坑，有点做律师的感觉是不是?要让业务和技术都看明白的确不容易，这里俺建议多画图，一张图有时候能抵几千字。什么流程图啊、数据流图啊、组织结构图啊、用户界面示意图啊什么的，能画图的地方就多画图，图加上文字，读者的理解就不容易跑偏。
最后，需求文档写完了，记得打印出来，核心用户一人给一本，告知几天内可以提出一次修改意见，只修改一次就会形成初始需求的定稿，以后再改要走变更控制流程。再印几本存档的，最后多一页签字确认页，让所有收到需求文档的用户最后都要签字确认，最后再给用户方的项目经理签字。有签字确认的存档就可以作为将来需求变更的依据了。
有人说，对方项目经理签字不就行了，为啥非要所有核心用户签字呢?因为领导们签字都是很慎重的。如果不需要签字，他拿着需求随便翻两下往抽屉里一扔，压根不会仔细看。但是如果三天后需要他一次性提出修改意见，没有修改意见就签字认可，这就不一样了。他就会仔细看，认真提出意见，因为很少有人会在自己没仔细看过的东西上签字的，对不?这样也是提前帮你检查了定义不够严谨、将来有可能产生争议的内容。所以通过这个过程，可以让核心用户对需求的理解和开发团队进行一次同步，真正形成需求的一个基准。
关于需求分析的体会，俺就说这么多吧。自己水平有限，唠叨了这么半天，也不知道有多少有用的东西，还请读者多多指正。最后其实俺还有一个想法，需求分析是项目经理义不容辞的工作，如果需求很复杂需要一个团队，项目经理也必须是这个团队的核心人员。关于项目管理俺也有一些体会，有时间再写一点东西，博读者一笑而已。各位看官，预知后事如何，且听下回分解。
