书接上回：研发项目文档重要吗？个人以为，改进研发项目文档内容质量，需要深入研发流程，梳理研发流程中的信息需求和依赖关系，完善相关的内容规范（模板）和评审规范，从系统上保障研发文档的质量。
所以这段时间，协调痛点场景作为改进试点，参与到研发设计/方案评审会，虽然免不了会让人觉得“你一个排版的懂什么”，但还是要依着自己的想法，捕捉一切蛛丝马迹，寻找可能存在的改进点。
领导说：你写个问题说明PPT吧。嗯，那我就基于个人有限认知，简单地分享两句吧。大家好，我是睿齐，一个技术传播者。
当我们谈研发项目文档时，我们谈些什么？
一提到研发项目文档内容质量，很多研发同事可能会立即生出误解和抵触：
是不是又要为写文档而写文档了？
是不是又要咬文嚼字儿讲语文了？
是不是又要强迫症附体排格式了？
NONONONO，并不是这样。实际上，我们更希望可以从研发项目文档中看到的是：
通过深度思考，明晰产品定义和技术实现，形成系统的文字说明，便于团队成员共享知识，对齐关键信息，达成一致目标，共同实现/验证产品定义；同时，归档知识资产，便于后续跟踪回溯。
所以归根结底，当我们谈研发项目文档时，真正谈的是研发项目信息管理。
就大规模集成产品而言，以我目前的实践深度，贸然讨论研发全流程信息管理，未免显得有点不自量力。所以为了说明原理，在此仅以敏捷开发流程为例。——有朋友可能要说了：我们敏捷开发都不写文档。嗯，咱别杠。
虽然产品、开发（包括代码+文档）、测试来自于不同的部门，但是就项目而言，他们更是实现共同目标的团队成员，对产品交付负责：产品→定义；开发→实现；测试→验证。
在研发过程中，产品、开发、测试彼此之间要共享信息，并且互相依赖。
嗯，上面这张图看不太清楚，也有一些歧义，重新画一下：
但是，由于很多原因，产品/技术信息没有被充分挖掘，顺畅的传递，以至于团队成员疲于沟通，研发进度却迟迟无法推进。具体场景实在太多了，在此仅以测试方案为例，来看看保证文档内容质量遇到了哪些挑战。
很多时候，我们误以为自己为文档编写付出很多，却巧妙地错过了实际使用需求。
针对于具体的文档场景，以测试方案为例，改进文档内容质量，需要从3个方面入手。
保证文档内容质量，绝不是一个部门、一个开发责任人在努力，而是需要充分调动起整个项目团队中每位角色（至少是主管），打破部门壁垒，深度参与贡献知识，共同完成。其中最重要的动作是：技术评审。然而文档评审很可能也是受到诟病最多的部分，以至于，不重视、低效、无结论……如何解决？且听下回分解。
其他推荐：
实施：GitHub + MarkDown 文档系统的工作环境部署及工作流程说明 | 技术传播
这次他们说好要“讲真的” | 传播
在座都别吵了，你们还有我 | 技术传播
睿齐
技术传播从业者
品牌内容策划
自由摄影师
自由撰稿人
汪力迪
公众号：techcomm / htstory
微信号：bgrichi
邮箱：hash_0813@163.com
