关于知识传递的载体：Tech Article的开发管理的最佳实践

知识作为一种无形的东西，其存储和承载传递都具有其特性。把隐性的知识转变成为显性的知识是知识管理推动者所面临的一个问题。当然，最根本的不是技术手段，而是企业战略发展的需要及企业的文化氛围。为什么国外的各种大企业愿意让员工花费上班时间编写Blog或者维护Wiki，不是因为他们仁慈，而是因为这有利于知识工作者对自己的知识和经验进行总结和提炼，从而把知识碎片进行提炼，形成系统化的知识。形成系统化的知识后，就能够更方便的进行共享和传播。

在知识管理的提炼和传递过程中，讨论、交流、头脑风暴、编制文档都是非常重要的手段，Blog和Wiki也是非常重要的手段。但偶在工作的过程中，发现如果仅仅通过Blog或者BBS的方式进行知识的积累，往往达不到所需要的提炼高度。需要一种能够进行良好组织和结构的知识积累方式，方便进行积累。于是经过一段时间的思考，我们现在开始使用“Tech Article”作为一个进行良好组织的知识的载体。

Tech Article顾名思义是一种技术型的文档，主要针对技术层面进行积累的一种形式（技术是广义上的技术，并不局限于编程）。如何系统的进行Tech Article的开发呢？我们常用的是如下9个步骤：
1、规划Tech Article的内容和体系
我们会根据工作需要组织和规划应该总结和提炼哪些Tech Article，才能够真正的对客户、ISV、售前、PS提供指导和帮助，即所谓的以战略和业务为核心规划知识管理的内容和架构。
比如对于Professional Service，常见的Tech Article包括：

• 完成POC：Process of Concept的最佳实践 － 提供给PS Team
• 客户常见需求及应对的总结
• 系统迁移后进行测试的最佳实践
• APB迁移后性能的常见问题及调优的最佳时间
• PS与FO的Selling Cycle与客户的Buying Cycle之间配合的最佳时间
• 如何有效的进行项目风险及成本的分析
• 如何成为一个优秀的PS咨询顾问师
• ISV向B/S架构迁移中在产品迁移之外的迁移
• 如何分析ISV的业务是否符合Saas模式的最佳实践
• ...

应首先根据PS Team的业务发展需要， 确定需要开发的Tech Article。应首先明确，Tech Article是一个工作，是一个系统化进行组织学习、知识提炼和知识传递的工作。这也是Tech Article与Blog或者BBS之间的重大差别所在吧。

2、制定开发计划，以送耦合虚拟项目方式推动开发过程
Tech Article的开发常常涉及到多个部门、各种不同角色的人员的共同参与。作为企业的CKO或者知识主管，应确定这些Tech Article的责任部门和项目经理，并由项目经理发起该项目，选择成员或发起邀请。项目经理一般是公司的技术骨干或者具有影响力和领导能力的人员。Tech Article的组织方式同企业一般的项目不同，它并不像一般的项目那样这么严谨。Tech Article常见的组织形式包括：

• 项目经理：负责计划、组织、确定核心编制成员、冲突协调等工作；
• 项目助理：协助项目经理进行必要的会议、IS支持协调、文档整理等
• 核心编制成员：核心成员是比较固定的Tech Article的编制成员，一般不会轻易变动；核心编制成员对Tech Article的编制内容结构、质量、版本发布和变更控制负责；
• 一般编制成员：具有特定的知识结构，参与部分章节的编制，参与部分的交流和探讨；
• 参与者：可以根据需要参与相关的会议、交流、活动、培训，可以提出意见和见解；

由于项目的这种参与人员数量会比较多，同时结构相对松散，虽然企业可以安排出一定的时间来，但优先级仍然不是最高的。因此，在支撑这种松耦合的虚拟团队工作时，Sharepoint是一个非常好的工具。可以建设专门的站点，用于Tech Article的开发，同时针对每一个Tech Article，均开启一个单独的项目站点。

3、确定目录架构、评审及确定职责分工
确定Tech Article的组织架构，可以通过MindManager/头脑风暴的方式，确定某一个具体的Tech Article的内容组织架构。当然也可以由1－2名核心编委起一个草案，提交大家审批。目录架构的设定对于Tech Article的开发非常关键。一般Tech Article的目录架构的开发包含如下几个过程：
－目录架构内部草案
－目录架构内部评审
－目录架构征求意见
－确定目录架构
－确定文档与相关Tech Article及其开发团队之间的协作关系
－详细描述各目录章节的内容要点及要求，描述相关的关联关系
－确定章节责任分工

4、具体的Tech Article的内容开发
确定完毕Tech Article的目录架构后，并且完成职责分工，即可以开始着手进行编制。这就是一个松耦合的项目管理的工作了。在这个过程，将涉及到大量的交流、探讨、分析，根据需要甚至可以同公司申请一些资源，如外部调研和客户走访、购置设备和搭建评估环境等。
项目经理在Tech Article的开发过程中起着非常重要的作用，他应该是一个非常热心的推动者、一个具有丰富经验的项目经理，同时非常了解公司的战略和需求，了解业务，善于同高层及业务部门进行沟通和交流，并根据需要申请必要的资源。

5、Tech Article的整合
在进行初步的开发完毕后，应对Tech Article进行集成和整合，形成正式的草案，提交核心编委进行评审。

6、内部评审
内部评审过程主要是由项目经理组织各位核心编委共同对形成的Tech Article进行审核、质询、修订，这是一个非常重要的过程。Tech Article作为知识在内部和外部传递的最主要的一个方式，如果在质量上没有保障，毕竟影响知识的传递，形成对内部员工和客户的误导，即影响公司的品牌和形象，也影响客户的工作。
内部的评审应进行多轮，多次评审，并根据需要，对某些章节进行必要的重写及重构。在Tech Article的编制过程中，可以充分借鉴XP的思想，及时进行重构。否则到了最后，对于一个300页的文档，如果再进行大的重构，那将是一个非常痛苦的事情。

7、征求意见
在内部征求意见或者适当的在外部客户（应适当选择客户范围）间进行Tech Article的意见征集，邀请共同进行评审和修订。这个过程可以让更多的人可以参与进来，让大家从各自工作的角度进行提出建议和意见。对于一个决策来讲，征求异议是决策的非常重要的一个过程。
在征求意见后，核心编制组可以根据意见进行修订和完善。并一定要针对意见进行全部的回复，即为什么采纳，为什么不采纳，计划在当前版本修订还是以后修订等，形成书面的征求意见的答复。因为征求意见不仅仅是一个技术性的问题，而且涉及一个参与感和感情的层面。确保广泛的参与度，尊重每一个人的意见和建议，鼓励大家的献智献策，倡导和推动良好的企业文化。

8、发布
每一个Tech Article都凝聚了非常多的人的感情和心血。因此，即使我们不能够象Microsoft发布产品一样进行发布，我们也需要正式的进行发布。Tech Article的发布是一个公司层面的事情，应经过公司的严格审核和策划。比如购置一个专门用于存放所有的Tech Article的玻璃书柜，在公司内部贴海报，摆在现眼的位置，召开一个小型的发布会，在公司网站和内部Portal上进行发布通知，将Tech Article印制一些书面的印刷版本，赠送给核心编委进行永久留念，给每一个Tech Article设计专门的封面和Logo ...，只要可以想到的，不用花费很多钱的，都可以去做，而且要尽量去做。

这非常关键。我们需要鼓励知识工作者的这种工作，让他们享受这种荣耀和尊敬，因为他们付出了更多的心血去开发这些Tech Article。

9、持续完善
Tech Article发布后，并不是终结。而是一个新的开始。公司应建立持续的对Tech Article的使用跟踪和意见反馈区域，持续进行优化、修订和完善。
应将Tech Article形成一个循环和轮回，持续改进。这也是第5项修炼所倡导的思想。
持续完善和改进是大部分公司进行知识管理常见的问题，就是一开始风风火火，一旦整理完知识库后就束之高阁，没有人去看，去用。这有悖于知识管理的目的。
因为知识管理的目的同企业的目的是一致的，那就是推动创新，提高企业核心竞争能力，提高企业的盈利和持续发展。

最后，非常感谢你花费了这么长时间看完这篇冗长的文章。这篇文章本身就是一个知识积累的提炼。当然，我现在把它作为一个Blog出现，说明我们在此方面还没有进行系统的提炼，还没有形成真正的Tech Article。我会继续总结和提炼这些东西，希望能够形成Tech Article，提供给大家共享和参考。

参考：
由于涉及到企业内部信息保密的问题，在此仅仅提供一个公开的Tech Article样例，仅供参考。这个Tech Article也是使用以上开发流程进行开发的。
Tech Article ：使用PGP系统进行安全邮件传递.pdf
注：这个是一个PDF文件，建议点右键下载到本地后阅读