三个字母指导我的工作方式：GSD—完成工作。多年来，我设法将反馈循环（来自精益方法）和迭代改进（来自敏捷）等概念融入到我的日常工作习惯中，以便我更好地 GSD（如果我可以使用它作为动词）。这意味着极大地提高我的时间效率：概述清晰、离散的目标；从主列表中勾选已完成的项目；并迭代且不断地推进项目。但是，当默认开放时，有人仍然可以 GSD 吗？或者这是完成工作陷入停滞的时候吗？大多数人会认为情况会很糟糕，但我发现情况并非一定如此。
在开放环境中工作并使用开放决策框架的指导可能会使项目启动速度较慢。但在最近的一个项目中，我们在一开始就决定公开工作并与我们的社区合作。
这是我们能做出的最好的决定。
让我们看一下这次经历中一些意想不到的后果，看看我们如何将 GSD 心态融入到开放决策框架中。
构建社区
2014 年 11 月，我承担了一个新项目：围绕 Red Hat 首席执行官 Jim Whitehurst 即将出版（当时）的书籍《开放组织》中的概念构建一个社区。我想，“酷，这听起来像是一个挑战——我参与！”然后冒名顶替综合症发作了。我开始思考：“我们到底要做什么，成功的样子是什么？”
剧透警告。在本书的结尾，Jim 建议读者访问 Opensource.com，继续讨论关于 21 世纪的开放性和管理。因此，在 2015 年 5 月，我的团队启动了网站的一个新版块，专门讨论这些想法。我们计划像在 Opensource.com 上一直做的那样进行一些故事讲述——这次围绕书中的想法和概念。从那时起，我们每周都会发表新文章，举办包含 Twitter 聊天的在线读书俱乐部，并将《开放组织》变成书系。
我们内部制作了书系的前三部，每六个月发布一部。当我们完成一部时，我们会向社区宣布。然后我们会开始制作下一部，循环往复。
以这种方式工作，我们看到了巨大的成功。近 3,000 人已注册接收书系中的最新书籍，《开放组织领导者手册》。我们保持了六个月的节奏，这意味着下一本书将与本书的第二个周年纪念日同时发布。
在幕后，我们创建书籍的过程非常简单：我们收集关于开放工作的特定方面的最佳故事，将它们组织成引人入胜的叙述，招募作者来填补一些空白，使用开放工具排版所有内容，与设计师合作设计封面，然后发布。像这样工作使我们能够按照我们自己的时间表进行——GSD，全力以赴。到第三本书时，我们似乎已经完善了这个过程。
当我们开始计划《开放组织》系列的最新卷时，一切都发生了变化，该卷的重点是开放组织和 IT 文化的交叉点。我建议使用开放决策框架，因为我希望这本书能够证明开放工作会产生更好的结果，即使我知道这会完全改变我们的工作方式。尽管时间表相当紧张（大约两个半月），但我们还是决定尝试一下。
使用开放决策框架创建书籍
开放决策框架列出了构成开放决策过程的四个阶段。以下是我们每个阶段所做的工作（以及它的效果）。
1. 构思
首先，我们起草了一份文件，概述了项目的初步愿景。我们需要一些可以开始与潜在“客户”（在我们的案例中是潜在的利益相关者和作者）分享的东西。然后，我们安排了与我们认为会对该项目感兴趣的源材料专家进行访谈——这些人会给我们关于该项目的原始、诚实的反馈。这些专家的热情和指导验证了我们的想法，并为我们提供了前进所需的反馈。如果我们没有获得这种验证，我们就会回到我们的提案，并决定在哪里转向并重新开始。
2. 计划和研究
在几次访谈后获得验证后，我们准备在 Opensource.com 上公开宣布该项目。与此同时，我们在 GitHub 上启动了该项目，提供了描述、预计时间表和一系列约束。项目公告非常受欢迎，以至于我们提出的目录中所有剩余的漏洞都在 72 小时内被填补。此外（更重要的是），读者提出了目录中没有的章节的想法——他们认为这些想法可能会增强我们最初勾勒出的愿景。
回顾过去，我感觉在阶段 1 和 2 中公开工作真的没有对我们 GSD 的能力产生负面影响。事实上，以这种方式工作有一个巨大的好处：识别和填补内容空白。我们不仅仅是填补它们；我们迅速地填补了它们，并且提出了我们自己永远不会考虑的章节想法。这不一定涉及更多的工作——只是不同类型的工作。我们发现自己要求我们有限网络中的人员撰写章节，然后管理收到的请求，设置上下文，并为人们指明正确的方向。
3. 设计、开发和测试
项目中的这一点完全是关于项目管理、牧猫和维护期望。我们有一个截止日期，我们尽早且经常地沟通这一点。我们还使用了一种策略，即创建贡献者和利益相关者的列表，并在整个过程中，特别是在我们在 GitHub 上确定的里程碑处，让他们保持更新和知情。
最终，我们的书需要一个标题。我们收集了关于标题应该是什么的大量反馈，更重要的是，标题不应该是什么。我们打开了一个问题，作为收集反馈的一种方式，然后公开表示我的团队将做出最终决定。当我们准备宣布最终标题时，我的同事 Bryan Behrenshausen 在分享决策的背景方面做得非常出色。人们似乎对它感到满意——即使他们不同意我们最终确定的标题。
书籍“测试”涉及广泛的校对。社区真的站出来响应了这一“帮助请求”。我们在 GitHub 问题上收到了大约 80 条评论，概述了校对过程（更不用说来自其他人的通过电子邮件和其他反馈渠道的众多额外互动）。
关于完成工作：在这个阶段，我们亲身经历了Linus 定律：“眼睛越多，所有的拼写错误都越肤浅。”如果我们使用我们之前为三本书项目使用的内部方法，那么所有的校对负担都将落在我们的肩上（就像那些书一样！）。相反，社区成员慷慨地帮助我们承担了校对的负担，我们的工作从校对本身（尽管我们仍然做了很多校对）转变为管理所有涌入的更改请求。这对我们的团队来说是一个非常受欢迎的变化，也是社区参与的机会。如果我们自己完成校对，我们肯定会更快地完成校对，但公开进行这项工作无疑使我们能够在截止日期之前提前发现更多错误。
4. 发布
现在我们就在这里，即将发布本书的最终版本（或者只是第一个版本？）。
我们的发布方法包括两个阶段。首先，为了与我们的公共项目时间表保持一致，我们在几天前悄悄地软发布了这本书，以便我们的贡献者社区可以帮助我们测试下载表格。第二阶段现在开始，正式发布本书的全面上市。当然，我们将继续接受发布后的额外反馈，就像开源方式一样。
成就解锁
遵循开放决策框架是《IT 文化变革指南》成功的关键。通过与我们的客户和利益相关者合作，分享我们的约束条件，并公开工作，我们甚至超出了我们自己对本书项目的期望。
我对我们在整个项目中体验到的协作、反馈和活动感到非常满意。尽管对没有像我希望的那样快速完成工作的焦虑感笼罩了我一段时间，但我很快意识到，开放流程实际上使我们完成了比我们原本可能完成的更多工作。这应该从我上面概述的一些结果中显而易见。
所以也许我应该重新考虑我的 GSD 心态，并将其扩展到 GMD：完成更多工作——在这种情况下，结果更好。
4 条评论