有没有人用和会不会有人用?

人类需要的是光明,可是爱迪生却给了我们灯炮! 你是否真正了解产品需求?

  1. 深刻理解业务

  2. 充分和用户沟通

  3. 具备深厚的技术背景和严谨的思维

一、让客户畅所欲言,罗列出所有的需求

二、透过现象分析潜在的需求

三、利用自然的语言描述项目模型

四、利用示意图和图表将用户的需求表现出来

五、什么人要看需求分析报告?

六、建立需求变更日志,制作新版本的需求分析报告。

七、本阶段重点工作角色

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

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

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

评论

您还没有登陆,登陆后可以发表评论哦!点击登陆