PM硬技能篇：从底层看需求分析

大家都知道，有一个Idea之后，一般就要进行需求分析和拆解来落地，每个公司每个人可能都会有不同的拆解方法论，本文主要从底层来系统跟大家聊下为什么要做，如何做需求分析。

先统一下大家对词汇的认知，对于需求分析，有很多不同叫法：需求分析、需求分解、需求拆解、User Case分解、User Story分解等等，本质说的都是一个事，就是对需求进行进一步详细分析，来确保整个团队正确理解。

本文的思路是：

需求分析的本质是什么？为什么要做需求分析？（Why）

目前常见的需求分析的方法论有哪些？（How）

如何更系统高效的分析需求？（How）

给大家一些启发来串联本文的知识。

一、为什么要做需求分析？

一个产品从0到1，一般的必经流程是：

产品战略（到底要解决什么问题）；

需求分析，输出Roadmap、需求文档PRD或User Story等；

设计团队：硬件、软件的UX和UI设计；

开发、QA、TA、运维团队：开发，测试，上线；

迭代。

我们今天要探讨的是上面的#2，那么我们来思考下，很多人可能立刻就想到思维导图工具、麦肯斯MECE分解法则等，我想跟大家一起思考的是Why，就是分析需求的目的和原因，下面四点逐层深入：

理清具体有哪些需求和它们的优先级（考虑的是一个点：需求）；

让团队能具体执行下去，团队包含设计、开发、QA、TA、运维等（考虑到的是一个线的局部：整个团队）；

团队一起给客户高效地、持续地交付有价值的服务（考虑到的是一个完整的线：考虑到了外部的客户）；

团队一起实现自我价值，获得成就感和物质奖励，内心充实（思考回归到人和自己）。

二、目前常见的需求分析的方法论有哪些？

国内开始出现PM这个职位还要感谢乔布斯、BAT的引领，大概是在2010年左右，近3到5年是PM从业的高潮期，所以国内PM的发展历史大概也不到10年，加上每个公司的情况不同职责就不同。

所以也一直没有特别万能的套路给PM们使用，只有一些high-level的Guideline，比如：

以用户为核心；

角色场景任务三要素。

基于此，常见的几类需求分析的框架输出有：

基于界面：每个界面是一个独立的case，然后基于此再拓展出页面上的button、逻辑等；比如：App分析，下面的四五个Tab就是四五个主case。

基于功能模块：每个产品功能模块就是一个主case。

基于用户流程：用户使用一个功能的流程，比如：微信，简单的核心主case可分解为注册登录、加好友、跟好友聊天等等。

下图就是网上看到的一个1和2的混合版：

以上三个分解方法理论来说，是不断有改进的，他们的好处是：模块清晰了、case遍历穷举了、也有条理了。但是他们都有一个明显的缺陷：各个分支case是孤立的，你看不到全局这个大系统，看不到各个分支之间的相互关系。

三、如何更系统高效的分析需求？

如何解决这个缺陷呢？

此时要引入敏捷理念下的一个方法：User Story Mapping（用户故事地图）

这个地图的层级也有很多不同的形式，我个人经过实践输出了一个感觉比较好落地和理解的形式，举一个实际的例子Task，也就是大家在用的to-do任务管理工具的功能：

从上图例子中大家可以看到，其思路是：

先列出所有跟这个服务相关的用户角色（Persona），如果是从0到1的产品强烈建议列出自己公司的不同团队、合作伙伴、客户的不同角色等，要全面，因为漏掉一个角色可能会导致你的业务跑不通或者不顺畅。

再列出你这个需求的目标，让你思考过程有个原则，不至于YY到跑偏。

General Activity，我解读为High level的端到端任务流程。

Epic：就是模块化需求。

User Story：就是每一个子case。

另外，值得一提的是这个方法可以跟“服务设计”以及腾讯内部据说不提“产品”只提“服务”是完美匹配的，这也就再次验证了此方法的科学性。

这样做的好处是：

你看到并看清了整个系统；

利用Persona连接了各个孤立的分支；

优先级通过任务流程更容易看清晰，更容易找出MVP；

不同意遗漏重要的User Case。

四、给大家一些启发来串联本文的知识

首先我想让大家思考2个问题：

1. 需求的详细分析分解一定要PM来承担吗？

之前看到了一篇关于硅谷和中国的PM与工程师之间的差异的文章，本人刚好在两类公司都工作过，我对那篇文章说的有深刻体会：

硅谷有工程师文化，工程师懂技术也懂产品，PM懂产品也懂技术，目前我们公司当提出一个需求的时候，PM会思考需求并且会考虑技术实现，然后你要自己去Drive不同开发团队的人来组队来实现你的需求，如果你不懂技术基本就无法完成工作（PM和开发配合很顺畅）。

而国内的PM是承包了所有产品需求的部分，不怎么考虑开发的实现，开发只考虑实现不去深入理解或思考需求，这就导致了PM越来越不懂技术，开发越来越不关系需求的价值，也就导致了双方经常相爱相杀（配合不太顺畅）。

2. 是否要按照开发喜欢或者某个固定的模式去拆分呢？

启发：敏捷理念有一个3C原则（Card一句话的卡片式需求、Communications密切双向沟通、Confirmation确认达成共识），这个我觉得特别适合PM与Team之间的合作分工。

简单概括来说，可以讲目前是同步串联模式（PM交付需求给设计，设计画UX和UI给开发和QA，开发和QA实现给运维），完全可以革新转换为异步并行模式（PM、开发、QA、TA、Ops打破各自边界，前期一起来介入需求的分析，避免了后期反复的沟通，也提升了团队对目标的一致性认可，自然可达到齐心协力的效果）。

除了硅谷的合作模式的思考外，还有俩个新的理念也非常值得学习，它们也验证了上面说的配合模式是值得学习和探索的。

一个是设计界的设计冲刺：强调PM、设计和开发一起集中几天来快速完成设计定稿，规避反复冗长的沟通确认；

一个是敏捷界的持续交付：持续交付的核心是一开始团队就要思考完整的服务流程，而不是各自思考自己的单点功能，而后期集成测试的时候，发现很多接口都缺失或对接不上。

感谢你读完此篇，希望对你有所启发，本人会持续分享此类思考的结果。