新闻资讯门户
互联网、云计算领域最新资讯
首页 > 互联网 > 产品经理

产品经理PM硬技能篇:从底层看需求分析

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

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

本文的思路是:

  1. 需求分析的本质是什么?为什么要做需求分析?(Why)
  2. 目前常见的需求分析的方法论有哪些?(How)
  3. 如何更系统高效的分析需求?(How)
  4. 给大家一些启发来串联本文的知识。

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

一个产品从0到1,一般的必经流程是:

  1. 产品战略(到底要解决什么问题);
  2. 需求分析,输出Roadmap、需求文档PRD或User Story等;
  3. 设计团队:硬件、软件的UX和UI设计;
  4. 开发、QA、TA、运维团队:开发,测试,上线;
  5. 迭代。

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

  1. 理清具体有哪些需求和它们的优先级(考虑的是一个点:需求);
  2. 让团队能具体执行下去,团队包含设计、开发、QA、TA、运维等(考虑到的是一个线的局部:整个团队);
  3. 团队一起给客户高效地、持续地交付有价值的服务(考虑到的是一个完整的线:考虑到了外部的客户);
  4. 团队一起实现自我价值,获得成就感和物质奖励,内心充实(思考回归到人和自己)。

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

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

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

  • 以用户为核心;
  • 角色场景任务三要素。

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

  1. 基于界面:每个界面是一个独立的case,然后基于此再拓展出页面上的button、逻辑等;比如:App分析,下面的四五个Tab就是四五个主case。
  2. 基于功能模块:每个产品功能模块就是一个主case。
  3. 基于用户流程:用户使用一个功能的流程,比如:微信,简单的核心主case可分解为注册登录、加好友、跟好友聊天等等。

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

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

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

如何解决这个缺陷呢?

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

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

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

  1. 先列出所有跟这个服务相关的用户角色(Persona),如果是从0到1的产品强烈建议列出自己公司的不同团队、合作伙伴、客户的不同角色等,要全面,因为漏掉一个角色可能会导致你的业务跑不通或者不顺畅。
  2. 再列出你这个需求的目标,让你思考过程有个原则,不至于YY到跑偏。
  3. General Activity,我解读为High level的端到端任务流程。
  4. Epic:就是模块化需求。
  5. 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、设计和开发一起集中几天来快速完成设计定稿,规避反复冗长的沟通确认;
  • 一个是敏捷界的持续交付:持续交付的核心是一开始团队就要思考完整的服务流程,而不是各自思考自己的单点功能,而后期集成测试的时候,发现很多接口都缺失或对接不上。

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

未经允许不得转载,或转载时需注明出处:西部数码新闻资讯门户 » PM硬技能篇:从底层看需求分析
分享到:更多 ()

网友评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

中国领先的互联网域名及云服务提供商

为您提供域名,比特币,P2P,大数据,云计算,虚拟主机,域名交易最新资讯报道

域名注册云服务器