“甚至讨论这一点[都]令人难以置信地沮丧。”
这是发送给全公司的一封电子邮件中的结束语——这封邮件反对我在 Red Hat 目前职位上任职两个月后做出的一个决定。休假回来后的第二天，阅读这封邮件以及大量类似主题（以及一些更生动的）的邮件，让我清醒了很多。我读的越多，就越意识到，除了对我所做的决定以及我的团队执行的方式持高度批评态度之外，这些电子邮件的作者还有一些共同点：他们是对的。
问题：不断变化的文档环境
当我开始在 Red Hat 担任目前的职务时，领导着全球团队，负责制作我们所有的产品文档和其他面向客户的内容，我很高兴有机会改变并在软件世界的一个变化非常缓慢的部分尝试新事物（尽管创新一直在我们周围发生）。在 2015 年，很多软件文档仍然以书籍的形式制作，以 PDF 格式交付，就好像是为了打印而设计的一样。当您获得一个新的软件应用程序或工具时，您会想：“在我开始之前，我应该打印出随附的 500 页手册吗？” 我不这么认为。
我们以四种格式向客户提供内容：作为 HTML 页面（每个部分都是一个单独的页面），作为 HTML 页面（整个书加载在一个巨大的页面中），作为 PDF 下载和作为 ePub 文件（用于电子阅读器）。查看下载数据，我们可以看到人们如何从我们的网站上消费内容（多页面 HTML 格式最受欢迎），并且从各种利益相关者和客户那里获得反馈（他们告诉我们他们不想要巨大的书籍；他们只是想要他们需要的信息，在他们需要的时候！），让我得出一个非常简单的结论：我们不应该制作设计用于打印的大型书籍。相反，我们应该创建更模块化、更易于搜索的内容，让读者可以准确地找到他们想要的东西，而不是假设他们会打开一本 500 页的书并通读目录。此外，更模块化的内容使我们能够加入其他功能，如用户评论和其他互动元素，以与客户互动、收集反馈并促进持续改进。
所以，我的团队和我决定尝试一下。对于下一个 Red Hat Enterprise Linux beta 主要版本，我们将不发布 PDF 和 ePub 格式的内容。我们还希望删除在单个 HTML 页面中查看整本书的选项（我们做出这个决定部分是出于技术原因）。相反，我们将鼓励人们通过搜索引擎找到他们需要的内容，以多页面 HTML 格式提供我们的文档，并朝着更基于模块化的内容开发方法发展。
海啸来了
Red Hat 员工在 memo-list 上的回应迅速而明确
- “这真是一种耻辱！:-/”
- “删除 html-single 是一种倒退而不是进步。”
- “[通过此更改]生活变得更加困难”
碰巧的是，当 memo-list 的回复爆发时，我正在度假，所以我无法回复。我的团队在捍卫该决定、与批评者互动并试图解释我们的战略方面做得非常出色。当我度假回来时，对话仍在进行中。我的第一反应是惊讶；我们查看了数据，使用这些格式的人的百分比非常小。为什么人们对此如此热情？
但我读的回复越多，就越意识到他们有一些非常好的观点。他们提出了我们没有考虑到的用例。而且，他们有一个非常有效的批评：我们本末倒置了。我们改变了交付书籍的方式，但我们没有充分改变内容的结构，也没有做足够的工作来改进搜索功能并使我们的策略可行。
尽早发布，经常发布
虽然有些观点似乎认为我是一个怀有恶意想法的白痴（这些观点很难读），但绝大多数人都认为相反——我的团队和我怀有良好的意图和良好的目标，而我们只是没有考虑到所有的细节。对于外部观察者来说，在 memo-list 上被“痛批”感觉很刺耳和可怕。虽然这是事实（在全公司面前受到批评从来都不是一件有趣的事），但它也是决策过程中一个很棒的部分。
我回复了该帖子，承认该决定的责任，感谢所有提供反馈的人，并解释了我们将如何整合他们的反馈并暂时逆转该更改，同时我们努力重塑我们的内容。我很惊讶——也很感激——有这么多人抽出时间回应，这次感谢我倾听他们的意见并承担该决定的责任。
这里有一个细节，可能被一些批评者忽略了：虽然看起来我们是在真空状态下做出这个决定的，但它实际上是一种受控实验。我们没有一次性地在所有产品中推出此更改；我们只在一个产品上进行了此更改，并且是在 beta 版本中。最初，我想看看人们的反应，以便我们可以继续迭代。
正如我们在开源中所说，“尽早发布，经常发布”。
因为无论您对任何决定进行多少尽职调查，总会有您没有考虑到的事情。计划时间接收反馈并迭代一个想法可能会花费更长的时间，但最终会带来对每个人都更好的结果——最重要的是，我们的客户。
这就是最终目标。
在 Twitter 上关注对话 #theopenorg
评论已关闭。