需求分析师-一个门槛不低的职位

一、深刻理解业务

二、充分和用户沟通

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

一看上面这个三点，就觉得门槛不低了，何况要全面，更怕业务涉及一大堆方向。。。  技术覆盖最古老的pasca，到Go，API设计到sdk 到微信，这倒是怎么了得

小结一下我的想法：在项目中，用户的字典里是单证、收入、报表、审核等，而开发人员的字典里则是键值、索引、按钮、事件这些，而需求分析就像是一位翻译，把用户的语言和开发人员的语言融合到一起，让双方准确理解对方的意思，从而在开始开发工作之前让双方都真正明白对方的思路。

对于需求分析中关键的因素，我自己的体会主要有如下三点：

一、深刻理解业务

需求分析人员需要对用户的业务有非常深刻的理解。所谓非常深刻的理解，就是说你能和用户的管理层就他们的业务问题谈笑风生。如果做金融产品不懂风险管控，做论坛不懂SEO，做人事系统不懂组织行为，如何能对业务有深刻的理解呢？

有人看到这里要说了，用户给我讲明白需要做什么功能就行了，我对他的行业了解那么深有什么必要呢？我想说的是，做需求分析也是分很多层次的，层次越高，需要对业务的理解越深。

我再举一个例子吧。某个项目要开发一套企业管理系统，客户是一个企业集团，下属很多分公司，都在做多条产品线业务，集团对分公司的业务管理一盘散沙的问题很头疼。之前的做法是每个分公司每个月底将每条产品线的业务报表传真到集团，然后集团进行业务统计。现在客户提出的需求是，在每个分公司都部署一套和集团一样的业务管理系统，并在集团的平台中做一个数据上报模块，让各个分公司都可以从自己系统中导出电子版数据并上传给集团，从而提高接收和统计的效率。

“还可以”的需求分析能够把这个需求准确描述，严谨定义，让开发人员开发出用户满意的功能。“比较好”的需求分析则可以更进一步，和用户探讨是否可以做成一套大集中的系统，分公司无须上报就可以让集团随时看到各个分公司的业务状况，从而杜绝虚报瞒报数据的问题。“更好的”需求分析也许可以和用户探讨通过信息系统的支持实现矩阵化的业务管理，在不改变组织结构（因为组织结构问题已经超出需求分析的范畴，甚至超过了项目范围了）的情况下，提高集团对各条业务线的宏观管理能力，从而更好地落实集团对于各条产品线的战略。

也许有人还有“更更好的”业务分析，但你可以看到，越深入业务的分析结果对于用户的价值越大，用户对整个开发团队的认可程度也会更高。这对于项目的成功是非常重要的。如果客户很感谢你提出了让他能加强业务管控能力的方案，他还会和你纠缠菜单的颜色够不够好看么？

二、充分和用户沟通

首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定；负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。有些业务部门不希望自己的业务数据被太多人知道，有些项目甚至会让一些部门失去权力，一些领导丢掉职位。所以在一个项目里，需求讨论会上往往会有各种各样的声音。声音后面是立场，立场后面是利益。缺乏经验的需求分析人员很容易迷失在这些声音里，最后做出来的需求成了四不像，而这正是某些用户希望看到的结果。

这时候怎么办呢？老码农俺有一个祖传秘方：找用户最大的领导讨论项目的整体思路，然后按大领导的意见把用户需求筛选一遍，凡是和大领导思路明显冲突的一律扔到一边，把符合大领导思路的那些需求充分细化。啥叫大领导？不是什么IT部经理、信息处处长、客户项目经理之类的，而是能拍板决定和这个项目相关的业务问题的人，比如做人事系统，大领导至少是人力总监，做财务系统至少是财务总监，当然能再往上让一把手积极参与进来就更好了。和大领导讨论的过程，既是了解大领导思路的过程，也是筛选需求的过程，更重要的是，获取大领导支持的过程。有了大领导的支持，再开会的时候，底下吵吵嚷嚷，你也能气定神闲，胸有成竹。

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

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

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

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

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

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

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

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