从实际情况来说，很难，你的语言描述要足够精炼和准确，你的知识接收者还要正确理解你表达的意思。有很多需求其实在沟通会议上反而更迅速和明确，prd的作用是记录结果和防止和别的部门撕逼用

PRD 可以分为几个部分，以图为主，文字为辅，且 渐进明细 ，就能在一定程度上防止遗漏，同时也降低阅读者的痛苦。

第一部分，相对宽泛、没有细节的需求定义

这部分主要用业务流程图、业务对象ER图、数据对象数据结构图，来框定需求的范围，以及统一团队的业务认知；

第二部分，直观的界面原型

将第一步的业务流程、数据对象，落到原型图上，让前后端对要实现的接口量有个预估；原型可以带一些基础的交互；

第三部分，边界条件、特殊规则、非功能性需求（安全、性能等）的补充，这部分主要是文字描述

整体三步，前两部以图为主，图直观易读，第三步辅以适量的文字性补充说明。

 #产品经理挑战赛# day1

      我觉得提高prd文档的沟通效率要从以下三方面实现：

1.展示形式：一定要画低保真的界面原型。界面包含哪几部分功能通过界面原型的方式呈现出来出来，不光非常直观，还能够帮助发现很多细节设计方面的问题。

2.文字表达方式：要结合用户场景描述功能。这个功能，用户在什么时间点什么情况下使用该功能，该功能帮助用户解决什么问题，要说用户想要干什么，而不是我们想要干什么。

3.数据来源及计算方式：数据也是prd的重要部分，各个数据来源及计算方式都要说清楚。

 #产品经理挑战赛# day4

看到你的问题，应该主要是给内部开发人员看的，如果不涉及到给客户、给老板或者其它角色的化，把开发他们不同角色关心的点涉及到就可以了的，

对于UI ，他们关心页面的功能有哪些，字段信息有哪些，如果需要做交互，需要把功能的优先级阐明。

对于前端，他们关心页面的布局，如果是纯线框图，可能会弱化交互，这个时候一定要文字把交互表达清楚，因为测试会根据你所写的交互操作来进行验证。

对于后端，他们关心业务的流程，字段信息是否完整，整个系统的复杂逻辑都会由他们来实现，同时，测试也会根据你写的逻辑来进行验证。

对于测试，他们作为质量的把控者，质量的好坏标准完全由prd来进行设定（测试用例根据prd来进行编写）

 #产品经理挑战赛# day2

这种有所遗漏的情况，你需要认识到其存在的必然性。即使是从业多年的大牛，也无法保证产出的PRD中不存在遗漏。越复杂的项目，需要描述的内容越多，这种遗漏情况就越容易发生。

在认识到必然性之后，可以通过一些行之有效的办法来降低出错的概率，避免一些低级、重复性的失误。

1、思维导图是个好东西。设计复杂功能时，先自嗨脑暴，从需求来源出发，连接上你能想到的，有一丝丝关联的功能点。这个阶段不用考虑研发成本、实现等问题。脑暴结束后，在结合具体需求场景，拆解出MVP。能减小遗漏关联功能的情况；

2、撰写规则逻辑、定义交互效果时。注意对各种场景需要的考虑充分，对于各种操作流程（成功、失败、等待中、无网络、网络差、关联数据产生了变动、权限丢失等），都需要考虑该如何处理。但要把握好“度”，对于一些处理成本较高，影响却很小的情况可以忽略或以后再优化，揪着某个无伤大雅的细节钻牛角尖，只会让合作者难堪，让项目无法推进；

3、有条件的话安排内部评审。产品内部进行评审，家丑不可外扬，有些你没考虑到的地方，让你的leader和其他同事把把关；

4、务必安排产研评审。拉上相关的研发、测试，详细讲解你的设计，回答各种刁钻的问题。理性看待各种反馈，解释不合理的，接收合理的，并且确保大家都有同样的理解。不要害怕被挑战，蒙混过关的需求只会让后期的推进痛苦不堪；

5、一些辅助性的清单、自查表。对于能想到的，经历过的失误、遗漏的内容，可以列个清单用于核查。每次PRD撰写完后，对照着检查一下是否有遗漏的，之前犯过的错是否又再犯。

写在最后，我始终认为“沟通能解决大部分问题”。希望你能保持一个积极沟通的心态，千万不要有“多做多错，少做少错”的想法。对一些忽然想到的，觉得可能有问题的地方，及时反馈。项目推进中被吐槽，总要好过后期出现问题，导致无法上线。

一起共勉。

#产品经理挑战赛# day3

我是这么看这个问题的：分当下和长线。

• 长线：就像题主讲到的，锻炼思维完整性，让自己成为一个逻辑思维很缜密的人
• 当下：在自己没有成为逻辑思维很缜密的人之前该怎么办？有什么是目前就可以做，而且做了就能完善的产出方案的？

就像如果一个人去看老中医，说我体寒，很容易就冷，怎么办？老中医会说你如何如何调理身体，让体质好起来，不再体寒，但这是一个长期的过程。除此之外，也一定会说你现在少吃生冷的食物、注意保暖，这是当下可以做的。

我甚至觉得“当下”甚至比“长线”更为重要，因为“当下”没有做好，就会有很直接的后果产生。

所以先说下在“当下”可以做什么?

1、用好思维导图——用思维导图，把该需求相关的所有点都列举出来，这样能有效地避免以部分疏漏。这些相关点有需求直接搜集到的、产品相关功能点、竞品的一些做法等等；

2、方案自查表——维护一个方案自查表，表中的内容是不断总结的出方案时容易疏漏的点，然后每次写完方案后，都对照自查表，一个一个check；

3、多沟通——有些细节，只靠产品可能是很难想清楚的，这个时候不要怕麻烦，多找人问问，特别是研发和测试。也争取在产品内部开内部方案评审会，会上应该能填不少坑。

然后“长线”可以做什么？

1、把PRD当做产品——用做产品的态度写PRD，为了写好（条理清晰、方案完善、可读性高）PRD，我做了竞品调研（研究其他同事、其他公司的产品的PRD）、做了用户调研（定期投放问卷让开发、测试、设计反馈他们读我的PRD的真实感受、他们看重什么、有什么建议？也会一对一聊）；

2、了解一些基本的、简单的思维模型，刻意做一些简单的训练——比如连问自己5个为什么才能找到更真实的答案、归纳推理、演绎推理等。

每个人的认知水平不一样，同样一句话的理解肯定也会有出入，不沟通是不可能的。

最简单的一句话“他走了”

理解出来的结果就会有：
1、这个人死了
2、这个人刚刚出去
3、这个人不在这个公司了
等等，还有很多

我们常用的就是，讲完需求，让对方用他自己的理解，再复述一遍，去反向评估 他是否真的理解。
需求、开发、测试、设计人员的处理问题的方法都不一样，所以需要多沟通，听他们是否真的明白了

再举个例子，产品说“我要什么”，而开发的逻辑是“这个东西里面，不包含什么、什么、什么，那么剩下的就是你要的”

还有就是，你可以完全转换到对方的思维方式，给他们讲解需求，而不是你自己的逻辑。

 #产品经理挑战赛# day2

要让UI、研发、测试多角色都能够读懂，首要前提是撰写prd时就考虑到这些用户的阅读视角。

1、首先，建议描述需求背景，通过这块的描述，让各方对需求要实现的目的达成一致；

2、其次，建议有业务流程的梳理，便于各方理解这个需求涉及到哪些角色、哪些场景、核心实现的流程是怎样、以及多系统间如何交互。这里对研发、测试同等重要，UI可以减少关注；

3、第三，通过页面交互流程，将业务流程串起来；此处研发、测试、UI都可以直观的对整个功能在系统内的呈现方式，有一个明确的想象，并且尽可能保证大家认知相同；

4、第四，才进入到各个页面的具体需求描述；详细描述时，可以把页面展现内容、交互形态、数据来源及交互、埋点等等拆开来讲。UI和前端可以更关注页面交互形态，后端可以更关注数据来源和交互逻辑，测试也可以根据情况分模块测试。总之，就是把各方各自更关注的内容，以清晰的结构的写出来，便于各方阅读；

5、最后，好的文档还需要有效的评审，在讲解的过程中好好把控节奏、尽可能当场解答研发的疑问，同样会减少研发会后在单独阅读文档时难以理解的情况。

我们是产品和研发在一个会议室，face to face的沟通就很多，即使不在一起的同事我们也倾向于去工位找他沟通。在我看来prd就是一个思路呈现，在功能上可以理解成营销做得ppt、运营写的文档，因为岗位不同所以承载内容的形式不同，但跟本上反正就是告诉别人这是一个什么事情。

要落实在纸面上，一方面是因为纸面上比口头更有逻辑性，一方是是纸质可以在之后的任意时间翻阅并以此为参照，一方面就是防止撕逼留下证据。但如果说沟通效率，一定是口头，尤其face to face。

#产品经理挑战赛# day1

我觉得需求评审会真的很重要，要想开一场完美的需求评审会，必须明白需求评审的目的，只有明确目的后，做好相关的准备工作才能够事半功倍！

1. 需求评审的目的

• 检视需求的合理性与完整性，降低需求风险。
• 与项目干系人对项目目标、需求达成一致，方便其他工作人员能够了解工作任务，从而增强团队协作能力。
• 能够对产品进行全方位的论证，验证或更改自己的想法、获取更多的想法，进行头脑风暴，完善产品需求。头脑风暴的作用有以及几点，不仅仅试用与需求评审也适用于其他方面。

2. 头脑风暴

1. 让参与者敞开思想集体讨论，相互启发激励，以弥补知识缺陷
2. 引起创造性设想的连锁反应，产生尽可能多的设想，并使各种想法在相互碰撞中激起脑海中创造性风暴
3. 再对设想进行客观，连续的分析
4. 从而找出解决难题的黄金方案

#产品经理挑战赛# day1

针对于这个问题，就近期本人工作涉及PRD的整理，可以说有些不一样的想法。

1.首先，不同公司对于PRD的定位不同，每个人对于自己的书写方式都是不同的，我们要确定PRD的目标用户是谁？如果只是研发、测试看，那么不必拘泥于死格式，我们的目的是让研发和测试能够快速准确的了解熟知每一个功能点，哪怕只有原型，只要足够详尽也是无可厚非的。

2.其次，现在一些培训课程会给出非常标准的PRD模板，内容量可以说是非常大，格式漂亮，内容丰富。但是，看起来大部分人都是眼花缭乱，更别说是研发，测试的小伙伴。PRD的定位应该是简洁、完备、清晰，能够快速讲清楚业务和功能，有效的缩短时间。这里主要是想表达，不是内容多，漂亮的东西才是最好的PRD，应该针对不同的对象给出相应的格式。

3.最后，近期我个人在梳理公司的产品资料，也整理新产品的PRD。这过程中发现，之前的格式一诚不变，相关人员也并不能很清楚的了解到具体内容，导致浪费掉双方的时间。对此，我个人认为在设计的过程中直接给出详尽的说明和交互效果，以文档PRD的格式来产出原型。

先内部评审，然后需求宣讲，然后测试用例评审。

即使这样，还是在测试阶段有各种问题要解答，正常的。

没有说一步到位，文档100%无误。所以平常心即可。

补充一下：怎么锻炼这个事，多几个项目，熟悉系统和规则。用思维导图梳理功能点。画流程图。自然就不会漏太多东西

 #产品经理挑战赛# day3

1、图文并茂，通过图示并加以说明；

2、按照不同的场景进行举例和说明；

3、将功能点的作用和需求对应，更加形象的说明需求是什么，对应的功能是什么，通过功能去解决什么样的问题。

通过以上就更清楚具体的需求是什么，需求对应的具体功能是什么，然后通过图片或说明对应的页面逻辑和交互，在加以相应的说明，相信已经说的很清楚了。

多沟通，才会少出现不必要的沟通

你们PRD写完不用评审吗？开几次评审会，自己做好总结，你的文档质量肯定会上去的。