认识达内从这里开始

我们都知道，企业在进行用户需求分析之前都会进行不同类型的需求收集和调查问卷，同样的，我们在进行产品设计和软件开发的时候也需要通过需求文档来确定基本框架。

今天，我们就一起来学习一下，一个完整的需求文档都包含了哪些内容，我们应该从哪些方面来完善我们的需求文档。下面就开始今天的主要内容吧。

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

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

功能需求。需要增加产品支持的使用场景，例如微信增加“搜一搜”，来让用户在微信中获取更多的内容、再次重打“用完即走”这句话的脸。这个很好理解，加功能或者优化已有功能以丰富应用场景，是大多数产品的日常，尤其在创业公司。

性能需求。自己狠狠踩过了调用接口超时的坑，才开始关注功能相关的性能问题。当时做需求中包含一个触发数据同步的功能，我只简单说明了同步流程。到用外网数据库测试时才发现，当数据量较大时，调用同步接口会超时，而不得不临时改变策略。类似问题还出现在批量上传没有考虑数量上限、下载不考虑是否需要异步处理、没考虑过图像清晰度和加载时间的平衡、完全不考虑浏览器兼容等。尽管有经验的研发会自己处理性能问题，有经验的产品应该在研发做技术设计之前抛出自己对性能的要求。

安全需求。看别人狠狠踩过了没有反爬虫策略的坑，才开始关注安全性问题。除了反爬虫外，有些功能需要进行敏感词屏蔽(同步过滤和异步召回)、防刷单机制等。安全需求暂时涉猎较少，不展开描述。

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

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

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

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

“增”我理解为创建过程。创建的入口在哪?创建的条件是什么?有什么输入参数，必填吗?

“查”我理解为查找。是否支持查找?以什么方式查找，搜索、标签or排序?全局搜索or类目下搜索?精确搜索or模糊搜索?什么情况下搜索屏蔽结果?搜索结果可以进行什么操作?如何退出搜索?静态标签or动态标签?

“改”我理解为编辑。编辑的入口在哪?编辑的条件是什么?什么参数支持编辑?

“删”我理解为删除。删除的对象是什么?删除的条件是什么?怎么删除?是否可以撤回?需不需要回收站?

“显”我理解为显示。显示的内容是什么?显示内容的优先级的逻辑是什么?视觉元素显示的优先级是什么?层级关系是什么?

“算”我理解为数学相关。增查改删显传的数值限制是多少?有什么计算或数量变化规则?用户需要的内容数量是多少?是否需要显示总数?

“传”我理解为传输，包括转发、分享、下载等。这里需要思考传输是否需要处理状态。

“异”我理解为异常情况。小到增查改删各个步骤的可能出现的错误情况、大到预估服务器的最大并发，产品能感知到自己解决方案的风险越多、对异常情况准备越充分，就是省钱省力。对异常情况的预知能力，一定程度上反映了产品的经验值。

作者： zhihui

【免责声明】本文转载自网络，著作权属原创作者所有。经检索无法确定原创作者，故未标明作者。我们分享此文出于传播更多资讯之目的。如涉著作权事宜请联系小编更正！