技术写手在公司成功中的角色

我见过太多公司把文档当作“事后补”的活儿，结果产品上线后，客户和内部员工一起抓瞎。说实话，文档不是摆设，它是企业知识的骨架。尤其在做企业 Wiki 建设时，你会发现，一份结构清晰、更新及时的知识库，能同时服务客户、新员工和跨部门协作。技术写手就是那个把散落的信息织成网的人。

发布有缺陷的软件后果可能是灾难性的。仅在美国，低质量软件造成的经济损失就以万亿美元计，而且每年都在增长。如果觉得难以置信，我们来看一个例子：2018年，日产因后视摄像头的软件缺陷召回了超过100万辆汽车。这个缺陷虽小——允许用户关闭摄像头图像，导致下次倒车时图像保持关闭——但它违反了联邦交通法规，不得不召回。为了避免这种情况，所有软件在上市前都会经过彻底测试。测试流程验证软件是否按设计运行，每个用户操作是否产生预期结果，不会引入问题甚至伤害用户。这些测试分多个阶段，包括自动和手动测试，目标是覆盖每一个角度。测试由专门的软件测试人员或QA专家执行，但他们并不孤单。因为技术写手需要非常熟悉他们要记录的产品，他们必须彻底测试所有功能，像最终用户一样使用产品。这样一来，他们提供了额外的手动测试层，有助于开发团队在产品交付给客户之前发现更多错误并打磨功能。在2021年 Write the Docs Symposium 上，IBM iX DACH 的软件质量工程师 Ines Stefanović 指出了测试人员与写手之间的相似性：“大多数公司实际上希望自己的软件产品能被描述得易于理解。为了做到这一点，技术写手需要深入理解产品。还有什么比像用户一样测试/使用它更好的方式呢？”通过探索产品并在文档记录过程中报告问题，技术写手的工作增加了软件上市后的质量水平。

员工刚加入公司时，他们的处境与最终用户非常相似。他们需要快速高效地学习产品以完成任务。过去，经理和同事负责向新员工传授经验并帮助他们入职。然而，工作场所的变化（如自动化和远程工作的兴起）大大减少了面对面培训的比例，这意味着员工不能总是依赖主管和同事来演示如何做事。例如，新研究表明，经理总共只花大约14小时进行新员工入职培训。因此，员工认为经理在入职流程中变得低效也就不足为奇了。幸运的是，这是另一个技术写手能发挥巨大价值的敏感领域。因为他们创建的材料旨在帮助用户了解公司产品的方方面面，所以他们对于初次接触产品的新员工也极有帮助。这几乎适用于任何部门或团队的新员工。例如，假设你正在客户支持部门入职一名新成员。经理不必坐下来手把手培训，只需让员工访问软件，借助技术文档学习如何使用。当支持人员开始与客户合作并遇到问题时，他们可以继续依赖文档来提供答案，而无需就每一个不立即知道答案的问题联系主管。故障排除指南等资源在这方面对新手非常宝贵。充分的文档甚至可以帮助团队中的新开发者熟悉产品背后的代码，使他们更快地进入状态，并减少资深开发者的参与。事实上，新开发者经常在开始新工作时感到沮丧，因为他们需要处理没有文档的代码。然而，有了高质量的开发者文档，新开发者就有了更轻松的起点，可以更快地掌握要领。一些非常有用的资源包括：安装/下载/快速入门指南、Hello World 教程、错误码。这些文档通常包含开发者着手处理新代码时最常见问题的答案，因此它们充当了培训资源。总而言之，你的技术文档不仅对外部用户有用，对团队中可能还不熟悉产品的新成员也同样有帮助。这意味着技术写手在培训员工中扮演直接角色，而良好的培训对公司成功至关重要。

现代企业面临的最隐蔽的问题之一是孤岛心态。这个概念指的是公司内部各部门变得自成一体，逐渐停止互相沟通。孤岛对公司极为有害，因为它扼杀了合作，使部门相互对立，并造成重复的实践和流程，而不是统一的工作方式。你可能认为你的公司没有孤岛风险，但事实上这个问题比许多人愿意承认的要普遍得多。如今，近半数的公司和组织已经注意到这个问题。公司要取得真正的成功，需要团队和部门协同合作，因为每个部门都为产品的质量和价值做出贡献。幸运的是，技术写手在凝聚团队、确保公司有一个单一的知识来源来指导和引领各部门工作方面可以产生奇迹。让我们看看一些例子。在编写技术文档时，技术写手可以征求项目中相关利益方的意见，以确保文档包含从公司专家处收集到的最佳信息。如果使用高质量的文档软件（如 Baklib），技术写手甚至可以在文档创建过程中利用软件的协作功能直接在文档中征求反馈。在这种情况下，技术写手充当了团队之间的调解人，收集专家的关键知识，确保各部门就功能如何满足用户达成一致。因此，通过文档实现了产品的一致性。另一个例子是技术写手与主题专家（SME）合作创建技术文档的方式。写手通常会对SME进行访谈，收集诸如产品满足用户哪些需求、用户使用产品需要哪些前提条件等信息。