专栏名称: 开课吧产品100

关于产品经理的这儿都有！

人手必备的产品自查表（建议收藏）

开课吧产品100 · 公众号 · 产品 · 2021-02-10 18:41

正文

产品经理在日常工作当中，由于其岗位的职责范围广，所需要具备的能力也较多，事情也相对较“杂”。

往往在有限的脑容量当中，要完美地做好每一件事，是极其有难度的。

不知道朋友们是否在产品工作当中有没有遇到这类问题：

1、产品文档写完，自己审视后没问题（自认为没问题），评审的时候“舌战群儒”，搞得心力交瘁！

2、产品文档写完，评审也顺利通过，但实际开发当中，还是遇到了需求变更！

3、产品文档写完，需求也顺利开发了，但推向市场，却发现用户不买账？

4、产品文档写完，需求顺利开发，用户也用了一段时间，数据分析的时候发现，效果极差！

看完上述四点，相信每一个产品朋友都会有或多或少这类的问题。（是读心高手阿境了）

所以就需要有个规范，在做产品当中，也需要有份自查表，能够清楚每一篇文档每一个需求是否清晰准确。

做好每一个需求，不管大小，都是非常重要的。而每一点需求也都是每一个产品人最初接触产品岗的工作内容之一，但也是极其重要。

（有一说一，有蛮大部分产品人没办法面面俱到地写好一个需求）

阿境在这篇文章当中所说的产品自查表，主要指的是需求文档的产品自查。深感需求的重要性，于是乎整理了这份产品自查表，望能够给到各位产品朋友一点启发（强烈建议收藏+分享！）

简单来说，文章适用于以下几类朋友：

1、还不明白产品自查的重要性，目前在“野生”地写文档。

2、意识到目前产品需求文档不完善而造成的问题后果，但没有行动，想要有规范的产品自查流程。

3、已经在逐步搭建自身的产品自查表，但却并不完善，想了解其他人的产品自查。

当然，产品自查表并不局限于产品需求自查，还包括产品项目流程自查，产品调研自查等等，阿境对于这些，会简单先概括下，这部分更详细的内容，后续阿境会持续整理，再分享给朋友们。

阿境会以两个方面来阐述产品自查表，第一个是宏观角度的自查，主要指产品整体全局；一个是微观角度的自查，主要针对产品需求文档（这个是重点！）

01
什么是产品自查表？

什么是产品自查表？顾名思义，自查表也就是checklist文档，是一份给到产品岗的朋友来验证自身产品的规划是否合适、妥当的表格。

当然，格式并不局限于表格，仅仅是以表格的形式来展示。

02
产品自查表的作用

讲作用之前，给大家讲个故事：

A：“你细心吗？”

B：“超细心好吧！人送外号[心细如尘厦门吴彦祖]”

A：“好的，写一份需求文档看看”

n分钟，写完后小A审阅.....

A：“你这叫哪门子细心？”

没错，这真是比悲伤更悲伤的故事，当中的小B就是曾经的阿境。（不堪回首）

许多人自认为自己做产品的合格及细心，仅仅局限于“自认为”而已。

产品经理是一个比较吃经验的岗位（当然，也并不是年限越多越厉害，因人而异）；这里所指的经验主要是针对于产品的定义及对细节的执行程度。

年轻的产品经理往往拿到一个需求洋洋洒洒地敲打键盘，毫无考虑；而有经验的产品经理则是经过深思熟虑之后再开始进展。

什么是差距，这就是差距！

话说回来，产品自查表表面上是一张表，一个导图，但实际上是一名产品经理对于细节的把控程度，一名好的产品经理脑子里面已经有一份自身的产品自查表。

在产品想法还没完成之前，它能够帮助产品经理思考需求的可行性及必要性；在产品正在规划当中，它能够帮助产品经理梳理清楚产品业务及细节；在产品规划后正在落地，它能够帮助产品经理规范进行查缺补漏，复盘思考。

那么，产品自查表有用吗？阿境认为对于大部分产品经理都是有用的，减少与开发的撕X，与老板的争论，思考清楚产品及需求的细节。

认清产品，写好需求实在是太太太太太重要了！（省略N个太）

噢对，一份适合自身的产品自查表能够让你瞬间变专业，工作瞬间变轻松！

所以，阿境姑且称为这份产品自查表为“让你瞬间变专业工作瞬间变轻松的产品自查表”。（别问，问就是标题瞎取的）

03
产品自查表内容

在产品自查表内容部分，阿境分为两部分，一是产品整体自查，是站在宏观角度来思考产品，主要适用在产品想法的阶段；二是产品需求文档自查，是站在微观角度上，思考一份文档是否严谨、细节流程是否得当，主要适用在产品规划中及规划后。

1、产品整体自查

对于产品整体自查，主要考虑的是产品的市场可行性、需求可拓展性等因素。是以一个宏观的角度来思考产品本身。

由于本文着重描述的是产品需求文档的自查，故该部分仅简单讲述下。

1、产品的受众人群是谁？

2、产品的定位是什么？

3、产品的核心功能是什么？

4、产品与其他竞品的核心竞争点？

5、产品是否满足了各个场景下用户的需求？

6、在做需求之前，是否有进行需求调研（包括竞品分析）？

7、在做需求之前，是否了解需求包含功能所涉及的业务？

8、在做需求之前，是否了解需求包含功能所涉及的历史逻辑？

9、产品要完成的目标是什么？

......

整体自查更多的是在产品想法诞生的时候来进行自查，只有想清楚了大方向是否正确，才不会造成“南辕北辙”。

2、产品需求文档自查

产品需求文档的自查部分，从第1点到10点更多的也是站在文档的宏观部分，而第11到第23点则是针对于需求当中的细节规范自查，涉及到产品的功能模块，例如文案、数据、弹窗、轮播图、图片等等。

1）需求阶段

在需求阶段，通常会出现的问题是“你认为你想清楚了需求的场景、对用户侧的作用、对产品的影响等”，但其实没有深入全面，最后导致需求做出来了，没人用亦或者是用了效果不好的情况发生，由此可见，深入思考需求是极其重要的。

是谁在什么样的场景下产生的什么诉求，希望用什么方法解决什么问题？
是否需要进一步调研相关用户/需求提出方，是否需要数据佐证？
是否符合当前核心业务场景、是否符合用户画像和用户故事？
是否存在类似竞品，是否完成竞品分析？
当前方案是否是同类场景下的共性诉求？
对核心用户的影响程度，尽可能量化。
对核心业务的贡献程度，尽可能量化。
当前技术是否可以支持
当前业务是否可以支持
是否存在关联功能的改造点？
是否完整梳理当前规划内容下线后的影响点？
是否已预估业务高峰数据爆发量级，及其处理措施？
是否已计划好功能上线后的验证方法？
是否引发诸如骚扰、欺诈等安全隐患？
是否存在负面舆情风险？
是否存在法律及合规风险？
用户覆盖度
使用频率
对核心场景的影响
实际收益的高低
对KPI的影响
实现难度的高低
产品成长时机

2）整体框架设计阶段

在整体框架设计的阶段，更多的是站在一个全局的角度，可以理解为树木的枝干，通过这些用户能够清晰地感知到产品的清晰度及易用性。

设计时是否结合了用户画像、用户习惯、业务场景等因素。
架构层次是否清晰，是否足够扁平，是否容易能使用户理解。
所有信息均需要进行重要级评定，以决定在界面和功能中的重要程度。
信息分类是否合理，一定要“高内聚，低耦合”。
架构拓展性是否足够大，后续对信息模块进行增删改查时，是否容易施行。

3）流程设计阶段

产品流程主要指的是业务流程部分，整体产品业务是重中之重，了解业务后再了解产品。拆分现有业务流程，持续优化它，排除不合理的流程走向，同时通过业务流程也能够探索现有问题。

流程设计是否结合了用户画像、用户习惯、业务场景、竞品等因素。
主干流程是否最简化，是否覆盖了足够多的场景。
是否有特殊流程（分支流程、逆向流程）
是否有异常流程
是否归纳出所有的操作节点、数据交互点。
操作节点是否足够精简易理解。
是否考虑了操作节点的容错性（二次确认、撤销操作）
数据交互点是否依赖其它系统。
特殊、异常流程是否需要增加切换流程的引导，避免流程断头。
相关流程的用户体验路径是否一致
各图形形状/字号统一。重点内容可特殊标识，关键节点增加注释说明
流程均以开始框开始，以结束框结束，避免断头风险。
流程图从左到右、从上到下排列。
流程图从左到右、从上到下排列。
流程完成后是否进行了场景验证，是否符合用户预期。

4）需求文档设计阶段

需求文档设计阶段时，是整体文档的自查，关于流程、文档文案、名词、场景、信息等大方向进行的把控。

完整流程是否可形成闭环？
逆向功能流程是否可逆，如果逆向操作，是否考虑对应的机制：比如退款、退货操作
各个步骤可能出现预期外的情况。
歧义需求文档的语法、功能文案、名词是否易懂，是否存在歧义。
兼容是否存在兼容问题：不同业务人员对功能都能接受吗？各个系统之间兼容吗？新旧功能的兼容吗（比如历史数据要不要初始化）？
备用是否有备用方案，次级选项。比如当正常流程无法传输的时候，是否可以用导入的机制救急。业务高峰的系统，是否有降级处理逻辑。
穷尽业务场景和可能原因是否穷举完毕。
脱敏是否存在敏感信息，是否有脱敏机制。
文案描述切记要精确，“可能”、“也许”、“大概”等模糊性词语避免出现。
不是本需求的功能避免加入文档中，给开发、测试人员造成干扰

5）特殊因素

特殊因素主要列举的是一些客观因素（例如手机系统、账号、网络等外在情况）的问题，由于其大部分脱离产品本身功能，是一个辅助的作用，容易被产品朋友忽略。

是否存在不同登录状态下展示内容或操作有不同（登录、未登录、帐号异常状态）
是否存在不同用户状态下展示内容或操作有不同（非会员、不同等级的会员，特殊付费会员等）
是否考虑多账号切换，切换时，本地缓存数据是否需要同步清空。
是否允许多终端同时登录一帐号，若允许，操作同一数据时是否产生冲突。
WiFi网络、移动网络（4G）
集团局域网、公共网络
连接超时，多久为超时
网络显示什么内容？是否给予用户友好引导检查网络或重试按钮。
网络变化从WiFi到4G网络环境时是否需要提示
服务器出问题返回数据失败时，是否给予用户友好提示或重试按钮
横竖屏是否有横屏展示的需要，如不需要需要锁定竖屏
分辨率高低：分辨率情况下是否会有适配问题，是否备注清楚。
SD卡Android手机，没有SD卡、SD卡存储已满、存储位置等情况是否考虑并备注。
硬件不同，手机物理按键的不同衍生不同操作。
系统版本的不同是否同步支持，iOS、Android、Windows及其不同版本
定位提示是否打开定位
相机提示是否打开相机
闪光灯提示是否调用闪光灯
蓝牙提示是否打开蓝牙
设备数据是否需要调用，步数、心率等，主要在iOS设备中。
夜间\日间模式是否考虑光线较暗的场景。
编辑模式下出现意外情况是否提示保存或自动保存已填信息。
无痕模式：不记录用户所有操作信息（实际是否记录根据数据需求来看）
无图模式：节约用户流量，加快页面加载速度。

6）账号状态及用户权限自查

不同账号状态说明：登录状态、非登录状态不同情况是否说明完整？
不同用户等级和权限说明，不同等级用户有哪些权限？在页面展示上有什么不同？
不同账号状态切换时是否有特殊展示？
不同账号状态切换时是否有特殊展示？
是否考虑多账号切换问题？
是否支持第三方账号登录？

7）设备相关

是否支持横竖屏操作；检查不同屏幕效果
不同分辨率下的适配问题，是否有空白溢出变形
操作过程是否有卡顿

8）特殊场景

网络加载慢情况下无图显示效果
考虑夜间模式下的展示效果
区分编辑模式下可变更内容的权限

9）全局

修改页面时，考虑在系统中其余地方是否也有相同的业务，是否需要修改？
全局控件样式是否具有一致性
全局控件交互行为是否具有一致性
是否周全地考虑了所有操作成功的反馈。
是否周全地考虑了所有操作失败的反馈。
控件触发的提示类型是否恰当（小红点、Toast、弹窗）

10）版本发布自查

确认完需求之后，要告知运营同事们有哪些新功能，何时能交付版本，这样方便运营童鞋们也好对应的落实相关的运营工作。如果运营的部分/全部工作也是PM干的话，那么自己心里要有数；
该版本开始就要落实是否要做新的应用商店图、新的欢迎页、新的功能引导页，并且相应的安排人手。在上线前3天最好再确认一下，万一有漏，也有时间能再补；注意：针对这三个东西，都有相应的文案要出；
确认这个项目中没有完成的需求或者中途协商修改的需求，都已经被记录下来，并且最好开始确认没有解决的需求怎么办，修改的需求怎么办的问题；
确认该新功能的埋点列表是否给出；
确认新功能带来的相关新数据的查看地方以及方法，这里会涉及一些常用的统计平台；
确认新功能带来的后台新的管理模块使用或者从某个地方切换到另一个地方的使用方法的切换，培训过相关人员，并且已经正确掌握；
确认提交给应用商店的新功能文案是否有出；
确认最终提交给应用商店的应用商店图、新功能介绍更新了；
确认各个渠道中的最新版确实为最新版本；
每个版本都要观察上个版本的埋点数据是否正常，及时发现是否打错点，进行及时修正，避免数据浪费；