需求分析是产品经理的核心竞争力，如何做好需求分析是所有产品经理都需要重视的问题。本文作者从一个简单的小案例出发，对做好需求分析进行了梳理，拆解分成了4个阶段，供大家一同参考和学习。

　　前段时间一个产品交流群中关于“身份证号该隐藏几位”的讨论引发了我的思考。

　　猛的看来这只是很小的需求，产品经理们罗列了每个数字的含义、讨论着到底隐藏几位才能保护隐私，但迟迟没有定论。

　　这就是犯了产品最常见的错误：拿到需求马上想方案，没有想透到底是要解决什么问题，导致方案无法落地。

　　所以挖掘需求根本为产品经理的核心技能，本文将以“抬杠青年”来定义产品经理，细说“需求分析”那些事。

　　P.S.抬杠的精髓在于不停say why，深挖问题的本质。这里可不是让大家去做杠精，下文便是抬杠的正确姿势～

　　需求分析的目标，是将未加工的需求功能进行梳理，产出用于技术实现的文档。

　　俗话说“千里之行始于足下”，需求分析的核心就是对原始需求的梳理分析，若初期就找错方向，后续的所有工作就会麻烦不断：toC 产品可能用户不买账，甚者触及合规风险被要求整改，toB 产品则会验收不通过，打回重做。

　　需求梳理分下面这几个阶段进行：

　　收集需求需求可替代性、可行性分析沙盘推演，产出业务流程图需求反推验证

　　初始需求可以分为两大类：客户需求、自研需求；客户需求又可细分为：上级需求、甲方需求、用户需求。

　　需求收集阶段的目的，是挖掘需求本质，了解需要解决的问题。

　　客户需求：

　　多数时候需求方在提出需求的同时，都提供了对应的解决方法，这一点在处理B端需求的时候尤为明显。

　　若不对这种包装好的需求进行拆解，直接在此基础上出具方案，那么解决的仅仅是表层问题，根本问题还没解决，后续还会遇到类似问题，导致浪费开发资源、团队质疑产品能力、降低产品经理自身的成就感。

　　所以产品经理在拿到新需求后，都将其视为“包装”好的需求，需要分析根本需要解决的问题是什么。

　　直接拿以上问题去问需求方，那就是将需求整理的工作甩给需求方，需求方只知道自己当前遇到了什么问题，但是并不清楚其根本需要解决的问题是什么。

　　那么就需要产品经理帮忙去引导、挖掘，去不断“质问”需求方。根据已有的信息提出新的问题，来不断深挖问题根本。

　　引导方式采用案例法，谁都会讲故事，通过叙事、举例子的方式，可以帮助我们还原需求场景，挖掘出根本问题。

　　案例法与学生时期写作文类似，分为五要素：时间、地点、人物、干什么、遇到什么问题，所以产生了这个需求。

　　时间：不仅局限于时间，操作的状态、步骤也可作为时间；地点：不仅局限于地理位置，操作的终端也可作为地址；人物：进行操作的主体角色、本次操作涉及的人群；（不同的角色有不同的定位，所谓“屁股决定高度”，不同定位关注的方向就不同，比如老板关注结果，员工关注过程）干什么：发生了什么事、本次操作流程、期望达到的效果；遇到什么问题：遇到了什么阻碍、阻碍了什么操作的进展、造成了什么影响。不同类型的客户需求的沟通方式也有所差别：

　　1）上级需求：上级看重的是结果、收益，不关注过程。所以他们的需求大多是一个结果。

　　例如：在减少开发量的前提下让更多人买会员、后台生成数据月报等。

　　所以在沟通时，需要站在宏观业务的角度，从结果反推背景，不要陷于细节的沟通。

　　例如第一个需求的业务背景是领导决定减少该业务线技术投入，且不希望增加机器，希望通过小功能的迭代，在不影响vip客户体验的前提下，提升会员转化。

　　第二个需求的业务背景是每月商务需要与甲方结算，人工从各字表提取数据太耗精力，希望自动生成。

　　2）甲方需求：甲方需求方的级别不同，所以需求类型可能是结果型，也可能是操作型。

　　但他们大都有一个共同点，就是会对原始需求做一层包装，用他们认为合理的解决方式来提需求。

　　产品经理需要将该需求涉及到的所有人拉到一起，一块讨论实际想解决的问题是什么，他们平时工作时是如何解决此类问题，所有人的意见达成一致后，产品经理再去思考针对需要解决的问题，是否有更优的解决方案。

　　3）用户需求：用户需求为操作类型，可直接采用五元素法来收集。

　　4）自研需求：自研需求就不必多说，不论是自己分析产品进行迭代，或是通过竞品分析来优化，一定都要有一个明确的方向：具体是为了解决什么问题，实现什么目标。

　　若方向没有明确，之后的工作就会像无头苍蝇一样乱撞，效率极低。

　　收集需求后，已明确用户实际需要解决的问题是什么，接下来，就要针对需求本身去思考，这个需求是否有现成可替代功能、是否值得去做，是否能做。

　　因为产品经理作为需求的第一接收者，不应该当传话筒，将外部传来的需求全部都一股脑交给开发。

　　应当先对其做一层筛选，决定是否有必要进行之后的工作。

　　流程如下：

　　第一步 ：是否有可替代性

　　没有谁比产品经理更熟悉产品，所以产品可能已经有现成功能可直接/间接解决用户问题，那么就没必要进行后续工作，将解决方案提供给需求方，确认其是否可以接受。

　　第二步 ：是否值得去做

　　每个产品都需要一套“产品原则”。

　　产品原则是对团队信仰和价值观对总结，用来指导产品经理作出正确的决策和取舍。

　　制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。——《启示录》第13章

　　根据产品原则，可判断该需求是否值得去做，处理的优先级如何。若判定不解决，需要将原因结合产品原则反馈给需求方。

　　第三步：是否能做

　　经过前两步，该需求已经确认需要实现，这一步需要根据当前系统架构、开发水平、运营成本等多方面考虑，该需求是否能实现。

　　这一阶段需要技术参与，一般不可做的原因有三种：当前系统架构不支持，需要重构；开发水平有限，不能实现；运营成本过高。

　　拿到不可做的原因后，需要与上级沟通，让上级决定是否要重构、新招开发、支付相应成本。

　　这一步沟通也有技巧，给上级提供最够多的信息来辅助判断：需求方、需要解决的问题、大致实现成本、影响范围。

　　通过以上筛选，需求就是经过筛选的待处理状态，可以进入下一步啦。

　　从需求转化为解决方案，需要先进行一次详细的沙盘推演，将操作过程走通、异常情况都考虑进来，才会保证最终产出的解决方案的定位准确、覆盖面全，不会产生遗漏。

　　闪盘推演，即根据需求的业务背景，将业务流程中所有涉及到的系统、用户间的交互，用流程图的形式进行流程梳理，帮助产品经理缕清业务逻辑。

　　在每个交互的过程中都可能产生异常，明确的流程图有助于提前将可能发生的异常情况尽可能全面的提前梳理出来。

　　流程图的制作过程不在本文详述。

　　该阶段的产出，为业务流程图、异常情况梳理表。

　　注：一般在这一步，脑中会生成大概的解决方案。

　　沙盘流程配合当前问题的解决方案+实现成本，可能会发现第一步分析出来的问题还不是最根本的，还有更底层的问题需要先解决。

　　这样就需要返回第一步重新进行一次需求梳理工作。

　　上面三个阶段，就完成了需求的梳理过程，产出方案前的最后一步，便是去质疑自己，反推以上的产出，是否是真正用户需要解决的问题，业务逻辑是否准确。

　　反推过程需要需求方的参与，产品提供需求梳理的产出资料，与需求方check。

　　需求再紧急，这一步都是一定要做的，需求梳理结果没有与需求方进行确认，可能整个过程都是产品经理的自嗨，初始的方向错了，没解决用户需求。

　　方向与需求方确认无误后，再与需求方一起分析第三阶段中“异常情况”的处理，这部分属于方案制定阶段，本文不做详述。

　　该阶段完成后，若是B端需求，需要进行邮件确认，作为留痕。在后期产品交付时以此需求为准。

　　拿到需求后，先不要急于动手，先进行需求梳理：

　　收集需求阶段：剖析用户实际需要解决的问题；需求可替代性、可行性分析：该需求是否有现成功能可解决，根据“产品原则”判断这个需求是否值得去做，从成本考虑这个需求是否能做/要做；沙盘推演：从业务出发，产出业务流程图，梳理异常情况；需求反推验证：将以上产出与需求方进行确认，确保初始方向正确不断提问，以“抬杠青年”的姿态多问为什么，会在初期尽可能的挖掘很多潜在的“坑”。

　　前期多花点时间调研需求，总比开发后期改需求强，大家说是不是这个理？

　　作者：橘子；公众号：橘子周思录；我是3年产品橘子，每周分享自己对日常工作的总结思考，希望与您一同成长。

　　本文由 @橘子 原创发布于人人都是产品经理，未经作者许可，禁止转载。

　　题图来自Unsplash，基于CC0协议。

　　本文是作者对业务主导、产品经理话语权、成长方向的一些看法，如果你也有这方面困惑，不妨看看~

　　最近关于业务公司产品经理的争论很凶，我也聊聊我的看法。

　　鄙人不才，刚巧就是在业务主导的公司里做产品经理，而是偏业务线的产品经理，还做超过了3年。所以对于这个问题应该是有发言权的。

　　在业务公司做产品时，最大的质疑就是，你都没有决策权，你还算产品经理吗？

　　这个事我是这样看的：首先来说，没有决策权是复杂条件造成的，并不能完全把这个锅甩给业务主导。举个例子来讲，自上而下的决策机制，也会导致产品经理失去决策权，一切都领导说了算嘛反正。

　　所以业务主导，只是减少产品经理决策权的一个主要因素而已。

　　那么真实的场景是什么样的，产品经理真的失去了决策权吗？首先把一个产品立体来看，底层是业务逻辑，只不过很多C端产品的业务本身就是产品团队或运营团队。所以他们会有很大的决策权，并且很多时候都直接合并为产品运营岗，就是为了决策权不分散。

　　底层之上，是产品逻辑。产品逻辑和业务逻辑什么区别呢？举个例子来讲，对于一个智能招聘系统来说，HR团队是业务团队，他们背负了招聘率、差评率等等好多指标，也决定了招聘规则和流程。也就是说这套业务规则是业务团队掌控的，统称为业务逻辑。

　　而业务逻辑，会成为产品经理的一道命题作文题。也就是说，你的想法再多，再正确，不能超于命题之外，否则也是零分的。

　　那么产品逻辑是什么呢，在这个业务框架下，产品经理究竟能做什么呢？

　　首先第一点就是，要抓住业务这个命题，确定你的中心思想。也就是说，你的一切产品逻辑，都是为了业务指标的提升而设计的。

　　如果业务要提高招聘率，你就要把投递简历的渠道同步变得极其强大，把整体招聘系统的效能提高到极致。但这个时候，就衍生了两个问题：

　　其实往往来说，业务指标和产品团队的指标就是不太符合的，并且产品经理往往对业务指标不太敏感，这就容易造成产品经理和业务的互相不信任。

　　从业务的视角来看：你这个产品经理可有可无啊，我底层逻辑已经给你了，你还跑出来做拦路虎，这不是影响业务吗？

　　而从产品经理的角度来看：你的底层逻辑虽然有，但是缺乏产品感，很多东西没有用户体验，商业和数据价值也不够，肯定需要完善啊！

　　这样一来一回如果没有对齐口径，就会加深两方的误会，那么解决方法是什么呢？

　　鉴于这是一个天然的冤家问题，我们就只能采取缓解化解的手段，而不是硬钢。老实说，在业务主导公司内部，任何试图抢占主导地位的团队，最后好像都很惨。

　　所以化解的角度来说，就是多找业务谈心，把他们的诉求当作自己的诉求，把他们的指标变成自己的指标。如果遇到方案上的摩擦，一定要不卑不亢。如果你选择卑微，那你得不到业务的尊重，他们会更加觉得你可有可无。如果你太亢进，对方又会觉得你越界，扮演了拦路虎。

　　不卑不亢这个境界，是我们具体情况具体分析才能达到的一种状态，所以在这里只能给一个方向，毕竟这个状态很多产品经理做了10年都没有达到。

　　这一点其实可以算作一个命题，也就是科技转型。我一直认为，科技转型不是要转变为科技驱动，而是科技的数据思维、产品思维能够内化到业务团队当中去，变成业务决策的一大因子，这样才能起到科技驱动的作用，才算完成了转型。

　　业务仍是主导，科技也无需和它互相替代，只不过更加加深了底层的合作。

　　对应到这个问题来看，就是产品经理要尽早主动地参与到业务的决策当中去，贡献出自己的意见。这点实现起来其实特别难，举个例子讲：业务一般会提交很多需求给到产品经理评估、落地，这个时候其实产品经理的时间已经被占满了，如果再介入业务，工作量上讲其实是超量的。

　　为了解决这个问题，一般科技转型都会提出一个办法，叫做“拥抱业务”。拥抱业务指的是，科技人员向业务团队靠拢，但怎么靠拢呢？是直接取消产品经理，研发直接对接业务吗？不是的。

　　拥抱业务绝对不是减少流程和环节，而是把所有的职能业务化。比如：产品经理更多地参与到业务决策，而RD更多地参与一些产品经理需求分析的工作，这样环环相扣，大家就把业务的工作量逐层承接传导到了研发层面。而业务多出来的时间，可以用来了解研发团队。这样一个工作量的平移，就可以带来整体科技元素的比重，以及产品经理参与度的提升。

　　所以老实说，有几个命题一定是正确的：

　　只会产品、技术、设计但没有某个领域业务深耕经验的产品经理是无价值的；在没有科技转型战略的业务型企业，产品经理想靠个人努力站主导地位是不现实的；产品文化和工程师文化到最后都是回归业务，C端个别如搜索等领域技术本身就是业务。

　　那么产品经理能做的是什么呢？

　　首先从日常工作流程来讲：

　　其实跟做C端一样，也是了解业务。只不过C端的业务就是流量运作，包括增长和留存还有转化。而B端就是了解这门生意是怎么运作的。而研究流量运作，最重要的就是看数据、做分析、想方案。而研究一门生意，要看的不仅仅是产品数据，要做的还有业务数据指标和业务场景访谈、用户调研。

　　鉴于此，我们工作的形式就有差别。做C端产品时，要多看数据多分析。做B端产品时，要多调研访谈。之前做C端时，我几乎每天80%的时间都在看数据，写文档。现在做B端，我几乎要花大半天时间调研问题再找人办事。所以千万不要认为只有写文档才是正事，开会和聊天可能更重要。

　　最重要的是需求运作模式就完全不一样了：

　　业务主导的研发团队来说，因为业务支持都是P0级别的第一时间响应要求，所以业务提出一个需求，只需要跟领导汇报，然后强压给研发团队即可。而产品产出的需求，需要内部上级汇报、总监汇报，再由总监和业务老大碰，碰完之后再跟业务自己提的需求PK。

　　支持需求和自发需求相比，一个是一级汇报，一个是四级汇报，时间周期和效率都没法比，所以产品经理觉得累，觉得自己想做点事情非常难。

　　但这样有没有好处呢？好处就是产品经理的沟通技巧要求非常之高，业务主导公司是一个很好的提高沟通技巧的环境。对于四个层级的汇报，你要准备不同角度的材料，再充分考虑好每层级汇报可能的后果，可能的需求变更和修改时间，最后来算算自己的需求什么时候可以上线。这样流程下来，一个好的方案一定是具有很高价值且经过多方打磨的方案。

　　所以我提了一个问题，产品经理到底是决策者还是执行者？

　　我个人倾向于后者。我觉得决策其实没有我们想象的那么重要、那么必不可少，而执行的过程也没有我们想象的那么固定和不可操作。很多时候命题命好了，能不能挖到价值才是你的本事。

　　最后给大家一点建议：决策和执行都只是形式层面的人为区分，所以我觉得产品经理最重要的不是决策也不是执行，而是迅速搞清楚团队的所需，然后补充上去。这个补充的形式可能是产品规划、项目管理、微决策或是会议组织，但只要是能提升用户体验和商业价值的活，都值得一做。

　　那么产品经理的核心竞争力是什么呢？

　　我觉得就是迅速切入一个行业、一个团队的能力，这个能力需要很高维度的思考模型、很深层次的经验来支持。所以日常我们一定要关注每一个项目，不断问自己能不能做到更好。

　　实践永远是最重要的。产品之术之所以有这么高粘性的关注者，就是因为我不是为了写而写，脱离了实践的写作和命题，本身对于自我和他人都是没有帮助的。只有从实践中的总结，才有个人特色，才有经验价值，才能形成输入和输出的闭环。

　　所以遇到任何问题千万不要第一时间拿自己的现有知识去套，这样只会让你陷入想当然和不理解，但多实践、多感受、多摸清楚问题后，才能看到真实的世界，这个时候再总结思考才有意义。

　　以上是我对业务主导、产品经理话语权、成长方向的一些看法，如果你也有这方面困惑，不妨参考尝试一下，也可以随时和我交流。

　　与君共勉。谢谢！

　　花生酱先生，微信公众号：产品之术，人人都是产品经理专栏作家。金融业资深产品经理，对职涯规划与个人发展有丰富经验，产品涉猎广泛，ERP、金融领域较多。

　　本文原创发布于人人都是产品经理。未经许可，禁止转载。

　　题图来自Unsplash，基于CC0协议