产品经理如何避免和技术人员的争论,提出一份优质PRD显得格外重要。这篇文章从功能关联性、通用CASE、备选方案3个角度出发,教你写一份没有遗漏的PRD。 细数产品经理和技术之间的口舌大战,往往是因为评审过程中需求有遗漏大家需要会议上花时间讨论,又或者是开发到一半技术发现有个点有遗漏,双方互相责怪导致争执。 多次发生后,技术会对事情的不满演变为对产品经理的不信任,以致于对产品经理做的决策潜意识表示质疑。 在这种潜意识下,产品经理在推进需求时,极有可能首先遇到的是技术的反驳而不是认可,导致低效推进。 大家应该都听过第一印象效应,指交往双方形成的第一次印象对今后交往关系的影响。产品经理如果能在第一次和技术对接的过程里,表现出逻辑严密和用例细致,那么一个"靠谱"的首次印象就会给你贴上。在往后的多次对接中,再不断巩固这样的"靠谱"印象,自然而然后续的对接会非常顺利,而且会在技术形成一种隐性的威信感。 但反之,一旦产给技术的印象总是遗漏CASE,需求说不清楚的话,一个"不靠谱"的标签就会长时间跟着你,往后要撕掉就更难。 今天就PRD遗漏这个话题,为大家总结了3个技巧,希望对大家有帮助。 一、做好功能关联性,避免功能模块缺失 功能模块的影响点一定是要全面考虑到的,绝对不能遗漏!遗漏的严重后果有2个: 本次评审基本白瞎,产品技术测试UI的时间都会被浪费。 遗漏的功能模块无法短时间讨论出结果,只能是重新梳理重新评审,项目推进一定会delay。 建议产品经理把自己负责的产品做一份功能模块关系(mind脑图或者axure原型图都可以),尤其是新手产品经理强烈推荐做一份,这样会很大程度规避这个问题。 电商购物车的功能模块关系示例: (购物车管理和下单部分留给读者朋友自己补充) 在设计类似的模块关系图时,有几个点需要大家注意: 1. 在组织结构时,一开始不要陷入细节,从大到小进行组织 比如上述有一点是描述"哪些场景是无法加入购物车"的。这个结构往下拆会先到商品原因、账号原因、数量原因和系统原因这样的维度,我们先确定好这几个点有无遗漏,不要一开始就陷入商品没库存不能加、价格变了不能加这样的逻辑里,然后我们再看每个细项包含哪些内容。 2. 从场景出发 保证不遗漏的最好方式就是按场景细化,我们把购物车分为下面3个大场景:1)购物车里商品的进出;2)购物车自身的管理;3)购物车提交订单。 这样的方式可以让我们非常容易的想到是否遗漏场景,就算想不起来,拿出手机打开购物车点一点,也还能想到是否其他场景可以补充。 3. 对照产品,按页面顺序罗列功能点,然后往框架里面丢 这是比较"笨"但是非常有效的办法。我们可以打开购物车页面,记录每个页面有哪些功能点,每个功能点触发后还有哪些功能点。全部记录后,再把每一个功能点往上述的框架里面放。 上述这一步做完,当你接到一个新需求的时候,就可以很快的判断影响点了。比如"在购物车顶部添加用户地址选择"这个功能时,你可以很快的判断,这个功能对商品加入购物车和购物车下单是没有影响的,影响面在于对购物车管理和商品移除购物车这2个地方。 二、汇总通用CASE大全,作为自查清单 相信很多产品经理都有一份自查清单,便于对比自己的方案是否遗漏了某些异常的场景。这里我梳理了一份自查XMIND清单抛砖引玉,大家可以根据自己负责的产品维护补充。 三、做好备选方案的抛弃理由 这块可能有点不好理解,很多产品经理也并不重视,但是如果做的好,在技术面前的形象会更高大一分。 相信大家遇到过这样的场景:当评审时带的A方案时,技术会经常问为什么不用B方案。如果此时我们拿出准备好的数据或者逻辑说明抛弃B的理由,会让大家觉得是有备而来,而不是草草完成任务。 举一个电商卖家后台商品上下架例子,可以有2个方案实现: A:创建完商品保存后,在商品列表有一个单独的【预售设置】 B:创建商品资料的页面同时加上预售时间设置 你希望做的是A方案,当你评审的时候可能技术有会挑战,既然要做预售,为什么不放到一起。如果事先想到这个方案就可以准备好如下应对: 不是所有的商品都需要预售 创建资料是商品资料组做,而预售是采购组做,是2个团队在做。 如此提前准备好可能出现的场景及应对的方案,评审会事半功倍。 当我们负责新的产品时,如果你的交接人有留存类似的文档,可以能够让我们更快的上手。如果有读者经常有需求遗漏的话,强烈建议大家试一试。 我们作为产品经理,在把需求提给技术之前,做好充分的准备,即能帮助自己高效的推进,也能尊重技术团队的时间。 更重要的是,一旦技术认为你靠谱,在后续的对接中会有意想不到的化学反应,技术GG们会主动帮助你思考业务场景,帮助你考虑哪里有遗漏,到了这个阶段是真的配合的很爽。