怎样才能写出简单易懂的需求文档？

怎样才能写出简洁易懂的需求文档？【文章摘要】产品需求文档作为一种和开发人员沟通的重要工具，假如梳理得不好，会干脆影响后续与开发人员的沟通质量，“简洁易懂”显得特别重要（产品需求文档）,这PRD Product-Requirement-Document,对于任何一个产品经理来说都不会生疏的一个文档，在网上搜寻也很简洁找到关于的干货，但会写还是不够，许多产品PRD新人都问我为什么我的文档开发哥都不看？怎样才能写好PRD呢？语言的创始者松本行弘说过“代码越少，有可能出现Ruby bug的机会也越少”文档也是一样，越是简短，可能出现的错误也会越少，同时也更利于阅读、维护和更新，所以建议大家的要写成“简洁易懂”PRD产品需求文档作为一种和开发人员沟通的重要工具，假如梳理得不好，会干脆影响后续与开发人员的沟通质量，“简洁易懂”显得特别重要但许多刚做产品的同学不太了解其重要性，会走不少弯路，他们会发觉在开完需求会议后开发人员在开发的过程中很少去翻看需求文档，通常状况下都是口头询问，同学们就觉得很惊奇，他们写文档写得那么具体,为什么开发人员就不看文档呢？既然不看，就不用写了，干脆用口头沟通不是更好吗？其实，能用口头阐述都小问题和小项目，假如是中、大型项目，参加人员比较多，文档是有助于减低沟通成本和提高共走效率；还有一点，许多时候开发不看文档，是嫌弃文档的内容太长了，他们只须要简洁了解这个功能也许是做什么的，怎样去实现就可以了反观许多同学在写的时候会进入一个误区，事无巨细地描述规则，总胆怯开发同事看不懂，一个比较困难的功能可能写个字，结果人家干脆不看了300怎样才能写出简洁易懂的需求文档呢？、分析核心需求1明确开发需求实现哪些功能需求，许多时候只是对原型上PRD没有的说明进行补充，你总不能输入框限制多少个字符都写在原型上面，所以第一步须要看一下哪些是说明并没有在原型上面提现，然后在上面进行补充例如，原型上面更多的是PRD交互说明与规则说明，但对字段的限制一般都很少去说明，还有时候原型上很难包含全部状况页面，所以也有时候须要PRD补充一下、先填写躯干2为保持简短性，需求描述主要写成，提取关键词，关键词字数不要超过个字，这样可以让开发哥最快的速度以内了解功能6点；最好运用约定俗成的语言，因为产品与开发部在有些点上面的描述和说法是不一样的，假如运用大家能立刻看得懂的言语就能提高效率，这个须要平常的积累和沟通的沉淀，最好每次项目结束总结范例，那下次开展项目可以更快更速度、再增加枝叶3写完关键词后，围绕关键词展示具体内容，把须要显示的具体内容放入了说明中，因为这些内容并不会影响开发，假如放在需求描述中，反而会降低阅读的速度和增加理解上的负担就前三点举个例子我曾经做过一个功能消息待阅读，一级躯干为欠费提示、账单提示、生日提示，二级枝叶为欠费提示中对象、内容、时间等元素，最终对元素进行描述、备注说明4在备注的加入需求来源、需求提出时间、需求提出人，避开出现产品开发完成后，由于开发周期太长，许多需求来源都渐忘了，无法得知为什么当时有这样的功能和需求，为什么增加这个字段，假如遇到项目需求确认人或者开发人员离开了，同时文档中没有留下任何确认过的需求来源记录，在产品上线验收的时候，需求出现了问题，那麻烦就大了，其实文档也是爱护双方的一种手段、时刻维护5文档还须要保持时刻更新，因为在产品开发阶段，会遇到零零散散的提升用户体现或者修改功能需求，假如是到了最终上线期间才去补很简洁产生遗漏，这里也举荐避开个遗漏的方法

3、肯定要刚好把变更的需求写入需求文档中，不要拖到下次在1写、用高亮的颜色标记出变更的细微环节，如须要显示的字段内2容、对于做了删改的需求要标明缘由以刚好间

3、假如中途修改次数过多，建议特地做个文档来记录变动状况

4、项目总结6每经过一次项目，总结是必不行少的，在方面也须要总结，PRD在总结大会上须要收集开发对此项目的看法和修改方向，PRD如何才能更清楚简洁地阐述我们的观点，“简洁易懂”不单单是产品部为这个目标奋斗，开发的同事也应当参加其中，这个在下一个项目开发中才能取得更大的进步本文作者毕振杰微信公众号毕生说产品本文由@毕振杰授权发布转载请注明来源于产品并附带本文链接100产品特别欢迎产品界的各路大神、人神、女神、男神、土100豪、扇丝来稿！共同共享爱，明天会更好，小编等你来稿少ann@chanpinlOO年关注我们的官方微博@产品和微信订阅号100有惊喜哦!chanpinlOOghsd,未经允许不得转载产品怎样才能写出简洁易懂的需求文100档？。