2B项目需求分析总结.docx

2B项目需求分析总结 PAGE 1 2B项目需求分析总结 本从将从需求分析内容、需求分析过程2个方面来分享2B项目的需求分析相关内容。一、需求分析的内容需求分析基本包括以下几个关键词：调研（获取）、分析、整理（编写）、管理，当然了这4个关键词肯定和需求有关的，比如调研是指需求调研。另外，根据不同公司岗位工作的安排，可能有的需求分析岗还有软件产品设计等相关性工作，但不在本篇文章讨论范围内。调研（获取）：和客户直接或间接沟通，对客户方的业务需求做深入了解。分析：该过程中发生在调研过程中调研后，对需求的收集不仅仅是“获取”，更重要的是通过分析去挖掘需求。整理：是对所有需求进行梳理，归类及详细描述，便于其他人能通过你的整理产出物快速准确了解需求。管理：需求是动态的，需求变更是做项目性需求的常态，要学会适应。对于处于变化中的需求要学会需求管理。了解了需求分析的内容，可以试着思考需求分析的目的是什么？答案一般包含于以下几方面：搜需求、挖需求、纠需求、砍需求等，个人认为需求分析要用一个词来归纳的话，那就是价值最大化：让软件或产品能够为客户提供最大价值。可能有人不太赞成我说的这句话，由于做项目会考虑到各方利益。但不管怎样，应该保持这样的初心。二、需求分析过程下面将围绕需求分析的内容对需求分析过程进行阐述。2.1 调研调研的方法有很多种，比如访谈法、会议法、体验法、观察法等，但具体到某个项目就各有千秋了。访谈法和会议法是比较常用的方法，毕竟比较直接有效。在调研过程中，有以下注意事项和大家分享：（1）找对人做项目性需求时，一般都有专门的业务对接人或者叫关键用户。做需求调研时，一定要让关键用户在场参与。既然客户方指定某个人为对接人，肯定有是原因的。说明他是能够代表客户方利益，并且对客户方的需求也是有独到见解的。其他参与人的想法或思路，我们不是完全否定，而是要条条记录、层层分析，最后要和关键用户讨论是否要纳入建设范围。现实中有一些比较缺乏经验的小伙伴在做需求分析时，可能太为客户着想，觉得应该接受客户方所有人的需求。结果把自己折腾得求生不能求死不得，更可怕的是关键用户不认可这些需求，一切都凉凉了。（2）多沟通、多确认平常大家可能有这样类似的经历，说话的人觉得自己说的很清楚了，听者也觉得自己明白说话者的意思了，其实双方还是没理解到一块。比如一句话客户说“我们部门工作内容有点多，平常很忙”，客户可能的意思是说他们部门是公司的关键核心部门，而听者可能理解为需要给他们部门减减压。现实中可能还有些业务专家可能觉得自己在同行业很久了，用户说的他都懂。在和客户沟通时，侃侃而谈，有点“喧宾夺主”的赶脚，这是很危险的。同样的一个问题，在不同客户那可能诉求是不一样的，所以要有耐心，让客户多说话，不要盲目自信。关于需求确认，个人觉得比较有效的方式是把你理解的意思重复一遍讲给客户听；或者把你理解的意思用具体的业务场景描述出来，比如把你和客户都当成实际需求中的用户，然后把需求描述一遍，让客户确认是否理解正确。在调研时，不要一直局限于项目范围，因为这样会限制你的思路，也不能全面的去了解客户需求。所以可以暂时不考虑项目的范围，让客户尽情地表达他们的想法，把需求甄别放在下一步。2.2 分析与挖掘需求分析不是简单的需求搬运工，而是要处理正确的需求。更准确的说，客户或用户提出的一般都不是需求，而是问题。他们希望我们需要对问题进行提炼，转化为软件需求（解决方案），然后转交给开发人员。从问题到解决方案就是一个思路、分析的过程。比如客户提出“我们所有的工作都要用软件管理起来”一句话，这是一个10星级的很抽象的问题，作为需求分析人员需求对问题做深入的了解并转化，才能成为软件需求。另外，有时候客户的想法也是脑门一拍的事儿，所以我们要通过分析去识别出错误的需求或伪需求，这里不再举例，回头有机会会补上。需求分析的过程也是把控范围的一个过程，比如本次是给客户做一个OA管理系统，客户突然提到说他们的办公用品台账管理太乱了，这个问题很明显就不属于OA的建设范围。技术是一步一步发展的，客户提出的所有需求并不是技术上都能实现，所有不能实现的需求也要靠分析去识别出来。以上是对需求分析的概述（转化需求、甄别伪需求、控制需求等）。需求收集、分析是本能，能够引导客户，挖掘需求才是高手。满足用户提出来的需求不是目的，建立客户在行业领域的标准化管理体系才是目的。这也就决定了用户提出的需求不一定都要实现，没有提出的需求也不一定不实现。让用户提需求只是实现这个目标的手段之一。2.3 需求管理之文档管理从一开始的初步调研到最后的上线，需求管理是贯穿整个需求分析的过程中的。日常对需求的管理，对文档的依赖性还是