这段时间我做了两个大项目，其中一个项目算是商业模式上和使用规范上的调整，另一个项目是之前功能的重做，为什么重做我下面会说到。关于需求分析，我认为把需求抽象成产品功能花费的时间占到了软件开发周期的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做需求分析的时候需要细致观察他们部门或者个人的工作内容，想一想为什么这么样做，有没有其他方案能提高其工作效率。在做数据统计需求的时候我发现业务部门某同事每天要先导出所有新用户电话、订单号、餐厅金额、订单金额等数据用于考察配送员满意度、用户满意度，然而她每天导出的数据其实有另外两个同事也需要用，只是使用目的不一样，但是他们都很死板，他们三个每天导出一份完整数据，然后筛选条件，组合成自己要的数据，这种工作其实很没必要，我们可以每天为他们部门发一份当日订单报表，标注新用户即可。还有个例子是，财务在结算物流人员工资的时候很多计算公式是相互关联的，比如说A=B+C，D=A*E+B-C，然而他们就计算成D=(B+C)*E+B-C，暂且不说他们部门管理流程怎么样，但是PM在遇到这样业务流程的时候结合产品设计考虑是否可以精简流程，实现产品设计的初衷的同时也能简化流程。
3:离散需求整合
在和业务部门打交道的时候发现他们的思维逻辑性可能稍微差点，在PM了解需求的时候业务人员或者用户表述的没有前因后果，也就是没有逻辑性，这时如果PM不追问下去自己很容易被带到坑里面，合格的PM应该在这种情况下峰回路转，把问题再阐述一遍，如遇到稍微强势一点的PM，此时应该会指出刚才的表述有错误。还有的业务部门人员在你去沟通的时候哗啦啦的说了一大推产品改进意见或者新需求想法，此时PM应该细心聆听，记录下需求点，千万不要给他们答复这个功能什么时候做、什么时候上线，因为系统永远是不完善的、需求却永远是数不尽的，而资源是有限的，你给的答复实现不了别人会有不好的看法，优秀的PM需要大局观，能够和团队一起评估需求优先级，规划产品生命周期，这才能推进产品迭代。
4:技术人员参与需求分析阶段
现在很多互联网公司基本上都是产品驱动，很难说技术驱动，因为产品团队可以知道用户想要什么，我在参与需求分析过程中事业部技术负责人喜欢跟着我一起去了解需求，这在我之前的工作组中没遇到过，现在做需求的时候他参与进来后我发现整个产品需求被乱了，阻碍了我需求分析进度，因为他总是以技术的角度考虑这样实现的难度，由于他是技术负责人，逻辑思维能力很强，每当听到这个数据没有需要新增一个入口去维护时他就站出来说为什么要这样做，然后劝说业务部门说这个数据提供不了，能不能先不做，但是从产品角度上考虑，既然选择做这个项目那么就该从产品角度去设计好，等一整套产品方案出来之后再去精简功能是一个很好的方法，还有一些情况是当有一个比较好的idea产生时技术人员会首先考虑能不能实现、实现的复杂度，如果有一点困难或者技术可行方案不能当场给出时，这个功能就暂且搁置了，也许就会提出另一个不会错但是并不是最好的方案，所以技术人员参与需求分析阶段最容易把原本一个好的产品扼杀在摇篮之中。综上考虑，我的理解是技术人员在需求分析阶段暂且不要参与进来，等产品团队内部讨论之后技术团队参与审评，这样也许能达到事半功倍的作用。
网友评论