如何做需求分析.pdfVIP

如何做需求分析 这段时间我做了两个大项目，其中一个项目算是商业模式上和使用规范上的调整，另一个项目是之 前功能的重做，为什么重做我下面会说到。关于需求分析，我认为把需求抽象成产品功能花费的时 间占到了软件开发周期的 40% ，产品设计到评审完的时间大概是 20% ，也就是说实际开发之前产品 团队介入的工作占据项目的 60% ，在需求分析阶段我有一些个人观点。 1: 抓核心点，不是所有用户诉求都是需求 我们每做一个项目迭代或者新项目一定有目的，而需求分析阶段，需求采集渠道中的需求往往是零 散的、无重点的、逻辑性不强的，所以我们需要从这些离散的需求点中要抓住核心，梳理实际使用 场景去分析问题，所有的核心点一定是以最终目的为导向的，不是所有用户诉求都是需求。 以我的项目为例，由于历史原因，自配送人员关系没有进入 OA 系统，所以配送员工资结算数据只 能做进配送系统，相当于是一个简单考勤记录，其实最早之前系统是有这个功能的，但是由于之前 没有仔细整理需求，导致这个功能白做了，所以这次我接手几乎从做，我以为这个事情比较简单就 让一个产品助理先去整理需求，当把原型图出出来时发现并不能解决结算工资的功能，只是一个简 单的排班。 所以，当时我就跟那小兄弟说，你这东西只是完成了排班，然而排班的目的为了结算工资这还不能 满足需求。所以我跟他强调，我们做这个需求的目的是为了考勤，诸如请假、值班、加班工时、轮 休日加班等数据要能提供出来，他的第一版原型其实没有充分了解到我们为什么要做这个排班功能 ，所以在了解需求过程中没有抓住核心点，导致需求不明确。 2: 制定规则、改善复杂流程 我的上一家企业做的是互联网电商，其实在我看来电商和 O2O 有很大的区别点就是电商在当下盛行 的情况下已经变的很有规则了，首页、产品列表页、详情页、下单页等等，每个页面展示的信息也 大相径庭，而 O2O 不一样，一方面是 O2O 差不多 13年才兴起，到目前为止（ 15年）还没有一个标 杆行业，另一方面是 O2O 与日常生活联系的太紧密，落地下来就是很复杂的业务流，这些是 to C 产 品的规则化和流程化，而流程化的东西在 to B 产品上体现的尤为明显， to B 产品最经典的例子就是 公司后台系统。 不论是一个 to C 的产品还是 to B 的产品，我们都要考虑到用户使用场景， PM 需要把自己当作用户， 充分考虑各种情况下的用户思维才能设计一个满足用户需求的产品，这里并不是一味的去迎合用户 ，做互联网的都知道当一个业务不是规则化时很难用产品去满足用户，所以我们有必要制定规则， 或者优化不完善、流程复杂的 规则。 下面说说制定规则，其实统一规则有利有弊，举个例子，滴滴打车的订单是抢的， uber 打车的订单 是系统自动分配的，滴滴那种做法能提高司机积极性、自主性，司机可以选择高金额的订单，但是 这种做法也会影响用户体验，比如说万一以后不补贴了，我只是一个起步价，有些司机就不愿意 接单，要等待很久；而 uber 打车制定了自动分配的规则，先分配目前离乘客最近的空闲司机，如果 他不接再分配给下一个，这种做法能不能满足用户我不说，我只说这种规则简化了下单流程，司机 和乘客只有两个选项，接还是不接，坐还是不坐，司机如果不接，但他并不知道下一单能等到什么 时候，订单金额有多大？虽然司机间的积极性和自主性减少，但是对用户来说体验很好。 说完了制定规则，再说一下改善流程，我上面说了这种流程化精简在 to B 产品上尤为明显，很多人 有个看法就是后台系统反正是自己人或者其他企业人员用的，完成功能就行，没必要做的这么便捷 和细致，其实不然，优秀的 PM 在这方面总能善始善终，因为在他们眼里一点点的产品优化或者流 程优化能为企业带来很多的效益，这个我有切身的体会。 之前做的多个项目，其中有两个就是我在做需求的时候发现业务部门在实际运营中思维定势或者每 日重复做属于他的工作，但是他们并没有发现这样做其实效率很低，在没人观察流程有问题的时候 ，业务部门已经形成规范，但是这种规范并不是最优的，当 PM 做需求分析的时候需要