测试计划剔除 log剔除

“这甚至是一个讨论点，这一事实令人难以置信。”

那是发给整个公司的电子邮件中的结束语，一个人反对我在Red Hat担任现职两个月后做出的决定。 度假回来后的第二天，读到这封电子邮件以及大量主题相似（且颜色更丰富）的电子邮件，令人耳目一新。 我读得越多，就越意识到（除了对我所做的决定和团队的执行方式持高度批判性），这些电子邮件的作者还有其他共同点：他们是对的。

问题：不断变化的文档格局

当我在Red Hat担任现职时，领导着负责生产我们所有产品文档和其他面向客户的内容的全球团队的工作，我为我们有机会在软件世界的一部分中进行更改和尝试新事物而感到兴奋的发展速度非常缓慢（尽管围绕它进行的创新力度很大）。 在2015年，仍然有大量的软件文档以书籍的形式产生，以PDF格式提供，就好像是要印刷的一样。 当您获得新的软件应用程序或工具时，您是否认为：“在开始之前，我应该打印出随附的500页手册吗？” 我不这么认为。

我们以四种格式向客户提供内容：HTML页（其中每个部分是一个单独的页面），HTML页（其中整本书载入一个大页面），PDF下载以及ePub文件（与e-读者）。 查看下载的数据，我们可以看到人们如何使用我们网站上的内容（多页HTML格式最为流行），并获得了众多利益相关者和客户的反馈（他们告诉我们他们不想要巨型图书；他们只需要他们需要的信息，当他们需要它时！），这使我得出一个非常直接的结论：我们不应该生产旨在印刷的大型书籍。 相反，我们应该创建更具模块化，更易于搜索的内容，使读者可以准确地将所需内容完全归零，而不是假设他们打算打开一本500页的书并通读目录。 此外，更多的模块化内容使我们能够合并其他功能，例如用户评论和其他互动元素，以与客户互动，收集反馈并促进持续改进。

因此，我和我的团队决定尝试一下。 对于Red Hat Enterprise Linux beta的下一个主要版本，我们将不提供内容的PDF和ePub格式。 我们还希望删除在单个HTML页面中查看整本书的选项（我们之所以做出此决定，部分原因是出于技术原因）。 相反，我们鼓励人们通过搜索引擎找到他们需要的东西，以多页HTML格式提供我们的文档，并在我们的内容开发中朝着基于模块化的方法发展。

雪崩来了

备忘单上的红色帽匠的ReactSwift而明确：

• “真是可惜！！
• “删除html只是一个回归，而不是改进。”
• “随着这种变化，生活变得更加艰难”

碰巧的是，备忘录列表中的响应出现时我正在休假，所以我无法响应。 我的团队在捍卫这一决定，与批评者接触并试图解释我们的战略方面做得很勇敢。 当我从假期回来时，对话仍在继续。 我的第一React是惊讶。 我们查看了数据，使用这些格式的用户比例很小。 人们为什么对此如此热情？

但是，我阅读的答复越多，我就越意识到他们的观点确实很不错。 他们介绍了我们没有考虑过的用例。 而且，他们有一个非常有效的批评：我们把车推到了马的前面。 我们改变了交付书的方式，但是我们没有足够地改变内容的结构，也没有做足够的事情来改善搜索功能并使我们的策略可行。

提前发布，经常发布

尽管有些情绪似乎认为我是一个有不良意图的白痴（很难理解），但绝大多数人却相反：我和我的团队都有良好的意图和良好的目标，而我们只是没有没有考虑所有细节。 对于外部观察者来说，在备忘录列表上被“剔除”会感到刺耳和恐惧。 尽管这是真的（在整个公司面前受到批评从来都不是一件有趣的事），但这也是决策过程的重要组成部分。

我回复了该线程，对决策负责，对提供反馈的每个人表示感谢，并解释了在我们重新设计内容的过程中，我们将如何吸收他们的反馈并暂时撤消更改。 令我感到惊讶且感激的是，有这么多人花时间做出回应，这次感谢我倾听他们的意见并掌握了决定。

这是一些批评家可能遗忘的一个细节：虽然看起来我们是在真空中做出这个决定，但实际上这是一种受控实验。 我们并没有立即在所有产品上推出更改。 我们只在一种产品上进行过测试，并在此期间进行了Beta版发布。 最初，我想了解人们的React，以便我们可以继续进行迭代。

正如我们在开放源代码中所说，“提早发布，经常发布”。

因为无论您做出了多少尽职调查，您总会有一些您不予考虑的事情。 计划时间来接收反馈并反复考虑一个想法可能会花费一些时间，但是最终它会导致对每个人（最重要的是我们的客户）更好的结果。

这是最终目标。

在Twitter上关注对话#theopenorg

翻译自: https://opensource.com/open-organization/15/6/eviscerated-front-entire-company

测试计划剔除 log剔除