程沛权
程沛权

简单的六个步骤 让你写出技术爱看的需求文档

作者:程沛权2021-05-05

本文最后更新于 1019 天前,部分内容可能不适合当前所有情况,仅供参考。

演讲稿的在线 PPT 版本可以戳 这里

五一啊五一,虽然很想去迷笛音乐节,但经不住太懒,加上最近太忙,实在想休息,所以还是宅家吹空调,三只猫陪着码字写东西也很舒服。也幸亏没出门,广深大暴雨,朋友圈还看着各种大塞车,还是过段日子再用年假来错峰出行吧哈哈哈哈。

这一篇其实大概在三月份的时候就说想写了,四月份清明假期因为赶项目,结果也没写出来,五一终于可以好好码一码字,终于不用再拖到儿童节了。

拖稿狂魔说的就是我了

之前在 UC 工作,后来又到网易搬砖,来来往往的接触过一些的阿里和网易的产品需求,从校招新人到产品大佬,不同级别的需求看的多了,也算是总结到一些需求设计方面的技巧。

由于时不时还是会接到一些比较随意的文档(很多人觉得原型不就是画几个框?),加上身边的一些朋友也想了解,所以总结了此文,主要面向新手产品同学,以及偶尔可能会提需求的运营同学等等对于需求梳理还不是特别熟悉的对象阅读。

好了,下面回归正文!!!

前言

在互联网的工作日常中,“提需求” 应该是大部分同学在工作中最不可避免的三个字,不论你在哪个岗位,总会涉及到五花八门的业务需求,哪怕小到 A 同学找你导个报表、B 同学找你出个文案,这些也是 “需求” 。

虽然大部分情况下,各个业务线都配备有产品经理这个岗位来梳理需求,但并不是所有需求都是来自于产品经理本身。提出需求的,可能是运营同学,可能是商务同学、营销同学,有些时候也可能是技术与技术之间的需求,或者是来自产品用户的反馈,以及你的老板传达下来的想法等等。

前些年,在互联网圈子里有句话很流行,叫 “人人都是产品经理” (源自一本产品书籍的书名),为什么这句话会流行起来?因为只要我们把这句话换个方式表达,本质上就是 “人人都是需求方” 。

作为一个前端工程师,这几年对接过的需求里,有的文档清晰、逻辑合理、交互人性化,有的看半天不知所云,而接触过的这些需求,又代表了大部分常见的界面化需求,其实提需求啊,还真是一门学问。

这篇文章会围绕工作中 “提需求” 这个常见的业务场景,聊一聊那些容易出现的问题,以及解决这些问题的窍门。

为什么要讲这个话题

相信大部分提过需求的同学都会遇到一个问题就是:

为什么我提的需求,最后技术那边做出来的效果,总是和我心里想要的不一样?

不止是你们,包括我自己在刚工作的时候,也经历过这种纳闷,为什么呢?

别急,先上一个段子:

产品经理:我想要这边右划可以出菜单,然后还需要一个闪烁的动画,这边这个 Tab 可以拉下来,你听懂了吧?

设计师:别废话了,把你要抄的那个产品拿给我看一下。

这个段子应该大家都有看过,有时候段子它不仅仅就是个段子,还真的是工作生活的体现。

回到刚刚这个问题,很长时间没有告诉我为什么,后来工作久了,慢慢发现,很多情况下,实现效果与需求想法不一致,并不是因为实现不出来,而是因为人和人交流之间最常见的两个情况导致的。

也就是所谓的 —— “表达不清” 与 “理解偏差”

形象一点表达就是:

需求方想的: ████████████████████ - 100%

文档表达的: ████████████████░░░░ - 80%

技术理解的: ████████████░░░░░░░░ - 60%

这个情况在生活中其实很常见,经常看很多梗或者搞笑视频,那种传话越传越离谱,其实也是类似这个情况,表达的过程中,信息是会有偏差和遗漏的。

所以,上面那个问题,在大部分情况下,都应该转换为:

为什么我提的需求,

>最后技术那边做出来的效果 心里想要的效果,

总是 和我心里想要的 和我表达出来的不一样?

那么作为一个需求方,我们应该怎么去表达,让我们的需求先变得更靠谱呢?

常用的六步法则

一个靠谱的需求,通常来说需要经历六个步骤:

  1. 需求分析

  2. 功能梳理

  3. 流程设计

  4. 绘制框架

  5. 完善细节

  6. 复读文档

所谓的 “原型就是画几个框” ,其实只是设计过程中的一个小环节而已。需求写得完善,双方才能有统一的理解;需求完成时,也有统一的验收标准。

我们来看看每个步骤里面,都有哪些注意事项和处理技巧。

一、需求分析

很多时候我们手里的需求,不一定都是由自己发起的,可能是来自老板的需求,可能是来自合作伙伴的需求,最终再由自己去统一对接设计 / 技术或者其他岗位,面对形形色色的需求,我们需要先进行一波需求分析。

需求分析,其实就是拆解需求目的:

常见的拆解方向:

—— 原始需求是什么?

—— 需求来源是否可靠?

—— 参考数据是否有权威性?

—— 需求的价值点在哪里?

—— 需求的成本?

—— 其他…

比如我们来看看下面几个需求案例,他们都存在哪些问题?

  • 你做了个投稿活动,玩家反馈投稿编辑器不好用,希望优化。
  • 老板让你五一做个活动提升一下 APP 的数据。
  • 产品要求你的活动页面要兼容 IE 8 才能上线。
  • 4 月 20 号了才想到忘记策划五一活动页面,赶紧提个需求。

好家伙,一个个的看起来有模有样,马上出解决方案!但是,千万不要急!拿到类似的反馈之后,我们还是需要先做一波分析,才能知道这些是不是真正的需求,有没有实现的价值:

需求场景需求分析问题所在
你做了个投稿活动,玩家反馈投稿编辑器不好用,希望优化。不好用是指什么功能不好用?是不支持 Markdown 语法,还是不支持插入视频?“不好用” 这个需求点缺少明确的达成目标,不是原始需求
老板让你五一做个活动提升一下 APP 的数据。老板的期待目标是指什么数据?日活?内容发布量?用户互动量?缺少核心价值点,容易费力不讨好
产品要求你的活动页面要兼容 IE 8 才能上线。2021 年了有多少 IE 8 用户?自家的 IE 用户占比有没有 5% ?缺乏有权威性的数据支撑,也是容易费力不讨好
4 月 20 号了才想到忘记策划五一活动页面,赶紧提个需求。这么点时间,不用设计?不用走测试?一趟流程走下来直接凉凉了突发情况,需要考虑是否有备用方案,能否使用现成的接口 / 后台 / 模板,节约开发资源,避免影响上线计划,所谓的有备无患。

如果没有需求分析,很多时候要浪费很多时间,多走很多弯路。

二、功能梳理

功能梳理是为了让各个页面、各个模块的作用不被遗漏,也尽量减少功能重合。这个步骤应该很多同学都知道要做,但是在我日常对接的过程中,也发现很多同学只是单纯的列功能,一个一个的列出来,这样其实是很容易遗漏掉需要的功能点。

建议使用 “金字塔分析法” 来梳理我们的功能,最后生成一个产品的架构图。

金字塔分析法

如上图,金字塔分析法其实很简单:

  1. 先归类你的用户群体,比如一个玩家故事征集活动,那么用户群体就有投稿者(内容生产者)以及读者(内容消费者)。

  2. 再针对不同的用户群体,去划分他们涉及到的大模块,比如投稿者,那他需要涉及的就有 “发布模块(编辑器)、推荐曝光、互动” 等等。

  3. 最后再围绕每个模块,拆分里面需要用到的功能点,并根据实际情况做取舍,比如投稿者的发布模块,是否需要支持音频上传、视频上传、草稿箱等功能。

最终可以输出如下的一个需求架构图(我这里就直接 Markdown 编辑了,你可以用更专业的软件去画):

# 以故事征集活动为例:

需求
│
├───内容生产者
│    │
│    ├───产出故事内容
│    │   ├───富文本编辑
│    │   ├───图片上传
│    │   ├───视频上传
│    │   ├───草稿箱
│    │   └───发布预览
│    │
│    ├───推荐和曝光
│    │   ├───首页推荐位
│    │   ├───内容分发机制
│    │   └───分享功能
│    │
│    └───粉丝互动
│        ├───作品被点赞
│        ├───作品被评论
│        └───作品被打赏
│
└───内容消费者
     │
     ├───看到内容
     │    ├───内容分发机制推荐
     │    ├───首页推荐位推荐
     │    └───其他用户分享
     │
     └───作者互动
         ├───点赞作品
         ├───评论作品
         └───打赏作品

三、流程设计

流程设计也就是所谓的画流程图,是为了避免在开发的时候才发现产品需求的逻辑不对,或者有什么被遗漏的流程。

在这里面,又分为 “正常流程” 和 “异常流程” 。

正常流程

正常流程是指:用户在没有遇到任何阻碍的情况下,顺利的完成某个功能的使用,比如登录:

“输入账号” ✔ ——> “输入密码” ✔ ——> “点登录” ✔ ——> “登录成功” ✔

这是一个正常流程,每个环节的正常流程只有一个,一步一步走下去,直到目标达成。

异常流程

异常流程是指:用户在使用功能的过程中,遇到某些意外情况,导致正常流程被中断,还是拿登录环节举例:

“输入账号” ✔ ——> “输入密码” ✔ ——> “点登录” ✔ ——> “密码错误” ❌

这就是登录环节里面的一个异常流程,但在实际业务场景里,每个环节的异常流程经常会有很多个,需要尽量多的去考虑到异常流程和对应的解决方案,避免打断用户的行为而导致用户离开。

设计技巧

我们在设计流程的时候,第一步需要先把完全通畅的正常流程画出来,确保在无任何意外的情况下,你设计的流程能够跑通;再处理可能出现的异常流程,在某个环节不符合要求的时候,做什么处理。

针对异常流程,我们需要在每个可能出现意外的环节,设计对应的处理方案,来给用户最好的体验,及时引导他们回到正常流程中。

知乎提问的时候就考虑了多个异常流程,并进行了正确引导

四、绘制框架

框架是为了让你的想法可以具象化的表达出来,减少在沟通过程中的理解偏差。比如本文最开始的段子,与其形容半天还不知所云,不如简单明了的出示你画好的框架。

把冗长的文字转化为简明的图形表达

框架不是设计稿,不需要做的非常精美,你可以像小时候搭积木一样,用各种点、线、方块拼到一起,把你心中想要的效果,用图形界面表达出来就可以。目前市面上主流的网站、APP 设计,都可以采用积木大法来绘制你的框架。

积木大法能应付常见的布局排版

画框架的工具有很多种,推荐使用专门做原型的 Axure,也可以用你擅长的 Excel 、PPT 来画,工具只是辅助,关键是你的表达要 OK 。

五、完善细节

光有框架没有说明也是不行的,图文搭配,才是最佳的表达。这里的细节,主要分为三类:

需求的基本信息

通常拿到需求都是先通过基本信息来了解这个需求是干嘛的,这里我列了一些常用到的项,可以参考取舍。

信息项用途
需求目的告知团队为什么要做这个需求,开评审会的时候经常要了解需求价值,所谓的排期优先级,往往是这个决定的
合作流程如果设计、前端、服务端不是同一个团队的,像跨部门合作的,特别需要把合作流程写清楚
跟进人需求负责人必写,各个环节有问题方便找负责人确认,其他岗位的负责人如果已确定(如由谁主导设计、由谁主导开发),也可以更新上来
迭代记录大项目,需要进行不断迭代的,迭代记录一定要做好
架构图就是 功能梳理 这部分提到的产品架构图,方便各岗位更直观的了解
流程图就是 流程设计 这部分提到的流程图,简单项目可以直接列出来,如果是复杂项目,可以分摊到各个模块里去写

在实际的文档梳理过程中,你可以像这样列个表格来清晰的展示每一项信息的内容。

模块的具体信息

上面说的是整个需求的一些全局信息,这一部分说的是具体到某个模块的功能信息,这个环节你可以充分考虑他们在可见范围外的一些细节,什么是可见范围外?我举几个例子。

前后条件考虑

比如,一个内容发布按钮,如果你只是完成一个内容发布,那其实不必单独标记说明 “这个按钮点了可以发布” ,这个就没有意义,因为本来就是执行发布行为,那么需要说明的是哪些东西呢?是可能会产生意见分歧的地方。

从按下发布按钮开始,到成功发布出去,在这个过程之间,需不需要对内容进行审核?也就是很常见的先审后发,还是先发后审,还是免审核?

然后完成发布后,从编辑器离开,是跳转到首页,还是作品列表页,还是作品详情页?

像这些就是需要考虑的前后条件了,有很多种选择,每个人都有每个人的想法,如果你有比较明确的方案,就需要把这个细节写清楚。

登录有效期

几时要让 Token 失效,登录失效后是切换登录页面让用户重新登录,还是可以对活跃用户提供 Token 刷新机制,自动延长有效期等等…

是否需要做黑白名单限制

比如:IP 封禁、账号封禁等一些违规处罚,敏感操作的模板只能在公司 IP 登录

类似以上都是有意义的标注,除了功能信息标注外,还可以是一些交互方式的说明(参考 XXX 应用的一些交互行为),也可以是一些数据来源的标注(比如投票功能旁边,就可以标注每天的投票资格如何获取)。

其他的辅助信息

辅助信息通常是脱离于需求功能之外的,但又不能被遗漏的一些补充,比如:

数据埋点

目前国内主流都是用的百度统计、CNZZ 统计等统计平台,可以记录网站、APP 用户的使用情况和行为分析,一般需求方不主动提及的话,开发是不会主动帮你埋点的,因为不知道你需要什么数据,你要的东西,你要主动写出来。

异常报警

一些敏感操作、宕机之类的异常情况,是否需要通过 Email 、短信之类的报警通知。

适配程度

比如网页的浏览器适配范围,APP 像安卓兼容到哪个版本之类的,有特殊需求也可以做出说明(通常对于非主流的低版本有要求才需要说)。

诸如以上,请根据自己的业务情况评估是否需要添加辅助信息说明。

六、复读文档

就像开发做完需求也不会直接上线,需要走几轮测试流程,复读文档就相当于自己对自己的需求文档的一个“测试”,主要的作用体现在两个方面:“查漏补缺” 和 “精益求精” 。

查漏补缺

复读文档的作用,一个是查漏补缺,减少理解偏差。

查漏补缺,把遗漏的细节补充起来

有些地方,同样的功能,命名不一致,或者功能描述不清晰等等,都会导致在对接的过程中理解产生偏差,通常可以考虑这几个方面的检查。

检查关键词是否清晰一致

比如一个内容聚合列表,是叫 “话题” ,还是叫 “频道” ,还是叫 “标签” ,收藏功能是叫 “我的收藏” 还是 “我的喜欢”,像这些问题在进行二次改版的产品需求里尤为常见,一些功能被重命名后,叫法开始变得不统一。

请切记,在产品里面,同一个事物,它的叫法应该是保持清晰一致的。

是用代词还是专业名词

就像 “会员” 一词,可以用在所有付费相关的功能上,但是如果你还要进一步划分会员等级,那么有些功能就必须明确到 “白银会员” 、“黄金会员” 这样更细粒度的专业名词,而不能用比较含糊的 “会员” 代词。

逻辑、流程是否有误

检查是否有冲突、有遗漏的情况,比如去年我在做一款 APP 内嵌需求的时候,点击页面上的关闭按钮,可以调用 APP 的内置命令来唤起一个原生的二次确认界面,确认后才能够退出,避免用户误操作,但测试的时候才无意中发现,通过 APP 的右划后退,其实是可以绕过这个判断,直接就退出去了,这就是一个被遗漏的情况。

描述上会不会太臃肿

描述臃肿是新人比较常犯的一个问题,担心讲不清楚,所以说了一大堆,但可能又因为写的太啰里啰唆导致更看不懂,更可能导致因为每次都一大段一大段描述,最后被习惯性忽略导致一些细节反而没有被注意。

就像一个 “短信 + 验证码” 登录的功能,没有必要把 “用户先输入手机号,校验手机号格式是否正确,然后点击下发验证码的按钮,接收验证码后,把验证码输入到验证码框里,点登录,校验验证码是否合法,合法的话注册成功” 之类的完成操作都写进去,因为这些都是常识性的。

你只需要关注 “发送验证码后,需要把获取验证码的按钮置灰,并显示 60s 倒计时” ,“验证码校验失败时,清除倒计时” 这样的一些特殊描述上。

是否会偏离需求目的

这个倒不是说自己的设计目的偏离了,更多是投产后,用户的行为,是否会与自己的需求目的偏离。

比如你做一个晒年味短视频的活动页面,主要目的是提升短视频的发布量,活跃 APP 的内容氛围,那么你在设计需求页面的时候,就应该多考虑一些降低参与门槛的问题,甚至可能把新手教程也考虑作为需求的一部分考虑进去,否则投产后,可能因为要求太复杂,参与门槛太高,最后没什么人参与。

精益求精

复读文档另外一个作用是精益求精,很多时候最佳实践不是一次性就能想到,那么就可以在复读文档的时候,检查是否可以再作优化。

精益求精,不断完善你的需求,增强体验

同样的,可以在这几个维度进行精益求精:

参考成熟成功案例

虽然很容易陷入 “你又抄了什么功能” 这样的圈子里,但不得不说,大型产品很多方案和决定都是经得起大量用户考验的,多了解下同类型产品的选择,再加以优化,是个比较稳妥的方法(毕竟你要为 KPI 负责啊)。

参考竞品的优点

版权相关的红线,你就不要去碰了,但是一些可以提升用户体验,只是你之前没有考虑到的,是不是就可以加进去。

学会做减法

小孩子才做选择,大人全都要,没毛病,但是落实到产品需求上,与之对应的有时间和成本要考虑,学会做减法也是一项很必备的技能。

减法不一定就是直接砍掉不做,而是可能 v1.0 先不做,只做主要、核心的功能,等 v1.1 、v1.2 等小版本再慢慢做迭代进去。

考虑复用性,可持续发展

诸如一些活动页面,很多时候换个皮肤就可以复用(像抽奖转盘、投票页面等等),偶尔考虑几个可以复用的需求,可以作为特殊节点的应急需求上线。

做好备选方案,以防万一

最常见的情况就是,你想的天花乱坠,最后开发说做不了,或者需要比较长的时间来完成,而你的时间不充足,这种情况下,你是否可以立即给到一个备选的方案,避免影响上线计划。

总结

再回顾一下,完成一个靠谱的需求所经历的六个步骤:需求分析 > 功能梳理 > 流程设计 > 绘制框架 > 完善细节 > 复读文档。

当然,实际情况中,不是每个需求都一定要每个步骤都经历,比如一些数据类的需求,那就没有绘制框架这种环节了,可以根据实际情况处理,其实本文主要的目的,是希望大家有这么一个思维,去对待你所跟进的每一个需求。

后记

第一次让我有意识的去了解产品设计的大佬,应该就是在 UC 的时候,前 PP 助手产品总监田哥,至今还记得当初借《人人都是产品经理》那本书给我看的时候跟我说,多了解点专业之外的知识,最终还是可以运用到自己的专业上,这么多年过来,确实非常正确。

后来几年一直到现在,又跟唯品会的 UX 婷姐,网易的 UI 猪猪,又从交互体验和设计体验方面学到了不少跨界知识,感恩!!!