项目

作为一名产品经理，撰写PRD文档是基本功之一，但依旧有很多同学写不好高质量的PRD。那么该如何写出高质量的PRD，应对后续工作呢？作者结合自己的实战，与你分享了一些技巧，希望对你有所帮助。 需求文档PRD是产品经理最基本的工作。优秀的产品经理一定能写出优秀的PRD，不能写高质量PRD的产品经理大概率不是优秀的产品经理。 今天笔者同大家一起聊聊写PRD那些事儿。 本文的前提是需求已经规划好，你拿到自己的需求开始做产品规划。 一、PRD的目标用户 写好一份的PRD其实并不容易，首先PRD的读者就需求就很难统一。 对于优先级，我个人的建议是：开发>设计师>业务，老板视情况而定。业务结合UI沟通效率更高，跟设计师则可以在线下持续共同需求。但是产品经理对开发过程的参与度很低，同时开发过程也是人力、时间成本投入最高的，一旦因为PRD描述不清导致开发事故，纠错成本就会很高。 二、写PRD前的准备 产品经理尤其是经验较少的产品经理，要避免拿到需求就开始“高效”输出PRD的误区。否则很可能写出自己觉得非常完美，但是被老板和业务劈头盖脸狂喷的PRD。 俗话说“磨刀不误砍柴工”，要避免写出自嗨的PRD，需要先了解用户需求。 例子： 背景：你在一家电商公司工作，现在公司想要做一个商品推荐的功能，并且将工作分配给了你。 你拿到需求之后，开始思考，这个推荐功能是面向所有用户的吗？显然不是，对于那种有明确购买目标的用户似乎不适用。 于是你查看公司的用户画像，发现主要用户分成如下几类： 这时你发现用户画像在线制作，小美、小英、小计都能作为商品推荐的目标用户。于是你跑去找Leader，问他是要为这三类用户都做推荐吗？你的Leader摸着脑袋不好意思的笑了，说“这次是想为一些小商家做商品推荐，帮他们提高客流量，工作太忙，忘记跟你交代了”。 于是你知道小美是你最主要的目标用户，需要针对年轻女性的偏好做推荐，使用的场景集中在非工作时间。需求的方向终于确定了。你在腹诽Leader的时候，也为自己的机智点赞。 如果你再多想一步，还会注意到公司目前的战略方向是吸引小商家，那么不止是推荐商品功能可以做，店铺推荐、小商家流量折扣等功能都可以做。 三、功能拆分 了解了用户需求之后，就可以开始产品功能设计。产品设计的第一步就是做功能拆分，功能拆分好之后，才好对每个功能展开描述，撰写PRD。我习惯按照敏捷开发的思路进行。 1. 拆分原则 功能拆分应当基于INVEST和MVP的原则，以使拆分的功能更合理。 INVEST用于拆功能，将复杂、庞大的功能（Epic、Feature）拆分为简单、微小（Story）的功能。不了解Epic等含义的，可以自行了解敏捷开发的方法，在此不能面面俱到。 1. Independent（独立原则） 指的是用户故事（Story）需要彼此独立，低耦合。应当做到功能在业务流程、功能界面、数据、用户目标等层面的低耦合。这样做的好处是有利于灵活的选择Story规划、设计、开发和验收。比如“登陆账号”和“登陆密码”不是独立的，“手机登陆“和“邮箱登陆”是独立的。 2. Negotiable(可协商原则） 指的是用户故事应当是可协商、可讨论的，不能是定死的。不要把用户故事写成合同，事无巨细，不可更改。应当在不断的讨论、细化中成型。 3. Valuable（有价值原则） 指用户故事对于用户来说是重要的，有价值的。这个不用赘述，是产品功能最基本的要求。同时价值也决定了用户故事的优先级。 4. Estimable（可估算原则） 指开发团队能够根据用户故事估算所需的工作量。包含两层意思，用户故事是可实现，且方便开发团队预估开发工作量。比如“根据用户心情改变手机主题”在现有技术条件是不可实现的，“根据天气、节日改变手机主题”是可以实现的且可估算的。 5. Small&Similar Size（规模小且适中原则） 功能越小，排期预估越准，但是过小也会导致管理难度增大。并且多个用户故事之间的开发工作量差异不宜过大。所以要根据团队的情况，切分出大小合适的功能，以能够在一个迭代内完成几个用户故事。比如登陆功能可以分成手机号、邮箱、第三方等登陆方式，可以将每种登陆方式单独拆出来，根据优先级和资源情况安排迭代。 6. Testable（可验证原则） 指用户故事必须是可以被验证的。我认为可以分成三个层面理解。 功能设计阶段，能够去验证用户故事的价值、合理性。开发实现阶段，能够有清晰的验收标准，确认开发结果满足设计需求。发布跟进阶段，能够收集到明确的市场反馈和效果判断标准，以判断是否达到设计预期，方便后续的迭代优化。 MVP(Minimum Viable Product)最小可行产品是极其重要的原则。无论公司大小，团队资源多少，按照MVP都能够保证项目团队一直在做最重要的事情。...