Ruby语言的发明人Matz说：“代码越少，bug就会越少。”文档也是一样，越简短，包含的错误就越少，同时也更容易阅读，更容易更新，更可能带来简洁的设计，总之，保持简短的好处太多了。对于产品团队来说，简短的文档更容易撰写，所以这一条原则并不是负担。
这段话给产品经理在梳理需求文档时提了一个非常重要的建议：保持需求文档的简短。
产品需求文档作为一种和研发人员沟通的重要工具，梳理不好，会直接影响后续与研发人员的沟通质量。“保持需求文档的简短”，这点看似简单，但却是我在最初做产品，梳理需求文档时体会最深的一点。
在刚做产品时，我发现一个奇怪的现象：在我们开完需求会议把产品大概的需求告诉研发人员后，他们在实际开发过程中很少去看我写的需求文档。通常是遇到问题口头询问。我当时就很奇怪，文档里每一步都写得很细，为什么他们不喜欢读我写的文档？
于是我带着疑问和研发沟通，得到的答案是：他们没时间看我写的过于冗长的文档。他们只需要简单地理解这个功能大概是做什么的，怎么去实现它即可。文档中的内容又多又复杂，要把文档完全理解非常费时，一些不影响开发的字段完全可以放在备注中。从这件事之后，我开始反观自己文档的问题。以前总害怕研发看不懂，把一个需求写得非常细。复杂的一个功能可能写到十几行（接近300多个字）。站在研发人员的角度来看，在较短的开发时间里想用最快的速度去理解需求，长篇幅的文档确实增加了他们理解上的难度以及阅读的速度。
在梳理需求文档时，保持文档简短，会增加整个文档的易读性。以下是我总结的保持文档简短的3个步骤。
分析需求：开发需要实现哪些操作。
填写躯干：写出操作流程。
增加枝叶：展示具体内容。
让文档瘦身不仅仅增加了易读性，其实也增加了它的灵活性。因为大家在开发过程中会发现，最终开发完的产品与原来写的需求文档很难保持完全的一致性。由于接口提供问题、技术等各种原因，开发过程中多多少少会出现需求变更的情况，把文档写得简短一些也利于以后变更时修改。
实践案例
因为所在公司——亚信科技是一家专注于为电信运营商提供IT解决方案和服务的公司。有一种常见的场景就是：电信运营商的客户经理经常会在一天工作的开始，查看当天未读的提醒，或是待阅的工作。我们将客户经理的这个需求暂定一个名字叫：待阅功能。待阅功能的大致描述是这样的：客户经理看到的待阅事项主要有三大类：欠费提醒、账单提醒、生日提醒。每个提醒点击后可查看一些具体内容，比如，生日提醒需要显示提醒时间、提醒对象、短信内容，等等。
拿到这个需求我们分三步走。
第一步：分析需求
通过分析具体的需求可以发现研发人员其实要做的就是一个查询操作。
第二步：填写躯干
为保持简短性，我的需求描述主要写成：作为客户经理，我需要在待阅功能中可查看3类提醒事项，如欠费提醒、账单提醒、生日提醒。提醒以列表形式展现，点击某条提醒可查看具体内容（具体内容是一些比较详细的字段，如提醒名称、提醒日期等）。
第三步：增加枝叶
像上文中所提示的那样，把需要显示的具体内容放入了备注中。因为这些内容并不会影响开发，如果放在需求描述中，反而会降低阅读的速度和增加理解上的负担。
同时很重要的一点：我会在备注的最后标注需求来源、需求提出时间、需求提出人。因为以前遇到过一种情况：产品开发完成后，由于时间比较久，很多需求的来源都淡忘了，此时也就无法得知当初为什么要留下这个功能，为什么会有这个字段。若不幸遇到项目需求确认人离开，同时文档中没有留下任何确认过的需求来源的记录。在产品验收时，若甲方对产品需求提出任何异议，就很难予以应对，也无法对应当时的需求责任人。
总结分析
同保持文档的简短性一样，在需求变更后，针对需求文档的后期维护也是梳理需求文档时非常重要的一点。因为在产品的开发阶段，会遇到零零散散的提升用户体验或修改功能的需求提出，若不及时记录，到最后产品验收时才发现漏做需求，会让自己陷入一种非常窘迫的境地。在与研发人员不断沟通和磨合后，我总结了几点需求变更后，如何梳理需求文档的经验分享给大家。
一定要及时把变更的需求写入需求文档中，不要拖到下次再写。
用高亮的颜色标出变更的细节，如需要显示的字段内容。
对于做了删改的需求要标明原因以及时间。
以上3点是关于需求文档一些建议，在实际的文档梳理中非常受用。但偶尔也会遇到研发同志过于忙碌忘记看文档，时间一长有可能会出现需求变更忘记开发的情况。于是我专门为变更的需求准备了一个文档。文档中描述有具体需求内容、需求来源、提出时间和上线时间。拿着文档跟踪开发进度，可以避免变更的需求忘记开发的情况。
以上是关于梳理需求文档的一些经验总结。其实在工作中，无论是文档、邮件，还是面对面沟通，“简洁精炼”都是一项非常受用的工作技能。希望我的经验分享会对你有帮助。
