作为产品人，PRD是工作中的一大块重要内容。而关于PRD的生产/搬运（copy）过程，大概可以套用《同桌的你》：
明天你是否会想起，好容易做的原型设计
明天你是否会惦记，评审会上被围攻的你
开发们都已想不起，经常改需求的PRD
我也是偶然翻日记，才想起有漏洞的设计
是的，PRD功能完整、逻辑正确永远是产品人头上的两座大山。这带来了无数撕逼的日夜——从来不曾忘记，而且时常想起……
而保证PRD功能完整、逻辑正确的有效方式之一，就是熟悉“增删查改显算传”。
“增删查改显算传”是什么鬼？先来看看所谓“增删查改”，维基百科如此解释：
Incomputer programming,create, read, update, and delete(as anacronymCRUD) are the four basic functions ofpersistent storage.
在计算机编程中，增删查改（CRUD）是永久存储的4种基本功能。
度娘了一下“增删查改”，能明显地看出这与编程的关系。
维基百科还有解释：
CRUD is also relevant at the user interface level of most applications.
增删查改也与多数应用的用户界面设计相关。
为什么“增删查改”能保证PRD功能完整？因为这4种功能太基础了，维基百科如是说：
Without at least these four operations, the software cannot be considered complete.
所以，“增删查改”是研发常常需要考虑的，也是保证界面设计的完整性的。如果在这方面考虑不够全面，可想而知的是，在原型评审与后期开发时，必然会遇到很多问题。再加上PRD更改起来常常是牵一发而动全身，这就蛋疼了……
所以，“增删查改”是必须考虑的，也是必知必会的。“增删查改显算传”，则是前者的升级版。
当然，核心中的核心，仍然是用户+需求+场景，即所谓PSPS。因为这才是PRD的来源，是战略层的内容。很多页面不一定符合“增删查改显算传”，这就是需求决定的。正如巴顿将军曾说过：
Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.
永远不要告诉别人如何做，而要告诉他们做什么，他们会给你带来惊喜。
这里就不过多展开了，将来再聊（要离题了）……
So，以用户+需求+场景为核心，再辅之以“增删查改显算传”，就能打造出一款功能更完整、逻辑更正确的PRD。注意：“增删查改显算传”属于范围层，而“用户+需求+场景”属于战略层，前者从属于后者，切不可打乱顺序。也就是说，在考虑“增删查改显算传”时，必须以“用户+需求+场景”为基础。例如，实际工作中，在设计功能结构图、信息架构图时，不能以“增删查改显算传”为前提，这样就容易本末倒置。比如我之前就犯了这样的错，在设计信息架构时，竟然是这样的，往事不堪回首……
不过，说了这么多，“增删查改显算传”到底是什么鬼，似乎还是有点模糊，那下面我们就直指本质——看看在编程语言上，“增删查改”到底是什么。看下图：
其实从上图中“增删查改”的英文名，以及“增删查改”的中文名（中文的“查”还是容易误解），就能猜出其大致含义。再结合SQL语句的解释，就能更准确地把握“增删查改”。
为了更全面地描述“增删查改显算传”，也为了体现其全面性，这里就将那著名的、能弥补漏洞的“5W2H”糅合进来，给“增删查改显算传”来一个全息展示：
图不给力，拆成2张更美丽：
仔细看看上图，看起来挺多，其实还透露了更多：
1.上图其实体现了用户+需求+场景的思想；
2.上图也说明了“增删查改显算传”为何能保证功能完整；
3.“增删查改显算传”、5W2H都不能保证绝对完整，但相对而言，都已很完整。这也从侧面说明了PRD有多完整。
当然，而我们要做的，就是既要考虑“增删查改显算传”，又要考虑其鞭长莫及的地方——如上图你所见的地方。
到此，我们已经很接地气了。但送佛送到西，不妨更接地气一点——举个栗子好了：
下图是全民应用微信的通讯录页面。
增——很明显的，右上角是“增”，可以加好友、公众号、扫码等等。
删——删除联系人的功能层级较深，需要进入联系人详情页，再点击更多操作才能看到红色的删除按钮，这就是“用户+需求+场景”的考虑了，当然也可能有其他考虑——这可能反映了微信不不鼓励用户删除好友，正如不鼓励用户发文字状态。
查——这个功能就更为明显，也更强大。页面顶端的搜索框，就是明晃晃的“查”。这里吐槽下：搜索框右边多出那一块干嘛，不影响美观吗？都好几个版本了也不改改……
改——左滑修改，这里不特别说明了。
显——这个页面的图标、文案、排列顺序、交互等等，都可以视作“显”。值得一提的是排列顺序，这是写PRD时需要考虑的。下图的通讯录，就是按照姓名首字母顺序排列的。
算——在本页中，体现得最明显的地方就是底部的好友数量，如下图。微信好友数上限是5000，这也是“算”的体现。当然，“算”与很多计算规则有关，下图的数据也涉及计算规则，再比如微信中常见的如朋友圈点赞/评论数的计算规则、文章浏览量计算规则等等。
传——这是难点。在微信里，一个明显的案例就是聊天：你发信息，别人收到了，这就是“传”。而“传”也是容易出错的地方，例如下图中，删除已设定的通讯录的标签，删除时是否要提示？已经使用的标签能否删除？删除时数据如何传递？这都是需要考虑的内容。当然这里微信做得比较简单，能直接删除，而且没有提示，这当然也是因为“用户+需求+场景”，因为这个功能对于多数用户而言并不重要。而假设换一个场景，换一种用户，标签的分类功能变得非常重要，这时就不能随意删除——必须提示，甚至已使用的标签不能删除。而“传”由于其牵一发而动全身的特性，就可能会使得PRD的一些细小更改变得障碍重重，这是难点，也是必须踏过去的难点。
再结合之前总结的思维导图，这里还要考虑用户的数据权限——什么用户能看到什么内容。比如通讯录，我就不能看到你的通讯录（张小龙能不能看到我的，这我就不知道了……）。再比如发朋友圈，你屏蔽了一些人，那些人就不能看到……
其他的就不继续罗列了……
怎么样，这样梳理一遍是不是清晰了一些？总结起来：以用户+需求+场景为核心，再辅之以“增删查改显算传”，就能打造出一款功能更完整、逻辑更正确的PRD。
