開放式職場研究

在開放的環境中工作，遵循開放式決策架構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 個階段。以下是我們在每個階段中的工作情況（以及開放是如何幫助完成工作的）。

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

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

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

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

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

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

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

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

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

成就解鎖
遵循開放式決策架構是《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 知識庫維護人員和支援工程師。

以上是開放式職場研究的詳細內容。更多資訊請關注PHP中文網其他相關文章！