三个字母指导我的工作方式：GSD——把事情做完 (Get Stuff Done)。 多年来，我设法将反馈循环（来自精益方法）和迭代改进（来自敏捷）等概念融入到我的日常工作习惯中，以便更好地 GSD（如果我可以将其用作动词）。这意味着我必须非常高效地利用我的时间：勾勒出清晰、离散的目标；从主列表中勾选已完成的项目；并以迭代的方式不断推进项目。但是，在默认情况下保持开放的情况下，人们仍然可以 GSD 吗？或者，这是否意味着把事情做完会陷入停滞？ 大多数人会认为情况最糟，但我发现情况并非一定如此。
开放式工作并使用 开放决策框架 的指导可以使项目的启动速度变慢。但是在最近的一个项目中，我们一开始就决定公开工作并与我们的社区合作。
这是我们能做出的最好的决定。
让我们看一下这次经历中一些意想不到的后果，看看如何将 GSD 思维融入到开放决策框架中。
建设社区
2014 年 11 月，我开始了一个新项目：围绕红帽 CEO 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 条评论