当你只想将事情搞定时，为什么开放式工作这么难？
开放式组织

> 
> 学习使用开放式决策框架来写一本书
> 
> 
> 


![Why working openly is hard when you just want to get stuff done](/data/attachment/album/201710/13/064330gp5x5mjzml29klpp.png "Why working openly is hard when you just want to get stuff done")


GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数年来，我将各种方法论融入我日常工作的习惯中，包括精益方法的反馈循环，和敏捷开发的迭代优化，以此来更好地 GSD（如果把 GSD 当作动词的话）。这意味着我必须非常有效地利用我的时间：列出清晰、各自独立的目标；标记已完成的项目；用迭代的方式地持续推进项目进度。但是当我们以开放为基础时仍然能够 GSD 吗？又或者 GSD 的方法完全行不通呢？大多数人都认为这会导致糟糕的状况，但我发现事实并不一定这样。


在开放的环境中工作，遵循<ruby> <a href="https://opensource.com/open-organization/resources/open-decision-framework">  开放式决策框架 </a> <rt>  Open Decision Framework </rt></ruby>中的指导，会让项目起步变慢。但是在最近的一个项目中，我们作出了一个决定，一个从开始就正确的决定：以开放的方式工作，并与我们的社群一起合作。


这是我们能做的最好的决定。


我们来看看这次经历带来的意想不到的结果，再看看我们如何将 GSD 思想融入开放式组织框架。


### 建立社区


2014 年 10 月，我接手了一个新的项目：当时红帽的 CEO Jim Whitehurst 即将推出一本新书<ruby> 《开放式组织》 <rt>  The Open Organization </rt></ruby>，我要根据书中提出的概念，建立一个社区。“太棒了，这听起来是一个挑战，我加入了！”我这样想。但不久，[冒牌者综合征](https://opensource.com/open-organization/17/5/team-impostor-syndrome)便出现了，我又开始想：“我们究竟要做什么呢？怎样才算成功呢？”


让我剧透一下，在这本书的结尾处，Jim 鼓励读者访问 Opensource.com，继续探讨 21 世纪的开放和管理。所以，在 2015 年 5 月，我们的团队在网站上建立了一个新的板块来讨论这些想法。我们计划讲一些故事，就像我们在 Opensource.com 上常做的那样，只不过这次围绕着书中的观点与概念。之后，我们每周都发布新的文章，在 Twitter 上举办了一个在线的读书俱乐部，还将《开放式组织》打造成了系列书籍。


我们内部独自完成了该系列书籍的前三期，每隔六个月发布一期。每完成一期，我们就向社区发布。然后我们继续完成下一期的工作，如此循环下去。


这种工作方式，让我们看到了很大的成功。近 3000 人订阅了[该系列的新书](https://opensource.com/open-organization/resources/leaders-manual)：《开放式组织领袖手册》。我们用 6 个月的周期来完成这个项目，这样新书的发行日正好是前书的两周年纪念日。


在这样的背景下，我们完成这本书的方式是简单直接的：针对开放工作这个主题，我们收集了最好的故事，并将它们组织起来形成文章，招募作者填补一些内容上的空白，使用开源工具调整字体样式，与设计师一起完成封面，最终发布这本书。这样的工作方式使得我们能按照自己的时间线（GSD）全速前进。到[第三本书](https://opensource.com/open-organization/resources/leaders-manual)时，我们的工作流已经基本完善了。


然而这一切在我们计划开始《开放式组织》的最后一本书时改变了，这本书将重点放在开放式组织和 IT 文化的交融上。我提议使用开放式决策框架来完成这本书，因为我想通过这本书证明开放式的工作方法能得到更好的结果，尽管我知道这可能会完全改变我们的工作方式。时间非常紧张（只有两个半月），但我们还是决定试一试。


### 用开放式决策框架来完成一本书


开放式决策框架列出了组成开放决策制定过程的 4 个阶段。下面是我们在每个阶段中的工作情况（以及开放是如何帮助完成工作的）。


#### 1、 构思


我们首先写了一份草稿，罗列了对项目设想的愿景。我们需要拿出东西来和潜在的“顾客”分享（在这个例子中，“顾客”指潜在的利益相关者和作者）。然后我们约了一些领域专家面谈，这些专家能够给我们直接的诚实的意见。这些专家表现出的热情与他们提供的指导验证了我们的想法，同时提出了反馈意见使我们能继续向前。如果我们没有得到这些验证，我们会退回到我们最初的想法，再决定从哪里重新开始。


#### 2、 计划与研究


经过几次面谈，我们准备在 [Opensource.com 上公布这个项目](https://opensource.com/open-organization/17/3/announcing-it-culture-book)。同时，我们在 [Github 上也启动了这个项目](https://github.com/open-organization-ambassadors/open-org-it-culture)，提供了项目描述、预计的时间线，并阐明了我们所受的约束。这次公布得到了很好的效果，我们最初计划的目录中欠缺了一些内容，在项目公布之后的 72 小时内就被补充完整了。另外（也是更重要的），读者针对一些章节，提出了本不在我们计划中的想法，但是读者觉得这些想法能够补充我们最初设想的版本。


回顾过去，我觉得在项目的第一和第二个阶段，开放项目并不会影响我们搞定项目的能力。事实上，这样工作有一个很大的好处：发现并填补内容的空缺。我们不只是填补了空缺，我们是迅速地填补了空缺，并且还是用我们自己从未考虑过的点子。这并不一定要求我们做更多的工作，只是改变了我们的工作方式。我们动用有限的人脉，邀请别人来写作，再组织收到的内容，设置上下文，将人们导向正确的方向。


#### 3、 设计，开发和测试


项目的这个阶段完全围绕项目管理，管理一些像猫一样特立独行的人，并处理项目的预期。我们有明确的截止时间，我们提前沟通，频繁沟通。我们还使用了一个战略：列出了贡献者和利益相关者，在项目的整个过程中向他们告知项目的进度，尤其是我们在 Github 上标出的里程碑。


最后，我们的书需要一个名字。我们收集了许多反馈，指出书名应该是什么，更重要的是反馈指出了书名不应该是什么。我们通过 [Github 上的工单](https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20)收集反馈意见，并公开表示我们的团队将作最后的决定。当我们准备宣布最后的书名时，我的同事 Bryan Behrenshausen 做了很好的工作，[分享了我们作出决定的过程](https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20#issuecomment-297970303)。人们似乎对此感到高兴——即使他们不同意我们最后的书名。


书的“测试”阶段需要大量的[校对](https://github.com/open-organization-ambassadors/open-org-it-culture/issues/29)。社区成员真的参与到回答这个“求助”贴中来。我们在 GitHub 工单上收到了大约 80 条意见，汇报校对工作的进度（更不用说通过电子邮件和其他反馈渠道获得的许多额外的反馈）。


关于搞定任务：在这个阶段，我们亲身体会了 [Linus 法则](https://en.wikipedia.org/wiki/Linus%27s_Law)：“<ruby> 众目之下， <strong>  笔误 </strong> 无所遁形。 <rt>  With more eyes, all  <strong>   typos  </strong>  are shallow. </rt></ruby>” 如果我们像前三本书一样自己独立完成，那么整个校对的负担就会落在我们的肩上（就像这些书一样）！相反，社区成员慷慨地帮我们承担了校对的重担，我们的工作从自己校对（尽管我们仍然做了很多工作）转向管理所有的 change requests。对我们团队来说，这是一个受大家欢迎的改变；对社区来说，这是一个参与的机会。如果我们自己做的话，我们肯定能更快地完成校对，但是在开放的情况下，我们在截止日期之前发现了更多的错误，这一点毋庸置疑。


#### 4、 发布


好了，我们现在推出了这本书的最终版本。（或者只是第一版？）


我们把发布分为两个阶段。首先，根据我们的公开的项目时间表，在最终日期之前的几天，我们安静地推出了这本书，以便让我们的社区贡献者帮助我们测试[下载表格](https://opensource.com/open-organization/resources/culture-change)。第二阶段也就是现在，这本书的[通用版](https://opensource.com/open-organization/resources/culture-change)的正式公布。当然，我们在发布后的仍然接受反馈，开源方式也正是如此。


### 成就解锁


遵循开放式决策框架是<ruby> 《IT 文化变革指南》 <rt>  Guide to IT Culture Change </rt></ruby>成功的关键。通过与客户和利益相关者的合作，分享我们的制约因素，工作透明化，我们甚至超出了自己对图书项目的期望。


我对整个项目中的合作，反馈和活动感到非常满意。虽然有一段时间内没有像我想要的那样快速完成任务，这让我有一种焦虑感，但我很快就意识到，开放这个过程实际上让我们能完成更多的事情。基于上面我的概述这一点显而易见。


所以也许我应该重新考虑我的 GSD 心态，并将其扩展到 GMD：Get **More** Done，搞定**更多**工作，并且就这个例子说，取得更好的结果。


（题图：opensource.com）




---


作者简介：


Jason Hibbets - Jason Hibbets 是 Red Hat 企业营销中的高级社区传播者，也是 Opensource.com 的社区经理。 他自2003 年以来一直在 Red Hat，并且是开源城市基金会的创立者。之前的职位包括高级营销专员、项目经理、Red Hat 知识库维护人员和支持工程师。




---


via: <https://opensource.com/open-organization/17/6/working-open-and-gsd>


作者：[Jason Hibbets](https://opensource.com/users/jhibbets) 译者：[explosic4](https://github.com/explosic4) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Three letters guide the way I work: GSD—get stuff done. Over the years, I've managed to blend concepts like feedback loops (from lean methodologies) and iterative improvement (from Agile) into my everyday work habits so I can better GSD (if I can use that as a verb). This means being extremely efficient with my time: outlining clear, discrete goals; checking completed items off a master list; and advancing projects forward iteratively and constantly. But can someone still GSD while defaulting to open? Or is this when getting stuff done comes to a grinding halt? Most would assume the worst, but I found that's not necessarily the case.

Working in the open and using guidance from the [Open Decision Framework](https://opensource.com/open-organization/resources/open-decision-framework) can get projects off to a slower start. But during a recent project, we made the decision—right at the beginning—to work openly and collaborate with our community.


It was the best decision we could have made.

Let's take a look at a few unexpected consequences from this experience and see how we can incorporate a GSD mentality into the Open Decision Framework.

## Building community

In November 2014, I undertook a new project: build a community around the concepts in *The Open Organization*, a forthcoming (at the time) book by Red Hat CEO Jim Whitehurst. I thought, "Cool, that sounds like a challenge—I'm in!" Then [impostor syndrome](https://opensource.com/open-organization/17/5/team-impostor-syndrome) set in. I started thinking: "What in the world are we going to do, and what would success look like?"


*Spoiler alert*. At the end of the book, Jim recommends that readers visit Opensource.com to continue the conversation about openness and management in the 21st century. So, in May 2015, my team launched a new section of the site dedicated to those ideas. We planned to engage in some storytelling, just like we always do at Opensource.com—this time around the ideas and concepts in the book. Since then, we've published new articles every week, hosted an online book club complete with Twitter chats, and turned *The Open Organization* into [a book series](https://opensource.com/open-organization/resources).

We produced the first three installments of our book series in-house, releasing one every six months. When we finished one, we'd announce it to the community. Then we'd get to work on the next one, and the cycle would continue.

Working this way, we saw great success. Nearly 3,000 people have registered to receive the [latest book in the series](https://opensource.com/open-organization/resources/leaders-manual), *The Open Organization Leaders Manual*. And we've maintained our six-month cadence, which means the next book would coincide with the second anniversary of the book.

Behind the scenes, our process for creating the books is fairly straightforward: We collect our best-of-best stories about particular aspects of working openly, organize them into a compelling narrative, recruit writers to fill some gaps, typeset everything with open tools, collaborate with designers on a cover, and release. Working like this allows us to stay on our own timeline—GSD, full steam ahead. By the [third book](https://opensource.com/open-organization/resources/leaders-manual), we seemed to have perfected the process.

That all changed when we began planning the latest volume in *Open Organization* series, one focused on the intersection of open organizations and IT culture. I proposed using the Open Decision Framework because I wanted this book to be proof that working openly produced better results, even though I knew it would completely change our approach to the work. In spite of a fairly aggressive timeline (about two-and-a-half months), we decided to try it.

## Creating a book with the Open Decision Framework

The Open Decision Framework lists four phases that constitute the open decision-making process. Here's what we did during each (and how it worked out).

### 1. Ideation

First, we drafted a document outlining a tentative vision for the project. We needed something we could begin sharing with potential "customers" (in our case, potential stakeholders and authors). Then we scheduled interviews with source matter experts we thought would be interested in the project—people who would give us raw, honest feedback about it. Enthusiasm and guidance from those experts validated our idea and gave us the feedback we needed to move forward. If we hadn't gotten that validation, we'd have gone back to our proposal and made a decision on where to pivot and start over.

### 2. Planning and research

With validation after several interviews, we prepared to [announce the project publically on Opensource.com](https://opensource.com/open-organization/17/3/announcing-it-culture-book). At the same time, we [launched the project on GitHub](https://github.com/open-organization-ambassadors/open-org-it-culture), offering a description, prospective timeline, and set of constraints. The project announcement was so well-received that all remaining holes in our proposed table of contents were filled within 72 hours. In addition (and more importantly), readers proposed ideas for chapters that *weren't *already in the table of contents—things they thought might enhance the vision we'd initially sketched.

Looking back, I get the sense that working openly on Phases 1 and 2 really didn't negatively impacted our ability to GSD. In fact, working this way had a huge upside: identifying and filling content gaps. We didn't just fill them; we filled them *rapidly* and with chapter ideas, we never would have considered on our own. This didn't necessarily involve more work—just work of a different type. We found ourselves asking people in our limited network to write chapters, then managing incoming requests, setting context, and pointing people in the right direction.

### 3. Design, development, and testing

This point in the project was all about project management, cat herding, and maintaining expectations. We were on a deadline, and we communicated that early and often. We also used a tactic of creating a list of contributors and stakeholders and keeping them updated and informed along the entire journey, particularly at milestones we'd identified on GitHub.

Eventually, our book needed a title. We gathered lots of feedback on what the title should be, and more importantly what it *shouldn't* be. We [opened an issue](https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20) as one way of gathering feedback, then openly shared that my team would be making the final decision. When we were ready to announce the final title, my colleague Bryan Behrenshausen did a great job [sharing the context for the decision](https://github.com/open-organization-ambassadors/open-org-it-culture/issues/20#issuecomment-297970303). People seemed to be happy with it—even if they didn't agree with where we landed with the final title.

Book "testing" involved extensive [proofreading](https://github.com/open-organization-ambassadors/open-org-it-culture/issues/29). The community really stepped up to answer this "help wanted" request. We received approximately 80 comments on the GitHub issue outlining the proofing process (not to mention numerous additional interactions from others via email and other feedback channels).

With respect to getting things done: In this phase, we experienced [Linus' Law](https://en.wikipedia.org/wiki/Linus%27s_Law) firsthand: "With more eyes, all *typos* are shallow." Had we used the internalized method we'd used for our three previous book projects, the entire burden of proofing would have fallen on our shoulders (as it did for those books!). Instead, community members graciously helped us carry the burden of proofing, and our work shifted from proofing itself (though we still did plenty of that) to managing all the change requests coming in. This was a much-welcomed change for our team and a chance for the community to participate. We certainly would have finished the proofing faster if we'd done it ourselves, but working on this in the open undeniably allowed us to catch a greater number of errors in advance of our deadline.

### 4. Launch

And here we are, on the cusp of launching the final (or is it just the first?) version of the book.

Our approach to launch consists of two phases. First, in keeping with our public project timeline, we quietly soft-launched the book days ago so our community of contributors could help us test the [download form](https://opensource.com/open-organization/resources/culture-change). The second phase begins right now, with the final, formal announcement of the book's [general availability](https://opensource.com/open-organization/resources/culture-change). Of course, we'll continue accepting additional feedback post-launch, as is the open source way.

## Achievement unlocked

Following the Open Decision Framework was key to the success of the *Guide to IT Culture Change*. By working with our customers and stakeholders, sharing our constraints, and being transparent with the work, we exceeded even our own expectations for the book project.

I was definitely pleased with the collaboration, feedback, and activity we experienced throughout the entire project. And although the feeling of anxiety about not getting stuff done as quickly as I'd liked loomed over me for a time, I soon realized that opening up the process actually allowed us to get *more* done than we would have otherwise. That should be evident based on some of the outcomes I outlined above.

So perhaps I should reconsider my GSD mentality and expand it to GMD: Get **more** done—and, in this case, with better results.

## 4 Comments