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