今天完成的事：

1.看知乎

2，调研如何从需求到PRD

明天计划的事情： 

1、任务十

遇到的问题：

1、每天都有问题，每天都在被纠正

2、权限的维度如果是限定在对某一个模块的细粒度操作控制该怎么办呢？

收获：

首先我们要知道什么是PRD?

PRD是干什么的，作用是什么？

PRD是给谁看的？

我们为什么要做PRD？

PRD里面需要写什么？

怎么写PRD？

应该怎么做？不应该怎么做？

如何采集需求？如何写需求分析？

开发流程是怎么样的？

https://zhuanlan.zhihu.com/p/21712973

https://www.zhihu.com/question/29213027/answer/66180329

PRD是什么？

PRD是“产品需求文档”

主要用于完整描述产品需求，向研发部门明确产品的功能和性能以及作为产品文档归档。

产品需求文档有三个核心作用：

传达产品开发需求；

保证各部门沟通有理有据

产品质量控制有具体标准

为什么软件开发项目中，需要需求文档这么个东西？

在稍微大一点的开发团队中，产品经理未必能向所有开发人员，传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦，所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节，测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时，文档也可以让新人更快地了解产品。

撰写产品文档可以强制所有人从项目初始就理性思考，频繁沟通，明确权责——所有的这些都会带来更好的软件质量，更低的进度风险，以及更少的时间浪费。

完善的文档可以极大的降低团队的沟通成本，提升开发效率。项目规模越大，参与人数越多，价值体现的越明显。试想，一个产品经理+两三个技术的小团队，尚且可以通过简单的脑图、原型图+口头描述的形式沟通需求，如果面对的是人数众多的设计师，前端团队，后端团队，外部团队，测试团队等，沟通成本就会成倍增加。

很多初创小团队不重视写需求文档，觉得太浪费时间，效率不够高，恨不得一个项目今天确定方案，明天就启动开发，具体需求开发过程中再定。但最终项目上线，纵观从需求到产品上线的完整过程，发现并不节省时间，因为前期节省的写文档的时间，都在开发、测试的过程中补回来了。

需求文档不够完善，通常会导致以下几个问题：

需求的工作量和技术方案难以评估：因为需求的不完善，导致启动开发前无法准确预估需求的工作量和确定技术实现方案，走一步看一步开发过程中，发现需求有坑，不断发现新的问题，有时因为一个简单的逻辑或设计不明确，在沟通明确后最终发现需要技术方案大调整，需求实际开发时间比预估的长很多，很多项目会变得失控甚至烂尾

沟通成本高：在开发过程中，产品经理依然要经常与设计、技术和测试沟通需求逻辑，完善的需求文档无疑会降低沟通的成本

技术脑补需求：有很多靠谱的技术同学，会帮助产品经理考虑逻辑和设计，如果需求没有明确描述，就按他自己的理解和想法实现了。遇到这样的技术同学，初看非常省事省心，产品简单描述下需求梗概，展示下原型图，东西就做出来了，但人和人的理解不同，实现的逻辑可能并不是产品期望的逻辑，到了测试环节，测试同学也有自己的理解，导致又要花时间沟通统一意见，或浪费时间返工修改

产品经理失去对产品方案的掌控力：对于需求的很多细节逻辑产品经理自身都不清楚，遇事都得问问技术，最懂产品逻辑的反而是技术同学，产品经理不是最了解产品逻辑的人，就会逐渐边缘化，只是简单描述要做什么，绘制原型图顺便讲讲交互的产品经理，实际更像是交互设计师

产品逻辑难以后续追溯：产品不断的迭代更新，或是人员的交接，经常需要回溯之前的线上逻辑，需求文档的缺失或不完善，会导致线上逻辑不明确，甚至后续的产品需求设计的逻辑与线上矛盾或冲突，为项目的开发带来麻烦

为什么要写产品文档？

为了以更高的质量、更快的速度和更佳的预判来交付正确的产品。

1、从一开始就理性思考
在团队开始付出更高成本去设计软件架构、实施代码开发、完善界面设计、测试软件质量之前，写文档可以迫使你提前思考每一个细节。这将会提高你决策的质量，降低意外事件发生的概率。

2、高效沟通
你常常需要和不同的利益相关方（支持团队，工程团队，设计团队，财务团队，管理层等等）沟通你的方案。产品文档可以帮助你事半功倍地完成沟通，避免口头沟通中产生的歧义，团队中的所有人可以更好地理解你的意图，并且更有的放矢地做出答复。

3、明确权责
明确项目目标的评价标准，公开承诺奖惩激励机制：利益相关方可以知晓如果最后一刻变更需求会意味着什么，工程师们也会在预估工期时再三斟酌。

PRD的面向对象是：

产品经理：可以通过产品功能描述自查清单来系统的梳理产品功能点和描述，更加透彻和完整的梳理产品；同时，产品经理可以通过PRD和其他人员进行高效的沟通。

交互设计师：通过功能点及其描述自查来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等。

开发工程师：检查自己的程序开发是否符合PRD中的相关要求。

测试工程师：PRD中的功能描述和用例转化为测试用例的一部分，进行产品可用性测试。

需求文档注定是给所有人看的，它就是产品的定义。

文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。

在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。

所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。

在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。

 开始撰写产品需求文档前的准备

在软件产品设计领域，PRD（产品需求文档）是最重要的文书。很多产品设计人员在接到设计任务后会急于开始撰写，同时非常在意PRD形式的完整性。在互联网上，也有大量的公开PRD模版可以获得，感觉可以按照填表格的方式来完成它。但是，不要过于着急。在开始撰写PRD之前，我们需要通过和需求方的沟通和确认，事先对以下内容达成了共识：

1）明确了产品设计的目标是为了解决哪些用户的哪些问题，它对企业的商业目的实现起到了什么作用？（要做什么）

2）开发项目的投入资源怎样？可以有多少产品研发人员？给出了多长的时间窗口？（能有多少资源）

3）我们要交付的最小化产品要达到什么标准？是否有对标的竞争对手或者其他产品可以帮助衡量？（要做到怎么样）

3.3.2 PRD的常见误区

1）混合而不分层次地陈述需求，缺失由总到分，由高到低，由粗到细的层次结构。这个问题通常是因为在PRD起草之前的讨论和总结不够有条理造成。结构化脑图可以帮助团队在动笔之前先建立好这个层次结构，将该脑图作为PRD文档的一部分也可以。

2）缺乏经验的设计者因为担心遗漏，追求一个过度完整的PRD，不仅事无巨细，而且把远期和非必要的需求罗列得过多，从而模糊了交付标准的界限。实际上，没有软件产品是依靠第一个版本的PRD管得太久的。要么PRD需要持续迭代，要么需要建立后续升级版本的PRD，设计者无需追求PRD的绝对完整。

3）设计者越俎代庖，不是描述需求，而是描述了解决方案。这个看似是全面能力的体现，但却对高产出的协作带来障碍。按照专业分工的要求，产品设计者应该着眼于需求和实现目标的描述，而不是替代架构师和工程师来设计具体的数据表结构和逻辑实现方法。

4）过度使用视觉辅助，而忽略对需求实质的描述。产品设计人员喜欢大量使用脑图等图表来表达逻辑结构，却对需求的实质缺乏自然的描写。虽说一图胜千言，但在需求文档中，除了参数和标准等具体的表格信息，其他视觉内容起到的主要是辅助表达作用。当然，另外一个极端也是PRD文档容易出现的问题，那就是对于复杂的需求缺失视觉辅助呈现，导致管理层和开发人员需要花很长的时间来阅读和理解。在义、文、图之间，产品设计者需要按照实际表达的需要组合使用。