企业研发文档管理.docVIP

企业研发文档管理 　　笔者多年来一直帮助企业提高自己的研发能力，看到太多的国内企业的做法，听到了很多企业管理者无奈的声音。很多公司可能成立时间很短，少则两三年，多则十余年（能超过这家百年设计公司吗？），但是能够拿出以前的产品设计文档吗？拿出的设计文档能够让后面的设计人员读懂吗？除了一些必需的电路图纸和软件代码，还有逻辑清晰，内容完整，关系一致的配套设计文档吗？　　记得有一次，与国内某电子行业龙头公司签订了咨询服务合作协议。在访谈时，总经理的一席话让笔者印象深刻，“我们公司已经成立都十年了，但是我感觉我们公司没有任何积累。只有一些老员工通过不断的犯错、试错获得了一些经验，但是这些经验无法在员工之间共享，都是私人财产，这些人一旦离开，什么经验教训都带走了，找来的新人又开始了试错、犯错的老路子。我们甚至还遇到过这样的情况：有一个产品推向市场后，市场反映不错，引起了竞争对手的注意，把我们的那个工程师挖走了，搞得我们无法继续开发其后续产品。我们在这个过程中付出了极高的成本，希望顾问们能帮我们想想办法。”　　该怎么解决研发过程中保存规范有效的设计文档呢？我认为要从以下三个方面入手。　　众所周知，思想决定行动。因此，首先要改变研发企业管理者和员工的意识。现在，企业竞争环境十分激烈，落后者都面临着被市场淘汰的命运。所以，企业管理者在交给下属——开发人员——开发任务时，都有一些不切实际的想法：“最好明天你就可以把产品开发出来”。但是研发是讲究规律的，很多事情如果没有想好就动手开发，就开始画电路图编代码，其结果却是：开发后期要为前期的工作不到位而埋单。如果某个研发人员为了系统全面地分析产品的需求和设计结构耗费了一两周时间，说不定，他/她的领导会对着他/她大叫“两周都过去了，你做了些什么？难道你不知道这个项目必须在月底完成吗？”而研发人员呢，为了迎合领导的意愿，甚至也是为了迎合他/她内心的“写文档没用”的想法，也不编写相关文档，直接就动手开发了。殊不知，这是典型的欲速则不达的开发模式，是“没有时间一次把事情做正确，却有时间不断的返工”的开发行为。而编写文档能够“提高一次把事情做成功”的概率。因为编写文档是系统思考（System Thinking）的过程。当将脑海中的思考转化成文字的过程中，人们潜意识地会对描述内容的正确性、完整性、一致性进行思考，并且文档往往要被其他人阅读，所以这无形中，也迫使作者不能随意而为之。　　另外，很多研发人员认为写文档是为了其他人，如产品的维护人员，公司经验积累等，对自己没有什么好处，所以不写文档也罢。在此，笔者以自己的经验告诉这些研发人员，写研发文档不仅对别人有利，更对自己有利。我想几乎所有的研发人员都希望自己的产品开发得又快又好。要能够做到这点，仅凭自己是无法做到的，因此在产品开发的过程中，需要引入别的领域专家来做评审。试想一下，如果没有相关的需求、设计文档等，专家们能够有效的发现问题吗？如果仅凭研发人员一张嘴、几张草图、随便地在黑板上画几笔，就能够让专家真正的了解您的设计思路吗？或许有些研发人员认为自己就是专家，不需要其他专家。可是你自己真的可以发现自己的问题吗？每个人都有自己的思路，也自然而然地形成了思维定势，因此当自己去检查自己的工作成果时，这种思维定势就会发生作用，也就很难发现工作成果中存在的问题了。　　因此研发过程中写文档，应是企业的要求，同时也是开发人员的自我要求。　　在建立了正确的文档意识后，企业应该建立基于产品开发流程的文档管理制度。没有制度，无法在企业内部形成一致的做法。很多产品的开发都是一个周期较长的过程，少则一月，多则上年，因此不应该是为了文档而文档，在事后补写，而应该是在开发工作中自然而然的产出和对之进行正确性评审。集成产品开发（IPD）流程就是将文档工作融入了整个产品开发过程的一种有效方式。它将产品开发分成了多个阶段，同时识别出了参与产品开发的所有角色，包括研发和非研发。在流程中，基于研发工作的基本规律和产品特点，识别了各角色在不同阶段的关键活动，并定义了这些活动的主要交付件，也即相应的研发文档。 　　结构化的集成产品开发流程不仅给研发人员提供了何时编写文档，写什么文档的指导外，它也是公司管理者和流程监控者的监控依据。　　同时为了提高编写开发文档的效率，提高文档的可读性，企业需要建立一些基本的文档编写规则和相关开发文档的模板，确保所有研发人员都在一致的基础上进行产品的业务计划、需求分析、总体架构的设计、试验报告等的编写。规范的模板不仅可以激发研发人员的思考，避免遗漏，还可以让产品的开发过程可以追朔，提高今后产品问题定位的效率。　　当然任何正确的意识和规范的制度，如果缺乏监管，也是无法持久一致地在工作中得到实施。前文提到的英国设计公司的主动