产品经理如何做好需求分析？教你做个抬杠青年！
副标题[/!--empirenews.page--]
前段时间一个产品交流群中关于“身份证号该隐藏几位”的讨论引发了我的思考。 猛的看来这只是很小的需求，产品经理们罗列了每个数字的含义、讨论着到底隐藏几位才能保护隐私，但迟迟没有定论。 这就是犯了产品最常见的错误：拿到需求马上想方案，没有想透到底是要解决什么问题，导致方案无法落地。 所以挖掘需求根本为产品经理的核心技能，本文将以“抬杠青年”来定义产品经理，细说“需求分析”那些事。 P.S.抬杠的精髓在于不停say why，深挖问题的本质。这里可不是让大家去做杠精，下文便是抬杠的正确姿势～ 需求分析的核心需求分析的目标，是将未加工的需求功能进行梳理，产出用于技术实现的文档。 俗话说“千里之行始于足下”，需求分析的核心就是对原始需求的梳理分析，若初期就找错方向，后续的所有工作就会麻烦不断：toC 产品可能用户不买账，甚者触及合规风险被要求整改，toB 产品则会验收不通过，打回重做。 需求梳理分下面这几个阶段进行：
1. 收集需求阶段：杠需求方初始需求可以分为两大类：客户需求、自研需求；客户需求又可细分为：上级需求、甲方需求、用户需求。 需求收集阶段的目的，是挖掘需求本质，了解需要解决的问题。 客户需求： 多数时候需求方在提出需求的同时，都提供了对应的解决方法，这一点在处理B端需求的时候尤为明显。 若不对这种包装好的需求进行拆解，直接在此基础上出具方案，那么解决的仅仅是表层问题，根本问题还没解决，后续还会遇到类似问题，导致浪费开发资源、团队质疑产品能力、降低产品经理自身的成就感。 所以产品经理在拿到新需求后，都将其视为“包装”好的需求，需要分析根本需要解决的问题是什么。 直接拿以上问题去问需求方，那就是将需求整理的工作甩给需求方，需求方只知道自己当前遇到了什么问题，但是并不清楚其根本需要解决的问题是什么。 那么就需要产品经理帮忙去引导、挖掘，去不断“质问”需求方。根据已有的信息提出新的问题，来不断深挖问题根本。 引导方式采用案例法，谁都会讲故事，通过叙事、举例子的方式，可以帮助我们还原需求场景，挖掘出根本问题。 案例法与学生时期写作文类似，分为五要素：时间、地点、人物、干什么、遇到什么问题，所以产生了这个需求。
不同类型的客户需求的沟通方式也有所差别： 1）上级需求：上级看重的是结果、收益，不关注过程。所以他们的需求大多是一个结果。 例如：在减少开发量的前提下让更多人买会员、后台生成数据月报等。 所以在沟通时，需要站在宏观业务的角度，从结果反推背景，不要陷于细节的沟通。 例如第一个需求的业务背景是领导决定减少该业务线技术投入，且不希望增加机器，希望通过小功能的迭代，在不影响vip客户体验的前提下，提升会员转化。 第二个需求的业务背景是每月商务需要与甲方结算，人工从各字表提取数据太耗精力，希望自动生成。 2）甲方需求：甲方需求方的级别不同，所以需求类型可能是结果型，也可能是操作型。 但他们大都有一个共同点，就是会对原始需求做一层包装，用他们认为合理的解决方式来提需求。 产品经理需要将该需求涉及到的所有人拉到一起，一块讨论实际想解决的问题是什么，他们平时工作时是如何解决此类问题，所有人的意见达成一致后，产品经理再去思考针对需要解决的问题，是否有更优的解决方案。 3）用户需求：用户需求为操作类型，可直接采用五元素法来收集。 4）自研需求：自研需求就不必多说，不论是自己分析产品进行迭代，或是通过竞品分析来优化，一定都要有一个明确的方向：具体是为了解决什么问题，实现什么目标。 若方向没有明确，之后的工作就会像无头苍蝇一样乱撞，效率极低。 2. 需求可替代性、可行性分析阶段：杠需求收集需求后，已明确用户实际需要解决的问题是什么，接下来，就要针对需求本身去思考，这个需求是否有现成可替代功能、是否值得去做，是否能做。 因为产品经理作为需求的第一接收者，不应该当传话筒，将外部传来的需求全部都一股脑交给开发。 应当先对其做一层筛选，决定是否有必要进行之后的工作。 流程如下： 第一步 ：是否有可替代性 没有谁比产品经理更熟悉产品，所以产品可能已经有现成功能可直接/间接解决用户问题，那么就没必要进行后续工作，将解决方案提供给需求方，确认其是否可以接受。 第二步 ：是否值得去做 每个产品都需要一套“产品原则”。 产品原则是对团队信仰和价值观对总结，用来指导产品经理作出正确的决策和取舍。 制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。——《启示录》第13章 根据产品原则，可判断该需求是否值得去做，处理的优先级如何。若判定不解决，需要将原因结合产品原则反馈给需求方。 第三步：是否能做 经过前两步，该需求已经确认需要实现，这一步需要根据当前系统架构、开发水平、运营成本等多方面考虑，该需求是否能实现。 这一阶段需要技术参与，一般不可做的原因有三种：当前系统架构不支持，需要重构；开发水平有限，不能实现；运营成本过高。 拿到不可做的原因后，需要与上级沟通，让上级决定是否要重构、新招开发、支付相应成本。 这一步沟通也有技巧，给上级提供最够多的信息来辅助判断：需求方、需要解决的问题、大致实现成本、影响范围。 通过以上筛选，需求就是经过筛选的待处理状态，可以进入下一步啦。 3. 沙盘推演阶段：杠需求从需求转化为解决方案，需要先进行一次详细的沙盘推演，将操作过程走通、异常情况都考虑进来，才会保证最终产出的解决方案的定位准确、覆盖面全，不会产生遗漏。 闪盘推演，即根据需求的业务背景，将业务流程中所有涉及到的系统、用户间的交互，用流程图的形式进行流程梳理，帮助产品经理缕清业务逻辑。 在每个交互的过程中都可能产生异常，明确的流程图有助于提前将可能发生的异常情况尽可能全面的提前梳理出来。 流程图的制作过程不在本文详述。 该阶段的产出，为业务流程图、异常情况梳理表。 注：一般在这一步，脑中会生成大概的解决方案。 沙盘流程配合当前问题的解决方案+实现成本，可能会发现第一步分析出来的问题还不是最根本的，还有更底层的问题需要先解决。 这样就需要返回第一步重新进行一次需求梳理工作。 4. 需求反推验证阶段：杠自己上面三个阶段，就完成了需求的梳理过程，产出方案前的最后一步，便是去质疑自己，反推以上的产出，是否是真正用户需要解决的问题，业务逻辑是否准确。 反推过程需要需求方的参与，产品提供需求梳理的产出资料，与需求方check。 需求再紧急，这一步都是一定要做的，需求梳理结果没有与需求方进行确认，可能整个过程都是产品经理的自嗨，初始的方向错了，没解决用户需求。 方向与需求方确认无误后，再与需求方一起分析第三阶段中“异常情况”的处理，这部分属于方案制定阶段，本文不做详述。 该阶段完成后，若是B端需求，需要进行邮件确认，作为留痕。在后期产品交付时以此需求为准。 综上，做个总结（编辑：91站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
