收集和分析需求时需要注意的问题

欢迎大家收听PM网事&＃xff0c;今天我们来聊聊需求。

需求这个话题大家已经聊得很多了&＃xff0c;我说一下个人的看法&＃xff0c;不涉及需求管理的全过程&＃xff0c;只讲需求的收集和分析&＃xff0c;这一期内容不管是项目经理还是产品经理&＃xff0c;只要是PM都可以听&＃xff0c;另外做运营的同仁们也可以听听&＃xff0c;希望大家听完后会有自己的结论。

我们知道&＃xff0c;不同的组织&＃xff0c;或者同一个组织不同类型、不同规模的项目&＃xff0c;收集和分析需求的方法是不同的&＃xff0c;所以脱离具体的环境和项目说方法其实就是在耍流氓&＃xff0c;具体的方法我们就先放在一边&＃xff0c;我们先聊聊需要注意的问题和常用的工具吧。

先说案例。话说当年&＃xff0c;某电商的一个核心部门发起了一个项目&＃xff0c;目标是要优化供应链的相关环节&＃xff0c;从而提升效率、降低成本、改善用户体验。现在&＃xff0c;我们假定项目刚刚被发起&＃xff0c;你已经被指定负责这个项目&＃xff0c;下一步就要收集和分析需求了&＃xff0c;你的整体思路是什么&＃xff1f;

听到这里&＃xff0c;熟悉电商业务的PM现在应该已经在掐着指头数这项目大概会涉及到多少部门和产品了&＃xff0c;没错&＃xff0c;这个项目当时涉及到了十几个部门和产品。

结合这个案例&＃xff0c;我就说在收集和分析需求过程里需要注意的地方&＃xff0c;总共有7点&＃xff1a;

第一点&＃xff0c;确保战略跟随和商业价值。
如今&＃xff0c;大部分的互联网组织其实是缺少持续稳定的收入来源的&＃xff0c;这就意味着组织所花的每一分钱从道理上来讲一定要产生期望的商业价值&＃xff0c;这些商业价值既可以是创造的营收、用户满意度的提升&＃xff0c;也可以是效率的改进&＃xff0c;总之不管商业价值是什么&＃xff0c;都要符合战略规划的需要&＃xff0c;这是对所有需求最最基本的要求。

第二点&＃xff0c;需要明确总体需求的控制者。
就上面的这个例子来讲&＃xff0c;这个项目涉及到了十几个部门和十几个产品&＃xff0c;那总体的需求应该是谁来负责把控呢&＃xff1f;是项目经理还是产品经理&＃xff1f;很清楚&＃xff0c;产品经理只负责自己的产品所对应的需求&＃xff0c;而总体需求一定是项目经理负责控制&＃xff0c;这一点虽然很明确&＃xff0c;但还是需要在项目里广而告之。

第三点&＃xff0c;需要尽可能弄清楚需求背后的真实动机。
我们都知道&＃xff0c;需求只是表象&＃xff0c;源自于需求提供方的内在动机&＃xff0c;虽然互联网倡导协作、信任、共赢&＃xff0c;还在实现扁平化、去控制等等&＃xff0c;可实际上我们的动机好像并没有真正地简单过&＃xff0c;而且越是大组织、大项目&＃xff0c;这些动机也就越不简单。有的需求方和你说提的这些需求是为了提高效率&＃xff0c;有可能他说的是实话&＃xff0c;但对于有的需求方来说&＃xff0c;他提出的需求其实另有深意。如果我们不了解真实的动机&＃xff0c;一些所谓的需求其实就变得非常的可笑&＃xff0c;这样的需求如果落地交付&＃xff0c;我们也许会收获可笑的结果。

第四点&＃xff0c;利益相关方的分析一定要做。
大家要是做项目管理的话&＃xff0c;对于利益相关方这个概念一定是很熟了&＃xff0c;在PMI也就是美国项目管理协会的词典里&＃xff0c;利益相关方这个词又叫做项目干系人&＃xff0c;我们以后就统一叫做利益相关方或者利益相关者吧。利益相关方这个概念对于专业的项目经理来说已经是很熟了&＃xff0c;但对于产品经理来说&＃xff0c;可能了解的人还不是很多&＃xff0c;我强调一点&＃xff0c;谈需求必谈利益相关方&＃xff0c;如果利益相关方的识别和分析都不做的话&＃xff0c;做需求是没有意义的。

第五点&＃xff0c;需求和实现方法不要混为一谈。
这个很简单&＃xff0c;比如需求方说了&＃xff0c;现在平台的用户体验不太好&＃xff0c;我们做个APP吧&＃xff0c;然后就是一堆的APP需求。这种时候我们心里一定要打个问号&＃xff0c;为什么要做APP&＃xff1f;做APP和提升用户体验之间有本质的联系吗&＃xff1f;做APP可能只是实现需求的方法之一。

第六点&＃xff0c;需求不等同于功能需求。
很多时候&＃xff0c;需求方和PM只要一提需求&＃xff0c;就会大谈特谈各种功能&＃xff0c;其实我们都知道需求除了功能之外&＃xff0c;还有很多其他的种类&＃xff0c;常见的有性能、质量、安全、可扩展、运维、兼容性、接口、数据等&＃xff0c;另外&＃xff0c;管理方面的需求也是很容易被忽视的&＃xff0c;我们在收集、分析功能需求的时候也要把这些种类的需求都要过一遍&＃xff0c;尽量不要遗漏。

第七点&＃xff0c;需求要尽可能保证合规。
合规这个问题在不同的组织、不同的发展阶段重要性是不一样的&＃xff0c;互联网因为自带颠覆、变革的属性&＃xff0c;所以目前互联网的有些领域确实是在踩法律和道德的红线&＃xff0c;而且在组织内部&＃xff0c;有时候越是高层管理者、越是风口行业&＃xff0c;也就越会有意无意地忽视合规的问题。法无禁止皆可为&＃xff0c;这句话基本没毛病&＃xff0c;但是如果我们发现要交付的产品和服务违反了法律和道德的话&＃xff0c;作为PM需要尽可能地坚持合规&＃xff0c;尽量避免发生后续的悲剧。最近一段时间互联网也发生了几件比较大的负面事件&＃xff0c;这些事件也需要我们引以为鉴。

好了&＃xff0c;需要注意的地方我已经说完了&＃xff0c;之所以说这几点&＃xff0c;是因为我发现这几点PM比较容易忽略。

下面我们来快速过一遍在收集和分析需求过程中经常用到的工具。

首先最常用的工具就是访谈、组织结构图和业务流程图&＃xff0c;另外还有一个常用的工具就是调查问卷&＃xff0c;调查问卷如果设计好了的话&＃xff0c;还是挺有价值的。

下一个工具是Business Usecase&＃xff0c;也就是业务用例&＃xff0c;用来收集和分析业务需求也是不错的。

利益相关方分析矩阵主要用来在多个维度分析利益相关方应该如何引导和对待。

下一个工具是RACI模型&＃xff0c;RACI模型可以用来确定各利益相关方的职责划分。

头脑风暴、焦点小组就不多说了&＃xff0c;主要用于分析需求。

评审会议就不说了&＃xff0c;大家都做过。

再有就是思维导图&＃xff0c;大家已经用的比较多了。

再有就是需求跟踪矩阵&＃xff0c;这是一个非常有价值的需求工具&＃xff0c;建议大家使用。

还有PBS、PFD&＃xff0c;主要用来把分析好的需求做分解&＃xff0c;类似于WBS。

再有就是MOSCOW&＃xff0c;用于确定需求的优先级。

另外还有多指标评分表&＃xff0c;多指标评分表也是用来确定需求优先级&＃xff0c;只不过这个评分表会涉及到多指标的换算&＃xff0c;至于是哪些指标、多大的权重&＃xff0c;这个需要自己根据情况来确定。

至于5W、5W2H主要用于需求的收集&＃xff0c;大家都已经用的比较多了。

竞品分析和可用性测试产品经理们都已经很熟了&＃xff0c;可以用来辅助确定和验证需求。

下一个就是Userstory和Usecase&＃xff0c;也就是用户故事和用例&＃xff0c;它们都是很好的需求分析工具&＃xff0c;需要根据项目和团队的情况灵活选用&＃xff0c;我个人更偏重于Usecase。

最后就是产品经理们最熟悉的PRD&＃43;原型了&＃xff0c;关于怎么写PRD&＃xff0c;怎么画原型&＃xff0c;大家在网上很容易就能找到很多资料&＃xff0c;PRD我建议还是用Usecase来描述和分析需求&＃xff0c;原型起到一个辅助的作用就可以了&＃xff0c;当然也有人认为没必要写PRD&＃xff0c;纯画原型就可以了。这件事情其实没有绝对的对和错&＃xff0c;需要具体情况具体分析&＃xff0c;但我认为图形和文字是两种不同的信息表现形式&＃xff0c;文字和图形对于人脑刺激的区域也不同&＃xff0c;完全用原型法来描述和分析需求&＃xff0c;出现问题几乎是必然的&＃xff0c;这其实不是我们能力的问题&＃xff0c;而是因为人的左右脑功能结构决定的&＃xff0c;所以我还是建议需求主要以文字为主&＃xff0c;图形为辅的模式&＃xff0c;这种模式对于团队其实是有好处的。

刚才我们说的例子是一个典型的项目&＃xff0c;既有项目经理&＃xff0c;也有产品经理&＃xff0c;所以上面说的这些工具有的是项目经理用&＃xff0c;有的是产品经理用。至于上面所说的这些工具用哪些不用哪些&＃xff0c;如果你所在的组织有PMO&＃xff0c;可以和PMO聊聊&＃xff0c;他们会给你具体的建议。

好了&＃xff0c;这期节目我们就聊到这里&＃xff0c;我们下期节目见。