企业研发文档管理
作者: 来源: 文字大小:[大][中][小]
该怎么解决研发过程中保存规范有效的设计文档呢？我认为要从以下三个方面入手。
众所周知，思想决定行动。因此，首先要改变研发企业管理者和员工的意识。现在，企业竞争环境十分激烈，落后者都面临着被市场淘汰的命运。所以，企业管理者在交给下属——开发人员——开发任务时，都有一些不切实际的想法：“最好明天你就可以把
产品开发出来”。但是研发是讲究规律的，很多事情如果没有想好就动手开发，就开始画电路图编代码，其结果却是：开发后期要为前期的工作不到位而埋单。如果某个研发人员为了系统全面地分析产品的需求和设计结构耗费了一两周时间，说不定，他/她的领导会对着他/她大叫“两周都过去了，你做了些什么？难道你不知道这个项目必须在月底完成吗？”而研发人员呢，为了迎合领导的意愿，甚至也是为了迎合他/她内心的“写文档没用”的想法，也不编写相关文档，直接就动手开发了。殊不知，这是典型的欲速则不达的开发模式，是“没有时间一次把事情做正确，却有时间不断的返工”的开发行为。而编写文档能够“提高一次把事情做成功”的概率。因为编写文档是系统思考（System Thinking）的过程。当将脑海中的思考转化成文字的过程中，人们潜意识地会对描述内容的正确性、完整性、一致性进行思考，并且文档往往要被其他人阅读，所以这无形中，也迫使作者不能随意而为之。
另外，很多研发人员认为写文档是为了其他人，如产品的维护人员，公司经验积累等，对自己没有什么好处，所以不写文档也罢。在此，笔者以自己的经验告诉这些研发人员，写研发文档不仅对别人有利，更对自己有利。我想几乎所有的研发人员都希望自己的产品开发得又快又好。要能够做到这点，仅凭自己是无法做到的，因此在产品开发的过程中，需要引入别的领域专家来做评审。试想一下，如果没有相关的需求、设计文档等，专家们能够有效的发现问题吗？如果仅凭研发人员一张嘴、几张草图、随便地在黑板上画几笔，就能够让专家真正的了解您的设计思路吗？或许有些研发人员认为自己就是专家，不需要其他专家。可是你自己真的可以发现自己的问题吗？每个人都有自己的思路，也自然而然地形成了思维定势，因此当自己去检查自己的工作成果时，这种思维定势就会发生作用，也就很难发现工作成果中存在的问题了。
因此研发过程中写文档，应是企业的要求，同时也是开发人员的自我要求。
在建立了正确的文档意识后，企业应该建立基于产品开发流程的文档管理制度。没有制度，无法在企业内部形成一致的做法。很多产品的开发都是一个周期较长的过程，少则一月，多则上年，因此不应该是为了文档而文档，在事后补写，而应该是在开发工作中自然而然的产出和对之进行正确性评审。集成产品开发（
IPD）流程就是将文档工作融入了整个产品开发过程的一种有效方式。它将产品开发分成了多个阶段，同时识别出了参与产品开发的所有角色，包括研发和非研发。在流程中，基于研发工作的基本规律和产品特点，识别了各角色在不同阶段的关键活动，并定义了这些活动的主要交付件，也即相应的研发文档。
结构化的集成产品开发流程不仅给研发人员提供了何时编写文档，写什么文档的指导外，它也是公司管理者和流程监控者的监控依据。
同时为了提高编写开发文档的效率，提高文档的可读性，企业需要建立一些基本的文档编写规则和相关开发文档的模板，确保所有研发人员都在一致的基础上进行产品的业务计划、需求分析、总体架构的设计、试验报告等的编写。规范的模板不仅可以激发研发人员的思考，避免遗漏，还可以让产品的开发过程可以追朔，提高今后产品问题定位的效率。
当然任何正确的意识和规范的制度，如果缺乏监管，也是无法持久一致地在工作中得到实施。前文提到的英国设计公司的主动提醒行为，其目的也是为了免除桥梁发生意外后所需承担的法律责任。试想一下，如果没有这样的红线，情况也许会发生改变。因此，在要求研发人员编写文档的同时，企业还应该建立第三方的监控审计机制，这就是通常说的QA工作之一。质量保证QA作为研发型企业为提高研发能力而建立的一个专业岗位，事实上承担着对公司研发流程执行度的监控和审计。当然也对研发人员是否按时、是否正确、是否规范地提交研发文档负有监控责任。
如此这般，我们才能在组织层面确保研发经验的共享具备文档基础，才能通过有效的文档来提升评审的质量从而提升产品的质量，才能让后续的研发人员能够站在前人的肩膀上继续成长。
一句话，只有不断地通过有效文档的积累，才能实现个人能力向组织能力转化，才能让企业在百年之后仍然能够精准地为
客户服务。