写 PRD 时的思考自查表

2017-08-16 10:12:00

在本文作者看来，PRD像解分情况讨论题，最后得分早在你决定分几种情况时已经落定，这篇文章将重点讨论解题思路。

PRD，产品需求文档，像厨艺切磋里的终极菜单的──蛋炒饭，人人会写的PRD其实藏着很多智慧、并时时暴露着你的思维死角。正儿八经当了一年的产品，写PRD的心态翻天覆地，从当做写文档、表格要漂亮、原型要精致，到认识到这是项目的基石，项目成员对你的信任度、项目的开发效率、项目最后的成就从发出PRD那一刻就开始发生着微妙的变化。
我现在希望，我们之间最质朴的交流，是我的PRD能回答你。

解题基本功

PRD的一切都围绕着需求：需求从哪里来、怎么落地这个需求、怎么衡量需求的落地效果。有PM笑称产品的日常就是在解应用题，只是“水池的进水速度、出水速度”这样的条件没有写在题干里。PRD相当于你交出的考卷，解题背景、解题思路和最后得分一目了然。

我说PRD像解分情况讨论题，最后得分早在你决定分几种情况时已经落定，这篇文章将重点讨论解题思路。根据我的踩坑经验，考虑缺失的苦果或早或晚会猝不及防的出现，让你狼狈一阵子。现在学乖的我至少会考虑三个大方面的需求：

功能需求。需要增加产品支持的使用场景，例如微信增加“搜一搜”，来让用户在微信中获取更多的内容、再次重打“用完即走”这句话的脸。这个很好理解，加功能或者优化已有功能以丰富应用场景，是大多数产品的日常，尤其在创业公司。
性能需求。自己狠狠踩过了调用接口超时的坑，才开始关注功能相关的性能问题。当时做需求中包含一个触发数据同步的功能，我只简单说明了同步流程。到用外网数据库测试时才发现，当数据量较大时，调用同步接口会超时，而不得不临时改变策略。类似问题还出现在批量上传没有考虑数量上限、下载不考虑是否需要异步处理、没考虑过图像清晰度和加载时间的平衡、完全不考虑浏览器兼容等。尽管有经验的研发会自己处理性能问题，有经验的产品应该在研发做技术设计之前抛出自己对性能的要求。
安全需求。看别人狠狠踩过了没有反爬虫策略的坑，才开始关注安全性问题。除了反爬虫外，有些功能需要进行敏感词屏蔽（同步过滤和异步召回）、防刷单机制等。安全需求暂时涉猎较少，不展开描述。

十四字思考自查表

画一张脑图，主题叫做“落地需求”，第一级标题划定为“功能需求”、“性能需求”、“安全需求”，子标题是什么呢？换句话说，就是该怎么思考落地方案呢？

高人传我七字箴言“增查改删显算传”。结合本人的经验，狗尾续貂为十四字：

“增查改删显算传，异常情况也要盘。”

“增查改删显算传”的每个字的扩展，可以用“ 5W2H ”来帮助思维延伸。问问自己这个操作是否必要（why）、操作的权限如何分配（who）、操作的时效限制（when）、交互邀请和提示怎么做（where）、可操作内容是什么（what）、操作的主流程和异常情况是什么（how）、整个操作要多少步骤（how much）。下面具体说说：

“ 增 ”我理解为创建过程。创建的入口在哪？创建的条件是什么？有什么输入参数，必填吗？
“ 查 ”我理解为查找。是否支持查找？以什么方式查找，搜索、标签or排序？全局搜索or类目下搜索？精确搜索or模糊搜索？什么情况下搜索屏蔽结果？搜索结果可以进行什么操作？如何退出搜索？静态标签or动态标签？
“ 改 ”我理解为编辑。编辑的入口在哪？编辑的条件是什么？什么参数支持编辑？
“ 删 ”我理解为删除。删除的对象是什么？删除的条件是什么？怎么删除？是否可以撤回？需不需要回收站？
“ 显 ”我理解为显示。显示的内容是什么？显示内容的优先级的逻辑是什么？视觉元素显示的优先级是什么？层级关系是什么？
“ 算 ”我理解为数学相关。增查改删显传的数值限制是多少？有什么计算或数量变化规则？用户需要的内容数量是多少？是否需要显示总数？
“ 传 ”我理解为传输，包括转发、分享、下载等。这里需要思考传输是否需要处理状态。
“ 异 ”我理解为异常情况。小到增查改删各个步骤的可能出现的错误情况、大到预估服务器的最大并发，产品能感知到自己解决方案的风险越多、对异常情况准备越充分，就是省钱省力。对异常情况的预知能力，一定程度上反映了产品的经验值。