工程

投资于内部文档:创业公司的一砖一瓦指南

午夜时分,随叫随到的工程师突然惊醒,因为他们的手机闪烁着,并发出一连串的推送通知、短信和电话。生产服务器宕机了,他们有责任尽快将其恢复。带着模糊的双眼和模糊的头脑,这位工程师疯狂地在Slack、Google Docs和GitHub上搜索答案,但它们只会模糊地提到这个错误。由于没有任何有意义的信息可供参考,他们被迫焦急地等待其中一位资深工程师醒来,因为故障还在继续。

关键任务知识被困在早期员工的头脑中,这是一个非常普遍的问题,初创的工程组织都很清楚。但是投资于内部文档通常是一个先有鸡还是先有蛋的问题。在创业初期,这是一个千载难逢的机会,当你获得宝贵的知识和规划你的路线时,你可以把事情写下来。每一个加入的新员工快速承担了大量的责任,这些文档可以成为快速启动和运行而不减慢业务节奏的关键资源。

但由于待办事项清单长得令人困惑,团队规模又小,腾出时间记录这些经验教训很快就变成了愿望清单,而那些最好的计划也会随着时间的推移而消失。如果把这些重要的见解放在次要位置,它们就会随着时间的流逝而消失。

作为Stripe、Uber和Salesforce等公司的早期文档负责人,大卫Nunez已经看到这种循环一次又一次地重复-他经常被要求清理内部文件债务。(本着言出必行的精神,努涅斯甚至写下了他的经验教训,与人合著了这本书。开发者文档,一本技术写作手册。)

像Stripe这样的公司已经将令人愉悦的开发者文档作为拥挤市场中的秘密武器之一。但努涅斯一次又一次地看到,有一个共同的模式困扰着各种各样的初创公司。“很多早期员工成为了公司的英雄。他们构建了许多功能,解决了重大故障,并提出了改进基础设施的新方法。随着公司的发展,越来越多的人加入进来,在没有书面记录的情况下,那些守旧的人会受到问题的轰炸。这造成了一个恶性循环,新员工快速认识到,最快的方法是得到答案就是去问那些守旧的人,”努涅斯说。”突然间,这些早期英雄最初所传达的价值,即建造和运输,他们现在所拥有的时间更少了.”

另一个常见的陷阱?由于文件的本质是内部的,因此很难借鉴其他成功公司的既定剧本。像Stripe和亚马逊因其写作文化而闻名那些有前途的创业公司羡慕不已——但是如果你想复制他们的方法,没有明确的路线图可循。

“模仿其他公司在这方面做得很好本身就比较困难,因为文档是隐藏在内部的。相反,你会看到一位首席执行官与Stripe或亚马逊的领导会面,回来后说,‘文档真的很重要——我们将专注于此。“初衷是好的。但没有明确的、实际的方向或贯彻到底,”努涅斯说。

当一个创始人要求更好的文档是一个优先事项时,你需要有人在第一线为成功建模并指导实现。否则,你会在几个月后放弃一些零碎的努力。

需要明确的是,努涅斯并不是只针对处于早期或中期阶段的初创公司——大公司也可能在创建文档等级制度方面同样有罪。“如果你去任何一家有意义的成功公司,他们至少会有可以通过的外部文档,比如入门指南或故障排除说明,因为用户依赖于它。但一次又一次,你看到企业公司有100名技术作家和20人的工程团队在做外部文档——但没有人在做内部文档,比如解释系统架构是如何工作的,”努涅斯说。

在这次独家采访中,Nunez概述了创建良好内部文档卫生文化的具体步骤。从他自己作为Uber第一个专门的文档招聘和Stripe第一个文档内容主管的经验中,他分享了这个过程的每个部分的超级战术建议:从养成习惯和激励工程师努力,到保持事情的条理性。虽然他的指导是专门针对没有专门文档团队的初创公司的,但对于那些偏离了方向、想要纠正方向的大型组织来说,也有很多策略。

如果您将赌注押在文档上,那么您公司发展的下一个阶段将从获取这些知识的核心中受益匪浅,否则这些知识将在以太中丢失。

第一步:从文化转变开始。

文档通常被视为一种“有就好”的东西——一种可以在“您有空闲时间”之前搁置的东西,或者更糟的是,直到一个关键的中断迫使组织不得不考虑它。努涅斯说:“很多时候,当一些可怕的事情发生,事情完全出错时,人们才意识到需要文档资源。

如今,优步以在新城市推出服务时精心部署内部剧本而闻名。员工们可以在一个没有优步足迹的城市着陆,手里拿着一本装满了旧金山和纽约成功案例的手册。但是,尽管这些早期的胜利,该公司还是得到了一个痛苦的警钟,他们需要在内部文档上投入更多。

努涅斯说:“在优步,我们开始关注文档和收集一些资源,但工程团队的发展速度远远超过了文档团队的发展速度。“然后,由于中国的一个数据中心过热,出现了停电。一名工程师按照操作手册中的步骤操作,他们实际上使停机情况变得更糟,并完全熔化了数据中心。”

根本原因分析发现了一个不太可能的罪魁祸首。“这份手册不准确,步骤排列混乱。这份手册显然写得非常潦草,它唤醒了领导层,我们需要掌握我们的文档标准,”努涅斯说。

似乎最直接的解决办法就是雇人来解决问题。努涅斯建议采用一种不同的方法,而不是开始招聘冲刺来寻找你的第一批文档员工。“默认情况是,公司资源不足的文档工作,当然,导致弱文档。但我也看到一些公司确实在文档上投入了大量资金,但没有在正确的领域或正确的方法上,所以工程师不会经常使用文档,”他说。

我不建议早期创业公司直接雇佣全职文档写手.我认识到,尤其是在高绩效环境中,改变企业文化是你能做的最高杠杆投资。”

如果您首先处理编写和维护文档(或缺乏文档)的激励和奖励,您将很快看到有意义的进展。

改变企业文化似乎是解决一个复杂问题的一种模糊、不切实际的方法。但努涅斯概述了开始的两个关键步骤:

养成良好的写作习惯。

没有强大的写作文化,就不可能有强大的文档文化.我发现,将这一点融入企业文化的最有效方法是,确保从创始人到一线经理的领导者,认真对待自己的写作努涅斯说。

我见过一些高管写的电子邮件都是小写的,充满了缩写和拼写错误,这给人的印象是,他们写一封低质量的电子邮件所节省的时间比别人破译它所花费的时间更有价值。不仅人们会对糟糕的可读性感到沮丧,而且其他员工也会学会不把写作当回事。

试着从这两个习惯开始:

定期回顾。“对于领导者来说,提高并展示自己的写作和知识分享技能的最有效方法是更认真地对待会议记录和后续行动。分享你自己的行动项目和从会议中得到的收获会给其他人一个推动,让他们效仿你的行为。”

获得生存。“你最近学到了什么?”你对公司当前目标的理解是什么?你最近对战略做了什么调整?有规律地分享思考提供了重要的背景,也强化了写作和分享知识的重要性,这将渗透到组织的其他部分。”

养成编辑的习惯。

“回到学校,你通常会遇到考卷组的工作人员,当考试是多项选择时,他们会很高兴。然后是写论文的人,他们很高兴能写一篇论文。通常,这是非常两极化的,”努涅斯说。“那些认为自己不是伟大作家的人往往写得越来越少,而且害怕自己的作品受到批评。”

但编辑对写作过程至关重要——无论你是天生的散文高手,还是在学校里总是害怕写文章。“多年来,每个职业作家的作品都受到过来自教授、同事和同龄人的批评。他们接受创作高质量的作品只是写作过程的一部分。让别人批评你的写作是一种很脆弱的处境,但是练习你的写作并获得反馈是进步的唯一途径。”他说。

我的一位前工程领导曾经说过:“黑客和软件工程师之间的主要区别之一是记录工作的能力。”

希望提高自己写作能力的英语专业人士,努涅斯建议进行一些逆向工程。“在公司内部或外部寻找优秀的写作范例,并试着找出它如此有效的原因。他们是如何如此清晰地传达信息的?他们是如何很好地保持你的注意力的?语言简洁吗?他们写了引人入胜的介绍吗?努涅斯说。

当你在处理自己的文档时,试着引入一个测试用例。“一个简单的练习是把你的文件草稿交给同事,让他们解释他们读到的内容。如果他们感到困惑,你知道你还有工作要做。如果他们理解了你想要表达的要点,你就实现了你的目标,”努涅斯说。“不要太执着于成为一个天生的作家——专注于成为一个伟大的编辑自己的作品。”

让写作成为职业阶梯的一部分。

急于修复有缺陷的内部文档,许多领导者直接采取策略——试图建立一个完美的过程,将文档融入软件开发周期,或者换出一个工具,希望它能解决问题。

相反,从上游开始:从招聘和招聘开始促销活动流程.努涅斯说:“我发现,如果你把知识共享的期望写入职位描述和职位阶梯中,人们就会自然而然地希望在自己的阶梯上履行这些职责。”

通过试验和错误,他现在提倡从这一步开始您的文档工作。“优步一度在修改软件工程的阶梯。我能够与领导更新工作的工程师合作,我们在每个级别都设置了文档期望。一夜之间,人们都来找我们说,‘我想达到人们对我的角色的期望。我该怎么做才能满足这些要求’这就像一个灯泡熄灭了,”努涅斯说。“所以当我加入Stripe时,我在第一周就迈出了这一步。我在工作阶梯的每一层都写了一行关于文件的内容’”努涅斯说。以下是他对语言的建议,你可以在自己的职业阶梯中借鉴:

IC应届毕业生:确保您的代码有良好的文档,有有用的代码注释和readme。

高级集成电路:确保您的服务和系统有良好的文档,有图表和端到端指南。

Eng领袖:确保您的团队有良好的文档实践,从代码审查到事件审查。

随着绩效评估和晋升的出现,人们开始优先考虑这类工作。“我很快就看到了许多不同的文档想法和项目,这些想法和项目是我自己不会考虑的,它们来自于一个工程组织——比如构建一个Slack集成,在提出问题时自动推荐相关文档。只要告诉工程师,‘这很重要——你正在为此接受评估。’然后看看会发生什么他说。

Nunez还建议团队尝试另外两种战术思路:

即使在业绩评估季节之外,也要让自己成为焦点。一位经理在她发送的每周更新中都附上了他们的“本周文档之星”。把别人说出来是一件很容易的事,人们喜欢被认可——尤其是在他们的舒适区之外做一些事情。”

挤出时间。他也见过其他团队进行“文档大打击”(比如bug大打击),整个团队会花一天甚至一周的时间来处理文档。“制作一个排行榜,看看有动力的工程师如何做出贡献。”

第二步:开始用MVP方法偿还你的文档债务。

即使有了文化上的转变,你可能仍然面临着大量的文件债务,这些债务是在几个月(或几年)不优先考虑这项工作之后积累起来的。这可能感觉就像试图让一辆16轮大卡车突然掉头。

努涅斯建议慢慢驶过这个弯道,以免卡车翻倒。首先确定要解决的最关键的问题。“给工程师们做一份调查,或者看看Slack上最常见的内部问题。你可能会有100多个主题,其中有工程师抱怨的糟糕文档,但在开始时,你必须将大部分资源集中在一个狭窄的焦点后面。试着找出工程师们最纠结的5到10个技术主题,并在这些领域进行投资他说。

不要急于对人们的需求做出假设。努涅斯说:“当我们刚开始在优步开展这项工作时,我们查看了内部数据,看看工程师们最想搜索的是什么,这些数据真的让我们大吃一惊。”

关注工程师每天真正需要的东西,而不仅仅是你每天需要的技术认为他们需要支持。

“我们发现工程师们在服务器配置和管理中不得不使用一种晦涩难懂的技术。在大公司,你会有一个运营管理人员或一个专家团队,他们在这个软件方面有专业知识,但在创业阶段,每个工程师都需要在某些时候使用它来部署更改。这对他们来说很可怕,因为如果工程师做了错误的改变,他们可能会导致服务严重中断——而这种情况经常发生,”努涅斯说。“我们确定了这一需求,加强了文档,整合了反馈,并立即看到有关该主题的投诉减少,并且在停机事件的根本原因分析中大大减少了对该软件的提及。”

大卫·努涅斯摄
David Nunez, Stripe和Uber前内部文档负责人,《开发者文档》合著者

注重质量,而不是数量来设定标准。

作为奖励,通过确定最关键的主题,您将更快地取得更有意义的进展,并开发出组织中其他人可以模仿的高质量文档示例。“当你开始关注文档时,工程师们会说,‘我以前从来没有做过这个。给我举个例子。通过在更少、高质量的资源背后投入更多的努力,你向人们展示了什么是“伟大”。你可以很快地提高下限,”他说。

很多时候,创始人告诉我,“我甚至不知道从哪里开始写文档,这太可怕了。”当我告诉他们只关注一个其他工程师可以复制的好例子时,他们松了一口气。

他分享了自己在优步(Uber)的日子里建立肌肉记忆的一个例子。“一开始,我们只是从一份关于如何设置环境和开发盒的文件开始,这样你就可以开始提交产品代码了。这是每个新工程师都必须完成的任务,没有文档,人们只是坐在房间里帮助新工程师手动完成,”努涅斯说。

Nunez表示:“一旦我们帮助该团队创建了清晰的入门指南,该指南组织良好且易于阅读,我们就可以将其作为其他团队希望偿还文档债务的黄金参考。”其他关于开始编写文档的想法包括:

代码风格指南:标准化你的编码风格可以减少开发和代码审查期间的认知开销,并创建一个更干净的代码库。”

术语表:“每家公司都有自己的系统和服务术语和方言。创建词汇表是为重要定义创建真实来源的一种简单方法。”

扮演记者的角色。

像设置开发环境这样的简单主题可以相当直接。但是其他的(比如Nunez之前关于一个神秘的服务器管理技术的例子)要开始捕捉可能要复杂得多。努涅斯建议,与其寻找混杂着电子邮件、Slack信息和电子邮件的过时备忘录碎片,不如找到一个真相来源。

“我们会和对这个话题最了解的人坐下来,用白板把要点写下来。然后文档编写者会有一个文档的起源,可能还有一些其他工程师的名字作为更多信息的线索。很快,你就可以发布一个工程师可以依赖的文档集,这在以前是不存在的,”努涅斯说。“我们有一个作家,她能很快地写出文件,因为她会记录与工程师的会议,将音频转录成文本,然后在开始制作下一个文件之前对其进行整理和发布。”

你也可以将同样的做法应用到更复杂的文档壮举中:“在Uber,我们没有规范的文档或图表来说明我们的服务架构是什么样子的。事情的发展和变化是如此之快——每个人的描述都不一样。这是有问题的,因为当你不知道所有的部分如何组合在一起时,你无法构建安全性和可靠性,”努涅斯说。

“我们从一位知识渊博的终身工程师开始,他和我们一起在白板上进行理论分析,并描述事情是如何发展的使用去工作。然后我们用这个作为基线来寻找其他可以帮助填补空白的人。在几周内,我们就有了一个非常好的架构文档,同样重要的是,我们有了一个准确的图表,工程师可以了解系统的运行情况。”

伟大的纪录片作家就像记者一样——跟随线索,填补空白,创造一个完整的故事。

授权你的高级工程师。

当你从文档债务中爬出来的时候,Nunez强烈鼓励把资深的人带进来,而不是在团队中指定一个人作为文档代理。

“教育你的高级工程师,听听他们需要什么来帮助建立一个强大的文档文化,并保持对话以维护这些新的规范。让高级工程师在架构讨论和代码审查期间执行文档标准是在开发生命周期中巩固文档的好方法。很快,它将变得如此普遍,以至于工程师们甚至不再认为它是一个额外的步骤。新加入的工程师也会很快跟进。”

我参与了各种类型的剧本计划,将文档编入开发过程,但最有效的是动员您的高级工程师。他们知道文档的重要性,但通常没有意识到他们有一个声音和平台来让其他人跟随。

第三步:停止随意的记录行为,组织起来。

养成把事情写下来的习惯只是成功的一半——以一种合乎逻辑、易于搜索的方式组织文档是工程团队面临的另一个绊脚石。如果没有一个一致同意的组织系统,你会发现自己有一堆越来越多的文档,没有什么是最新的和准确的。

“这对许多团队来说都是可怕的,因为这与写作无关了。现在你必须弄清楚人们如何才能找到它。我也了解到,对于工程师来说,上信息架构的高级课程是非常困难的。他们甚至不想开始,因为他们意识到他们无法想象最终的状态是什么样子,但他们知道这将是很多工作,”努涅斯说。

但是管理和组织内容可能是一个重大的胜利——特别是对于那些对文档是否应该优先考虑有点犹豫不决的组织。“如果你首先专注于管理,而不是试图撰写大量的网络新文档,你可以在相对较短的时间内产生如此广泛的影响。”你不需要太多的背景就能做好。盘点现有内容,合并重复内容,删除过时内容,清理和更新一些重要内容,然后将其组织成一个整洁的结构,”努涅斯说。

这些可能看起来只是表面上的改变,但它们可以为你的钱提供一个大爆炸。他说:“它允许工程师更容易地找到和理解重要的文档,这将立即显现并提供即时价值——这将允许您在更好的工具、流程甚至专用文档资源上投入更多资金。”

整理你的清单。

从组织基础开始,而不是试图过快地变得过于复杂。”只要把你列出的所有重要的文档放在电子表格中,努涅斯说。这里的目标是将所有内容集中在一个地方,而不是让人们进行“随机的文档行为”,从而变得杂乱无章。

“这给了你一些湿粘土来想出一些结构,并最终将这些文档迁移到内容存储库。但就目前而言,您可以在电子表格中快速识别哪些文档是多余的,如果有任何明显的差距,以及更好的结构的机会。这是非常低的风险,因为你只是处理一些url,你可以从人们那里得到反馈,但这比无数人把文件放在他们想要的地方要好得多,”努涅斯说。

当你在寻找要添加到电子表格中的文档时,请记住大多数规模较大的公司都存在这五个文档桶。(努涅斯指出,规模较小的初创公司可能还没有具备所有这些技能。)

新员工培训文档。这些类型的文件经常被忽视,但它们与任何其他类型的内容一样重要,甚至更重要。努涅斯说:“入职文件为新员工创造了一条有效的途径。他建议采用一种简单的、非结构化的方法来开始:“随着团队的发展,要求每位新员工写下他们在最初几个月学到的东西。每次招聘都将建立在之前记录的基础上。经过几次招聘,这是一个非常可靠的入职指南,”他说。

人们很容易这样想:“我挺过了头六个星期,学会了为自己找到所有答案。”下一个人也会明白的。”但这肯定会拖慢你的新员工,限制他们的影响力。

基于任务的文档:例如,为内部用户提供有关如何构建新端点、与接口集成或使用新功能的说明。

运行手册:如何以特定顺序执行一组任务,以执行常见的操作任务,如启动新服务器或解决常见错误。

建筑及设计文件:这是骨干文档,为所有其他文档和知识捕获提供有用的上下文,描述系统如何工作。

维基风格的团队文档:包括会议记录、备忘录、沉思、提案。努涅斯的建议是:“自由地写这些文档,但要把它们与上面列出的其他文档分开。这些都是团队快速获取和分享知识的重要资源,但它们可能非常嘈杂。”

如果在整个工程部门查找各种文档并将其添加到你的电子表格中似乎是不可能的,他将其归结为简单的行军命令。“有策划和组织总比没有好。如果你不想整理成百上千的文档,为了快速获胜,只需查找前50个最受欢迎的文档。这可以在一天内完成,并产生立竿见影的效果努涅斯说。(大多数内容工具都有一些开箱即用的分析功能——或者如果你将文档存储在数据库中,你可以运行查询来获得这个列表。)

我发现大约10%的文档获得了大约90%的页面浏览量。如果你的资源紧张,只关注前10%,忽略长尾,直到你的房子井然有序。

确定所有权。

你可以花费数小时的时间来编写一份详尽、清晰的文件。但很多时候,人们忽略了一个最重要的组成部分:作者的名字。努涅斯说:“你可以用一个分类账来记录哪个团队拥有哪个文档,但即使你在文档的顶部手动输入一个团队的名字,你也会创造更多的问责制,而且如果文档需要更新,人们也可以追踪到这个团队。”

对于那些想要升级的人,他建议在页面的元数据中分配一个团队,这样就可以自动通知所有者按照预定的节奏或代码更改来检查他们的文档。“随着公司的发展,你每隔几个月就要进行一次重组。球队的名字会改变,或者队员会轮换。这时你就会想要建造一些更复杂的东西,”努涅斯说。

分配一个轮换的文档负责人。

为了保持文档的集中化和可访问性,不仅要确定每个文档的中心所有者,还要确定中心电子表格的中心所有者,这是必不可少的——即使你还没有准备好聘请专门的文档。”如果您有10个团队负责他们自己的内容组织,那么没有人会关注这10个文档集如何形成一个内聚的整体努涅斯说。

他概述了一个例子,说明了为什么这可能会导致心痛:“在基础设施项目中,工程师通常希望执行端到端的任务,他们可能需要使用由多个团队构建的接口。如果文档被团队分割,那么完成这些端到端任务将是非常痛苦的。”

但是,如果没有特定的工程师或产品负责人举手要求拥有文档电子表格,可以尝试一种公共方法,由一个轮流的所有者负责一周的监控和维护电子表格,然后再把这个角色交给下一个人。“你是基本的版主,你在寻找异常值,‘哦,有人为这个主题创建了一个新文档,但我知道这个文档已经存在了。’或者,‘有人把这个做成了主页的子页面,但实际上它应该嵌套在另一个页面下面,就在这里,’”努涅斯说。

不要害怕删除。

他对保持你的文档有条理的最大建议是什么?赋予人们删除的权利。“无论是意识到一份文件解释了一个不再存在的系统,还是一份文件完全过时了,人们害怕只是删除一个文档,即使这会让你的工程师感到困惑,并混淆搜索结果.至少,您应该将其存档。通过删除不再有用的东西,你正在使整个系统变得更好,”努涅斯说。

文档经常被搁置,因为创建它花费了太多的时间和精力。但如果它完全过时了,它就弊大于利。把它想象成一个花园,你必须修剪和旋转土壤来保持健康。

升级登陆页。

在完成了电子表格组织练习之后,Nunez非常支持将登陆页面作为升级的一种方式。“着陆页经常被忽视,但很容易制作,而且非常有价值。这些是每个主要用户决策点的路标。”“大多数内部中心只是一堆文件,你尽最大努力搜索你需要的东西。但是你的内部搜索引擎和你的内部内容的SEO可能很差。通过让内容更容易浏览来规避这个缺点。”

为了保持简单,尝试用这些登陆页面构建一个内部文档主页:

后端开发

前端开发

安全

度量和监控

存储和管理数据

第四步:将文档带入开发周期——不要等待代码完成。

到目前为止,我们已经讨论了通过记录丢失的文档并以易于追踪的方式组织它们来解决文档债务问题。但真正找到文档的天堂需要从被动的文档习惯转变为主动的文档习惯。这意味着要记录开发一个新功能,而不是等到发布后再保存。

但当面临时间紧迫的最后期限时,大多数团队倾向于将文档编制推迟到特性发布之后。或者,在努涅斯的案例中,有一次,他在全体会议上得知他的团队和其他所有人一起,要准备一份重要的文件。“有一次,我们的工程领导决定立即将我们内部认可的编程语言从7种减少到2种。对工程师的承诺是,用这两种语言编写的服务将被完美地记录下来。不出所料,在如此短的时间内,这一承诺未能在发布时实现

虽然很诱人,但将文档留到最后是交付劣质内容的最可靠的方法,这将使开发人员感到沮丧,并最终使产品的用户感到沮丧。“总有新的东西要做,而不是花时间记录你刚刚建立的东西。你要么在改进功能,要么在修复bug,要么只是完成代码,你不想再考虑它了——你在做下一件事,”努涅斯说。

说你要在发布一项新功能后进行记录,就像说你要在新年开始节食一样——它永远不会像你计划的那样奏效。

拍个快照。

Nunez称之为快照文档,这是一种在编写过程中记录文档的低成本方式,而不是在代码完成后盯着空白页面。“创建快照只是意味着写下作为用户完成任务所需的实际步骤。在早期阶段,这可能会很混乱,但它应该是准确的。你还不需要概念背景,只需要简单的步骤和输入,用户就可以使用产品完成你想让他们完成的任务。”

这将为你的团队节省大量的时间和挫折,并最终产生更好的产品。“这不仅能让你采用更可持续和迭代的方法来处理你的文档,而且你还能获得有价值的见解,了解如何在产品生命周期的每个阶段取得成功。产品可能看起来很简单,但当你记录成功的步骤时,你可能会发现完成一项任务有25个独立的步骤,你想把它们减少到5个,”他说。

文档的迭代草稿作为摩擦日志非常有用,因为它们可以作为用户必须处理的复杂性的预览。

总结:开始吧。

就像找不到适合市场的产品、组建早期团队和其他创业公司的“第一”一样,没有一种方法可以构建你的文档流程。“在加入工程机构成为他们的第一个文档招聘时,我首先从制作网络新内容开始,或者管理,或者实施更好的工具,我首先从布道开始。要想获得更好的内部文档,没有一个‘正确’的切入点——这只是一个开始。”他说。

所以当你开始偿还你的文档债务时,保持一个MVP的心态——打好你的基础,一砖一瓦,而不是试图一天建成罗马。