當你只想將事情搞定時，為什麼開放式工作這麼難？

GSD（get stuff done 的縮寫，即搞定）指導著我的工作方式。數年來，我將各種方法論融入我日常工作的習慣中，包括精益方法的反饋循環，和敏捷開發的迭代優化，以此來更好地 GSD（如果把 GSD 當作動詞的話）。這意味著我必須非常有效地利用我的時間：列出清晰、各自獨立的目標；標記已完成的項目；用迭代的方式地持續推進項目進度。但是當我們以開放為基礎時仍然能夠 GSD 嗎？又或者 GSD 的方法完全行不通呢？大多數人都認為這會導致糟糕的狀況，但我發現事實並不一定這樣。

在開放的環境中工作，遵循 開放式決策框架 Open Decision Framework 中的指導，會讓項目起步變慢。但是在最近的一個項目中，我們作出了一個決定，一個從開始就正確的決定：以開放的方式工作，並與我們的社群一起合作。

這是我們能做的最好的決定。

我們來看看這次經歷帶來的意想不到的結果，再看看我們如何將 GSD 思想融入開放式組織框架。

建立社區

2014 年 10 月，我接手了一個新的項目：當時紅帽的 CEO Jim Whitehurst 即將推出一本新書 《開放式組織》 The Open Organization ，我要根據書中提出的概念，建立一個社區。「太棒了，這聽起來是一個挑戰，我加入了！」我這樣想。但不久，冒牌者綜合征便出現了，我又開始想：「我們究竟要做什麼呢？怎樣才算成功呢？」

讓我劇透一下，在這本書的結尾處，Jim 鼓勵讀者訪問 Opensource.com，繼續探討 21 世紀的開放和管理。所以，在 2015 年 5 月，我們的團隊在網站上建立了一個新的板塊來討論這些想法。我們計劃講一些故事，就像我們在 Opensource.com 上常做的那樣，只不過這次圍繞著書中的觀點與概念。之後，我們每周都發布新的文章，在 Twitter 上舉辦了一個在線的讀書俱樂部，還將《開放式組織》打造成了系列書籍。

我們內部獨自完成了該系列書籍的前三期，每隔六個月發布一期。每完成一期，我們就向社區發布。然後我們繼續完成下一期的工作，如此循環下去。

這種工作方式，讓我們看到了很大的成功。近 3000 人訂閱了該系列的新書：《開放式組織領袖手冊》。我們用 6 個月的周期來完成這個項目，這樣新書的發行日正好是前書的兩周年紀念日。

在這樣的背景下，我們完成這本書的方式是簡單直接的：針對開放工作這個主題，我們收集了最好的故事，並將它們組織起來形成文章，招募作者填補一些內容上的空白，使用開源工具調整字體樣式，與設計師一起完成封面，最終發布這本書。這樣的工作方式使得我們能按照自己的時間線（GSD）全速前進。到第三本書時，我們的工作流已經基本完善了。

然而這一切在我們計劃開始《開放式組織》的最後一本書時改變了，這本書將重點放在開放式組織和 IT 文化的交融上。我提議使用開放式決策框架來完成這本書，因為我想通過這本書證明開放式的工作方法能得到更好的結果，儘管我知道這可能會完全改變我們的工作方式。時間非常緊張（只有兩個半月），但我們還是決定試一試。

用開放式決策框架來完成一本書

開放式決策框架列出了組成開放決策制定過程的 4 個階段。下面是我們在每個階段中的工作情況（以及開放是如何幫助完成工作的）。

1、 構思

我們首先寫了一份草稿，羅列了對項目設想的願景。我們需要拿出東西來和潛在的「顧客」分享（在這個例子中，「顧客」指潛在的利益相關者和作者）。然後我們約了一些領域專家面談，這些專家能夠給我們直接的誠實的意見。這些專家表現出的熱情與他們提供的指導驗證了我們的想法，同時提出了反饋意見使我們能繼續向前。如果我們沒有得到這些驗證，我們會退回到我們最初的想法，再決定從哪裡重新開始。

2、 計劃與研究

經過幾次面談，我們準備在 Opensource.com 上公布這個項目。同時，我們在 Github 上也啟動了這個項目，提供了項目描述、預計的時間線，並闡明了我們所受的約束。這次公布得到了很好的效果，我們最初計劃的目錄中欠缺了一些內容，在項目公布之後的 72 小時內就被補充完整了。另外（也是更重要的），讀者針對一些章節，提出了本不在我們計劃中的想法，但是讀者覺得這些想法能夠補充我們最初設想的版本。

回顧過去，我覺得在項目的第一和第二個階段，開放項目並不會影響我們搞定項目的能力。事實上，這樣工作有一個很大的好處：發現並填補內容的空缺。我們不只是填補了空缺，我們是迅速地填補了空缺，並且還是用我們自己從未考慮過的點子。這並不一定要求我們做更多的工作，只是改變了我們的工作方式。我們動用有限的人脈，邀請別人來寫作，再組織收到的內容，設置上下文，將人們導向正確的方向。

3、 設計，開發和測試

項目的這個階段完全圍繞項目管理，管理一些像貓一樣特立獨行的人，並處理項目的預期。我們有明確的截止時間，我們提前溝通，頻繁溝通。我們還使用了一個戰略：列出了貢獻者和利益相關者，在項目的整個過程中向他們告知項目的進度，尤其是我們在 Github 上標出的里程碑。

最後，我們的書需要一個名字。我們收集了許多反饋，指出書名應該是什麼，更重要的是反饋指出了書名不應該是什麼。我們通過 Github 上的工單收集反饋意見，並公開表示我們的團隊將作最後的決定。當我們準備宣布最後的書名時，我的同事 Bryan Behrenshausen 做了很好的工作，分享了我們作出決定的過程。人們似乎對此感到高興——即使他們不同意我們最後的書名。

書的「測試」階段需要大量的校對。社區成員真的參與到回答這個「求助」貼中來。我們在 GitHub 工單上收到了大約 80 條意見，彙報校對工作的進度（更不用說通過電子郵件和其他反饋渠道獲得的許多額外的反饋）。

關於搞定任務：在這個階段，我們親身體會了 Linus 法則：「 眾目之下， 筆誤 無所遁形。 With more eyes, all typos are shallow. 」 如果我們像前三本書一樣自己獨立完成，那麼整個校對的負擔就會落在我們的肩上（就像這些書一樣）！相反，社區成員慷慨地幫我們承擔了校對的重擔，我們的工作從自己校對（儘管我們仍然做了很多工作）轉向管理所有的 change requests。對我們團隊來說，這是一個受大家歡迎的改變；對社區來說，這是一個參與的機會。如果我們自己做的話，我們肯定能更快地完成校對，但是在開放的情況下，我們在截止日期之前發現了更多的錯誤，這一點毋庸置疑。

4、 發布

好了，我們現在推出了這本書的最終版本。（或者只是第一版？）

我們把發布分為兩個階段。首先，根據我們的公開的項目時間表，在最終日期之前的幾天，我們安靜地推出了這本書，以便讓我們的社區貢獻者幫助我們測試下載表格。第二階段也就是現在，這本書的通用版的正式公布。當然，我們在發布後的仍然接受反饋，開源方式也正是如此。

成就解鎖

遵循開放式決策框架是 《IT 文化變革指南》 Guide to IT Culture Change 成功的關鍵。通過與客戶和利益相關者的合作，分享我們的制約因素，工作透明化，我們甚至超出了自己對圖書項目的期望。

我對整個項目中的合作，反饋和活動感到非常滿意。雖然有一段時間內沒有像我想要的那樣快速完成任務，這讓我有一種焦慮感，但我很快就意識到，開放這個過程實際上讓我們能完成更多的事情。基於上面我的概述這一點顯而易見。

所以也許我應該重新考慮我的 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 譯者：explosic4 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive