写时的思考自查表

　　在本文作者看来，PRD像解分情况讨论题，最后得分早在你决定分几种情况时已经落定，这篇文章将重点讨论解题思路。
　　PRD，产品需求文档，像厨艺切磋里的终极菜单的蛋炒饭，人人会写的PRD其实藏着很多智慧、并时时暴露着你的思维死角。正儿八经当了一年的产品，写PRD的心态翻天覆地，从当做写文档、表格要漂亮、原型要精致，到认识到这是项目的基石，项目成员对你的信任度、项目的开发效率、项目最后的成就从发出PRD那一刻就开始发生着微妙的变化。
　　我现在希望，我们之间最质朴的交流，是我的PRD能回答你。
　　解题基本功
　　PRD的一切都围绕着需求：需求从哪里来、怎么落地这个需求、怎么衡量需求的落地效果。有PM笑称产品的日常就是在解应用题，只是水池的进水速度、出水速度这样的条件没有写在题干里。PRD相当于你交出的考卷，解题背景、解题思路和最后得分一目了然。
　　我说PRD像解分情况讨论题，最后得分早在你决定分几种情况时已经落定，这篇文章将重点讨论解题思路。根据我的踩坑经验，考虑缺失的苦果或早或晚会猝不及防的出现，让你狼狈一阵子。现在学乖的我至少会考虑三个大方面的需求：
　　功能需求。需要增加产品支持的使用场景，例如微信增加搜一搜，来让用户在微信中获取更多的内容、再次重打用完即走这句话的脸。这个很好理解，加功能或者优化已有功能以丰富应用场景，是大多数产品的日常，尤其在创业公司。
　　性能需求。自己狠狠踩过了调用接口超时的坑，才开始关注功能相关的性能问题。当时做需求中包含一个触发数据同步的功能，我只简单说明了同步流程。到用外网数据库测试时才发现，当数据量较大时，调用同步接口会超时，而不得不临时改变策略。类似问题还出现在批量上传没有考虑数量上限、下载不考虑是否需要异步处理、没考虑过图像清晰度和加载时间的平衡、完全不考虑浏览器兼容等。尽管有经验的研发会自己处理性能问题，有经验的产品应该在研发做技术设计之前抛出自己对性能的要求。
　　安全需求。看别人狠狠踩过了没有反爬虫策略的坑，才开始关注安全性问题。除了反爬虫外，有些功能需要进行敏感词屏蔽（同步过滤和异步召回）、防刷单机制等。安全需求暂时涉猎较少，不展开描述。
　　十四字思考自查表
　　画一张脑图，主题叫做落地需求，第一级标题划定为功能需求、性能需求、安全需求，子标题是什么呢？换句话说，就是该怎么思考落地方案呢？
　　高人传我七字箴言增查改删显算传。结合本人的经验，狗尾续貂为十四字：
　　增查改删显算传，异常情况也要盘。
　　增查改删显算传的每个字的扩展，可以用5W2H来帮助思维延伸。问问自己这个操作是否必要（why）、操作的权限如何分配（who）、操作的时效限制（when）、交互邀请和提示怎么做（where）、可操作内容是什么（what）、操作的主流程和异常情况是什么（how）、整个操作要多少步骤（howmuch）。下面具体说说：
　　增我理解为创建过程。创建的入口在哪？创建的条件是什么？有什么输入参数，必填吗？
　　查我理解为查找。是否支持查找？以什么方式查找，搜索、标签or排序？全局搜索or类目下搜索？精确搜索or模糊搜索？什么情况下搜索屏蔽结果？搜索结果可以进行什么操作？如何退出搜索？静态标签or动态标签？
　　改我理解为编辑。编辑的入口在哪？编辑的条件是什么？什么参数支持编辑？
　　删我理解为删除。删除的对象是什么？删除的条件是什么？怎么删除？是否可以撤回？需不需要回收站？
　　显我理解为显示。显示的内容是什么？显示内容的优先级的逻辑是什么？视觉元素显示的优先级是什么？层级关系是什么？
　　算我理解为数学相关。增查改删显传的数值限制是多少？有什么计算或数量变化规则？用户需要的内容数量是多少？是否需要显示总数？
　　传我理解为传输，包括转发、分享、下载等。这里需要思考传输是否需要处理状态。
　　异我理解为异常情况。小到增查改删各个步骤的可能出现的错误情况、大到预估服务器的最大并发，产品能感知到自己解决方案的风险越多、对异常情况准备越充分，就是省钱省力。对异常情况的预知能力，一定程度上反映了产品的经验值。
　　勤于修炼，方得始终
　　我想面向对象和面向过程这两种建模方式不止适用于编程，也很适用于产品的日常解题。这篇文章中重点说的是一种面向过程的思考方式，小、具体、细致，对产品的抽象思维能力没有提出太多的要求，非常适合用来锻炼产品基本功，以达成思维层级一的目标：完整的闭环。
　　最近做的一个后台功能，主流程就是用户上传CAD文件、完成必须入参填写，完成上传的一个过程。用这个例子来带大家走一遍十四字箴言的思考流程。
　　1。增
　　（1）创建条件
　　完成素材上传的需要的必须参数有哪些（文件、名称、尺寸、材质等）？
　　用户上传的CAD文件内容的要求是什么？
　　名称长度、字符的要求是什么？
　　尺寸范围是什么？
　　支持添加的材质是什么？
　　（2）异常情况
　　不符合要求的文件处理方式是什么？
　　超过长度的名称怎么处理？
　　超过尺寸范围怎么办？
　　2。查
　　查询方式：
　　添加材质时，如何快速查找到需要的素材？
　　搜索支持的字符是哪几种？
　　模糊搜索还是精确搜索？
　　如何退出搜索结果？
　　3。改
　　（名称和尺寸的编辑不赘述）
　　（1）编辑入口
　　重新上传文件的入口存在于几个地方？设置区域组合关系、设置区域与材质映射关系时是否需要重新上传文件的入口？
　　（2）编辑条件
　　已经设置好区域的组合关系后，是否支持再次编辑区域成组方式？
　　（3）编辑逻辑
　　再次编辑成组时，如何确定每个区域材质信息？
　　4。删
　　所有右上角的关闭路径是什么？
　　5。显
　　（1）点击状态
　　上传完成之前，完成上传、继续上传按钮是否可点击？在进行区域成组操作时，进入材质映射步骤的按钮是否可点击？
　　（2）显示内容
　　初次打开页面、上传中间状态、上传完成状态分别显示什么？
　　6。算
　　区域和材质的映射关系是一对一还是多对一？
　　7。传
　　加载状态：读取文件、渲染图片等状态是否需要考虑加载状态？加载中、加载成功、加载失败等。
　　以上是我在提笔写PRD前，按照十四字口诀列出的思考自查表。
　　平时在进行竞品功能调研的时候，也可借助这张自查表较为完整的列出功能的实现逻辑、以及边缘情况的处理方案。有时候在调研过程中，看到竞品产品对细节处细腻的处理，会有种想要大呼对手高明的冲动。
　　大家不妨试试用这套逻辑来分析一个功能练练手，例如淘宝的我的收藏、微信通讯录等，勤于修炼、方得始终。
　　思维层级的递进
　　沉沦于面向过程的思考会失去系统的分析的高度，说人话就是功能做的太多不要忘记抽象和沉淀，否则容易迷失在细节围城的迷宫。
　　入行这一年修炼的最多的还是具体的细节逻辑，沉淀这一套通用解法，面对各种场景也能有一些思考的线头。
　　下一步就是锻炼面向对象的系统性思考方法，有所心得再与大家分享。