一步一个脚印，现在就开始去做。
编者按：本文来自微信公众号 红杉汇（ID：Sequoiacap），作者：洪杉，创业邦经授权转载，图源摄图网
我们不时会在社交媒体的热搜上看到大型互联网公司服务器出现问题的消息。这些问题有的很快被修复，有的则需要用户等待许久。在抢修的过程中，比用户更焦躁的，就是计算机工程师了——他们不仅要追根溯源，找到问题从哪里来，还要与时间赛跑，反复多次调试新的代码；倘若半夜遇到服务器瘫痪，召集计算机工程师又要花费一段时间。
特别是，当丰富的经验、关键的知识都只留在了资深工程师的头脑里时，这个过程又会被延长。
其实这个问题，对于初创企业，尤其是技术性组织来说非常关键，是需要在起步阶段就需要注重的事情——打造内部资料系统文档，随时将任何有价值的知识和企业路线规划等信息记录下来，之后每个加入的新员工都能通过学习这些材料迅速适应角色，掌握关键资源，而不至于因为无经验而拖慢团队的步伐。
但是情况没有这么简单，特别是对于初创企业而言，相比于产品研发、品牌营销、用户拓展来说，人手不足、事项繁杂，“抽出时间整理经验并记录归档”就会变得微不足道、能省则省；而一旦放松，这些宝贵的经验就会随着时间流逝被遗忘。
如何处理这个问题？本文用四个步骤，手把手教你打造内部文档系统，并且让其在公司发展中发挥最大的价值。
在一些技术性组织中，我们可以观察到这样的现象：早期的老员工们随着公司一起成长，他们对公司的基础设施、产品开发等极为熟悉，加上他们有着丰富的工作经验，新员工有任何问题都会第一时间寻求他们的帮助。久而久之，经验越丰富的员工就需要回答越多的问题，继而无法发挥自己的真正作用，去做具有更大回报价值的开发工作。
这就是公司没有总结内部文档，无法让经验形成可共享的文档所导致的。
但是，总结内部文档也不是一件简单的事情。你需要有人专门去推进，还需要这个主管人能够形成一套判断的标准；也不能让这项工作流于形式主义，比如有的公司对外的文档详细又规整，为客户提供了极为详细的产品介绍手册，但是内部的技术文档却一塌糊涂；另外，内部技术文档也不能过于“内部”，有时候需要其他公司的成功经验作为辅助借鉴，这样才能得到一部精要文本。
无论是初创企业，还是已经成型的大型组织，想要打造一个高效、全面的内部文档系统，都需要从文化转变开始，一步一个脚印。
文档方面的工作常常会落入一个十分尴尬的境地：觉得做了挺好，甚至很有必要，但就是一直腾不出时间来，但直到真的出问题了，才想起来它重要。
更关键的是，不但要做，而且一开始就要做好。试想，当你对着错误的经验手册修复错误，只会引起更糟糕的问题发生。
那么要招聘专人来执行吗？如果是初创企业，建议你从团队或企业文化着手，用小投入带来大影响。可以分为以下三个关键步骤：
1.树立良好的写作文化
要想把写作融入企业文化，最有效的方法就是确保从创始人到一线管理者，大家都能认真对待自己写的东西——要准确、高质量。具体写什么内容？你可以：
定期分享总结。对于管理者来说，可以写会议要点与后续跟进方案——管理者分享自己在会议上的记录要点与后续行动纲要，会激励其他人效仿。
靠近本质的思考。你最近学到了什么？你怎么看公司当前的目标？你们最近在战略上做了哪些调整？定期分享这些思考，不仅能让大家在思考时更注重决策的背景，也同时强调了写作与分享知识的重要性，这些都会慢慢渗透进组织文化当中。
2.养成编辑的习惯
有员工觉得自己不会写文章，怕写得不好被批评，所以会抗拒写作。这个时候，管理者的“编辑”角色就极为重要——要给他们提供具体的修改意见作为反馈，让他们逐渐习惯记录自己的工作；引导他们去阅读写得好的案例，帮助他们分析为什么写得好……总之，要鼓励他们多写多分享。
3.让写作成为工作晋升要求的一部分
很多领导者急于修复有缺陷的内部文档系统，会直接从战略入手，比如试图打造一个完美的内部流程，将文档纳入软件开发周期，或者换一个工具，希望如此便能解决问题。
但更确切地说，应该从更上游的地方开始抓：招聘和内部晋升体系。如果在招聘职位描述和内部晋升体系里就写明对知识共享的要求和期望，人们在代入这些角色的时候，就会自然而然倾向于把它当作份内事去做。
当你开始执行相关规定后，员工们必然需要一个具体的文档写作要求。以下是几个岗位层级的要求，供你参考：
初级工程师：做好代码相关的文档工作，如相应的代码注释和README文档。
高级工程师：做好服务和系统的文档工作，如相应的图表和端到端指南。
技术部管理：做好整个团队的文档记录与管理，落实从代码评审到事件评审的制度。
工作要求与绩效评估及岗位晋升挂钩后，员工便会优先考虑这方面的工作。在实际执行后，就会有人提出新做法来提升效率。比如建议在办公系统中集成一个可查的文档合辑，大家有什么问题一搜就能找到相关答案，这时你就可以不断改进你的工具和标准。别忘了将它综合进员工们的绩效考核中。
除了业绩考核方面，平时也可以有些鼓励积极性的做法，比如积极表扬每周在这方面做得不错的员工等。另外，还可以专门留出时间来共同研究怎么更好地实现文档，或者就这方面的贡献度做个排行榜，以此刺激大家。
即使转变了文化，你可能还要面对之前的文档系统方面的问题，你要先处理好它们，才能推进下一步。
这件事情急不得，必须循序渐进，才不会“翻车”。首先要确定最关键的问题，你可以直接向工程师们发调查问卷，或者看看日常办公软件里被问得最多的问题是什么——可能你会搜集到100多个不同的反馈，但一开始，你必须先集中精力解决最迫切的5到10个。需要注意的是，不要自己去假设人们需要什么，你想的可能会和工程师们需要的完全不同。
有的放矢、先解决最关键问题的附加好处是，你会更快取得更有意义的进展，并开发出高质量的文档范本，供组织中的其他人参考效仿。
1. 设定标准时，要更注重质量
在一开始让工程师们做文档时，大多都会需要参考范本。所以，这时候就需要你将主要精力和资源都投入到撰写一份标准的黄金范本上，这样你们的整体水平也会逐步提高，体系也会在这个基础上搭建起来。
你还可以增加这两个方面的标准：代码标准和术语表。树立统一的代码标准，可以有效减少开发和代码评审所需的时间，并且你们的代码库也会高效规整得多；每个公司都有自己系统和服务的术语，所以非常有必要建立一个对应的术语库，来减少分歧。
2. 像记者一样去写
当然，相对简单的主题处理起来可以直截了当，但大多数的问题都很难找切入点。所以，你可以找一个真正的“技术权威”去替代各种技术备忘录、电子邮件、内部通讯软件上的信息碎片。
找那些经验最丰富的技术专家，和他们坐下来，一起在白板上列出相应的要点。如此，就有了文档的雏形，之后再相应分配对应的工程师去有针对性地细化。用不了多长时间，就能整理出一套可靠的、前所未有的技术文档。
同样的做法也可以应用到更复杂的文件编制工作中，比如服务器架构的搭建。优秀的文档写手就像记者一样——跟着线索脉络，填补空白，写出完整的故事。
3. 发挥资深工程师的作用
让团队某一个人来专门负责文档方面的工作的同时，还要充分发挥资深工程师的作用。他们一方面知道文档的重要性，但另一方面往往意识不到自己的影响力。所以，只要公司提供了平台，其他人就能跟着他们形成规范。
你可以先与高级工程师充分沟通，就如何建立一个更稳固的文档文化达成共识，然后持续对话来不断强化这些新的操作规范。比如在架构讨论和代码评审过程中，让高级工程师来负责强化文档操作规范。用不了多长时间，大家就会习惯这种新的规范，而不觉得是额外的义务。与此同时，新加入的成员也会相应遵守。
养成记录的习惯只成功了一半。以一种有逻辑的、易检索的方式来组织你的文档则是工程团队面临的另一个重点。如果没有相应的管理系统，工程文档只会越积越多，最终混乱无序，无法分清哪些是最新的准确版本。
这些工作对很多团队来说可能有些难以推进，其关键在于找到一种人们可以便捷搜索过往资料的办法，然后建立体系，这要花费大量的时间和精力。但它却是四两拨千斤的好事，相对小的付出就能获得极好的效果，特别是那些本身还犹豫要不要投入人力物力去做文档系统的组织——先考虑文档系统的架构，而不是一上来就让大家写文档，可以在相对较短的时间内产生更广泛的影响。而且，这件事情本身并不涉及太多新的背景知识的学习，只需要清点现有的内容，合并重复的，删除过时的，清理和更新一些重要的，然后将它们规整成体系即可。
1. 整理清单
从组织的基本要素开始，把所有的重要文件都列出来，放到一个电子表格里。落到表格上会让一切变得更清晰，同时它也相当于一个目录，方便你之后把文件归档归类进内容库。
在这个阶段，你可以尽情按自己的想法去整理，哪些文件是多余的、哪些方面的内容还有空缺，以及是否可以规整出一个更好的结构等等。此外，你还可以将它发送给其他人，获取反馈，这比让大家各自整理要好得多。
在搜集文件清单的过程中，可以留心以下五大类文件：
新员工培训文档。入职培训的文档可以为新员工提供有效的学习路径。随着团队的发展，要求每位新员工写下他们在最初几个月学到的东西。每次招聘新人就在之前的基础上继续完善知识体系。用不了几轮招新，你们就会拥有一份相对可靠的入职培训指南了。
操作指南类文档。例如，指导内部员工建立新节点、整合新界面或者使用新功能之类的说明性文档。
运行手册。比如如何以特定顺序执行一组任务，来完成诸如启动新服务器或解决常见错误之类的操作。
架构和设计文档。这是骨干文件，为所有其他文件和知识获取提供有用的背景信息，人们据此了解整个系统的工作逻辑。
团队百科类文档。包括会议记录、备忘录、思考、建议等。这些文档的记录可以随意一些，但注意与上述其它类型的文档区分开来。这些是团队快速获取和分享知识的非常宝贵的资源，但它们可能非常杂乱。
可能归整整个工程部门的各种文档到一个电子表格中难度太高、文件太多整理不过来，那不妨就整理一份前50个最常用的文件的清单，因为有总比没有好，即使是再简单的归类整理也会有好处。你也可以先整理最重要、最常用的那些文档，剩下的有空再慢慢整理。
2.确定责任人
很多时候，人们花费了大量的时间归整，记录了很多条理清晰、方便易用的文档，但却忽略了相当重要的一个部分：作者的名字。署名会让作者更重视、更负责，与此同时，当后期文档需要更新时，也能找到对应的责任人或团队。
你还可以开发相应的元数据标签，在上面署名团队或作者的名字，同时开发通知功能，定期通知文档负责人维护或评审文档的更新。而随着公司的发展，每几个月可能会有一次组织变动，到时可能会有新的团队名称，也需要做相应的维护，或者打造更复杂、自动化的系统亦可。
除此之外，为了让事情运转得更顺利，还需要指定一名专职或轮值的主负责人，不能是各部门或各组织的内容各自为政。如果每个团队自我负责的话，那大家可能就不太会在意团队间以及整个大集体的利益。
3. 敢于删除精简
想要保持文件系统规整，最重要的是让人们学会删除。冗余文件常常造成干扰，影响搜索效率。删除精简是为了让系统变得更高效，而且如果文件已经完全过时，弊就会大于利。
4. 做更好的目录页
电子表格文档整理做好之后，必须要制作目录索引，这件事情是小投入大回报的事情。当内部搜索引擎水平有限的时候，好的目录页就能发挥巨大作用。
到目前为止，我们已经讨论了：通过补充欠缺的文档和调整文件系统结构来解决之前欠下的文档债的问题；降低检索和管理的难度。但要真正把这件事情做好，还需要调整习惯，让被动记录转变为主动记录与管理——也就是说，要在开发的同时就把文档编写好，而不是留到写完代码发布完之后。
但是，有时时间紧迫，代码都是在最后期限才完成，大多数团队就会把文档类的工作拖延到功能发布之后。但你要知道，总会有新的事情冒出来，你就会拖延着不去写文档，计划会永远赶不上变化。
与其在开发完成之后，面对着空白文档从头开始回忆做记录，不如在边开发的过程中，边留存快照记录。快照可以是操作截图——到时文档的使用者也可以参照的具体流程指引。早期阶段，这些快照文件可能杂乱无章，但却比事后回忆更准确。此时也还不需要补充什么背景信息，就如实说明使用者应该参考快照怎么操作、输入什么即可。
这种做法不仅能最终为你的团队节省大量时间，还能让你们少走弯路，做出更好的产品。比如你们的文档记录会更可持续，还可以不断迭代，在过程中，帮助你们更好发现一些平时可能没注意到的细节，了解产品在其生命周期的每个阶段都需要什么来取得成功。你开发产品的时候可能觉得整体的使用流程很简单，但如果你在过程中有做每一步的记录，最终当你发现，居然要25次操作才能获得一次结果时，你就知道你需要再做调整或精简，把它降到5次操作。
加载中,请稍侯......