太粗略了，仅自己用。

主要问题

1、开发天天找不到哪里有说明。--> 说明太散了，一些在 jira 上，一些在 原型 上，一些在 UI 图里。

2、开发每次做一个需求，里里外外要打开好多链接。

概述

本文内容从需求规模角度来阐述针对不同规模的需求（通常以开发工期长度来衡量）应该如何写 PRD。因为这非常接地气，而且在我个人日常工作中最常用到。

在此过程中，还会涉及对「我的原型图」、「我的需求说明」的管理的反思。

碎碎念：

1、有些未覆盖的场景，日后遇到了再补充

2、本文应该是在入行 6-8 个月之后就应该产出的，来迟了（估计 6-8 个月的时候我应该还没能力写）

小规模需求

纯客户端

1、文案修改

2、UI 修改、交互调整

3、页面信息内容变化……

纯后端

1、通知文案修改……

前后端

1、页面某字段替换

2、页面新增某元素……

以上，除了通知文案修改这类纯后端，跟页面无关的需求以外，其余都必须*在自己的原型图里体现*，也就是依旧要*画原型*（以往我都是偷懒，直接截图，然后通过箭头、框框、文字等标记在截图上，粘贴到 jira 就结束了，但这样从长期来看是不合理的）

因此即便是一个文案的修改，也应该打开 Sketch，截图，P 图，上传蓝湖，这样做的好处是：

1、方便且帮助督促自己管理原型图

2、不管是在 Sketch 上还是蓝湖上

3、从开发看需求的流程上能够和看「中等规模需求」和「大规模需求」一致

4、Jira 内容简单干净，方便管理。举个例子，之前有一次做后台需求的时候，一开始以为只需要在页面上加两个文字信息就可以了，于是直接截图 P 图放进了 Jira，后来做着做着发现有原先图片上的说明不准确，需要修改，那么我就需要重新截图，重新 P 图，这就导致每次的编辑内容都是一次性的，不利于后期的编辑。

中等规模需求

例如本次的评论优化，客户端在样式展示上做了较大的改动，后端也改了好几个接口。例如标签优化，后端结构改动较多，客户端倒是较少。

同理，涉及客户端，给出*蓝湖链接*和*UI链接*即可；涉及后端的若不是长篇大论，则直接在 Jira 里编辑

大规模需求

某大系统、大功能的设计与开发，例如图片审核。

涉及客户端，给出*蓝湖链接*和*UI链接*即可；涉及后端的若不是长篇大论，则直接在 Jira 里编辑，否则单开石墨文档，再将链接粘贴到 Jira 里

原型图管理

做好 Sketch 文件分类，例如根据端来分

1、管控后台

2、APP

3、PC

4、WAP

在某个端里，例如根据业务/页面来分图层

1、文章详情页

2、个人主页

3、版块首页

在具体的一个图层里，可以将一次需求内的改动放在同一行内，或者通过紧密性原则归类

*蓝湖上同理*，不赘述了，做好分类分组

需求说明管理

在原型上标注，少在 UI 上标注。这就需要原型图做到*面面俱到*，不能少状态（即使在让 UI 做的时候 UI 没有少）

这里就有个问题，开发在做的时候，原型图和 UI 要同时打开，会有一些麻烦。但是如果将说明标注在 UI 上，会导致我的工作出现失误（说明从原型图上转移过程中出现遗漏、UI 图出了再做说明导致部分规则遗忘等）

总结

任何只要涉及客户端的需求，都需要画完整的*原型图*，并在原型图里做上说明标注。*并在开发前把每个细节考虑到尾，除非万不得已，少改需求*

做好 Sketch 和 蓝湖 文件的管理，事半功倍

（没有ul、ol好难受哇）