关于需求分析的几点体会

　　有人可能又要嘀咕了：大领导你想见见，你以为自己是谁啊?这又联系到我刚才谈的第一个问题，对业务理解的深度。项目启动的时候，大领导一般例行是要接见一下项目组的，你也会给大领导留下一个印象。如果你张口闭口是数据库、表单、Java框架什么的，大领导和你没有交集，自然懒得见你，要是你能聊到们大的竞争对手在这个项目相关的业务领域有哪些优势劣势，国外的业务管控经验等等，你也许能经常成为大领导的座上宾。所以说，对业务理解的深度是项目成功非常关键的。 互联网的一些事

　　和用户的沟通有多种形式，比如需求讨论会、高层访谈、用户讨论什么的。我觉得应该先做很多的一线用户讨论，问很多问题，把所有的业务环节都彻底摸清，顺便收集一些表单和数据作为需求分析的依据。然后再去做高层访谈，了解整体思路、战略、目标一类的宏观问题。需求讨论会一般在后期开，主要是针对某些争议比较大或者定义不清晰的问题，集思广益，实际上是一种头脑风暴方法。在这些讨论中，需求分析人员都不应该只是做一个记录者，而应该多提问题和建议，用自己的思路去启发用户，大胆设想小心求证。但也要注意尊重用户的意见，不能觉得用户不懂技术所以我随便听听行了，怎么实现是技术的事情，和用户没多少关系，这样往往在后期会出问题。 yixieshi.com

　　三、具备深厚的技术背景和严谨的思维

　　需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。当然，这是建立在前面与用户(包括技术人员)充分沟通的基础之上的。 互联网的一些事

　　有的需求分析人员技术背景不是很强，是不是做不好需求分析了呢?我觉得倒也未必，这时候需要团队的力量了。如果有一个技术很强的开发人员作为后盾，能够和你搭档一起去讨论需求，并为你提供技术方面的意见，让你能充分发挥自己对业务的理解和沟通的能力，也会是不错的组合。 互联网的一些事

　　写文档考验需求人员的文字功底了，有时候一句话、一个字都需要反复推敲，一不小心有可能给自己挖坑，有点做律师的感觉是不是?要让业务和技术都看明白的确不容易，这里俺建议多画图，一张图有时候能抵几千字。什么流程图啊、数据流图啊、组织结构图啊、用户界面示意图啊什么的，能画图的地方多画图，图加上文字，读者的理解不容易跑偏。

　　后，需求文档写完了，记得打印出来，核心用户一人给一本，告知几天内可以提出一次修改意见，只修改一次会形成初始需求的定稿，以后再改要走变更控制流程。再印几本存档的，后多一页签字确认页，让所有收到需求文档的用户后都要签字确认，后再给用户方的项目经理签字。有签字确认的存档可以作为将来需求变更的依据了。

　　有人说，对方项目经理签字不行了，为啥非要所有核心用户签字呢?因为领导们签字都是很慎重的。如果不需要签字，他拿着需求随便翻两下往抽屉里一扔，压根不会仔细看。但是如果三天后需要他一次性提出修改意见，没有修改意见签字认可，这不一样了。他会仔细看，认真提出意见，因为很少有人会在自己没仔细看过的东西上签字的，对不?这样也是提前帮你检查了定义不够严谨、将来有可能产生争议的内容。所以通过这个过程，可以让核心用户对需求的理解和开发团队进行一次同步，真正形成需求的一个基准。

　　关于需求分析的体会，俺说这么多吧。自己水平有限，唠叨了这么半天，也不知道有多少有用的东西，还请读者多多指正。后其实俺还有一个想法，需求分析是项目经理义不容辞的工作，如果需求很复杂需要一个团队，项目经理也必须是这个团队的核心人员。关于项目管理俺也有一些体会，有时间再写一点东西，博读者一笑而已。各位看官，预知后事如何，且听下回分解。