這是#非項目系列文件中的最后一篇；研究了組織如何以非項目的組織形式來進行持續交付。如果你還沒有準備好，請先閱讀一下該系列的前兩篇文件：第一篇和第二篇。這一篇文章依賴于之前討論的概念和基于工作量和價值來可視化和管理不斷改變的流程的方法。
我們本文將改變一下語境——產出物。詳細討論如何定義產出物、它們相互作用的管理和成功標準的度量是務實的做法。我們將以一個警告作為本篇文章的結尾：浮現出隱性項目的風險。也就是說，模仿項目組織方式的工作模式，只是名稱上不同罷了。

什么是產出物？

從根本上說，所有項目的目標都是創建新的組織能力，無外乎技術性或功能性這兩種。那么問題來了，組織可以不以項目驅動的方式來引入新的能力嗎？
簡而言之，可以。關鍵是把能力作為具有價值的東西和產出物來思考。
無論從團隊、部門或組織哪個層面來看，活動的連續流轉都是更加關注產出物（outcomes）而非輸出（outputs）。產出物是通過它為組織帶來的價值來度量的，無論這個價值是直接且有形的，還是間接且無形的。產出物是有計劃的、慢慢變化的，為組織定義了共同的方向。

然而，產出物可能會更為復雜，互相間會有依賴，偶爾還會有沖突。為了有效地管理以上種種，我們需要先來理解四件事：

1. 產出物的概要，
2. 工作原則，
3. 產出物之間的關系，
4. 以及非預期的結果

產出物的概要

產出物的概要為團隊、部門或組織定義了環境、目的和預期。雖然組織間的概要會有所不同，但最起碼都會包含以下內容：

1. 總結——產出物的簡短描述。
2. 度量基準——如果產出物是可量化的，那么它目前是什么狀態呢？
3. 擁有者——誰（個人或團隊）對該產出物負責？
4. 依賴性和順序（排列）——與其他產出物有關的產出物在什么位置？
5. 投入——完成該產出物的最大投入產出比是什么？
6. 當前目標——你試圖要完成什么？盡量避免用百分比（它們很容易被運作），并記住這是當前的目標。它會隨著時間的推移而產生變化。依賴于該產出物所在的環境，當前目標可能還會有一個時間期限或者到期日期。
7. 產出物測試計劃——當針對該產出物目標采取行動時，你將如何來度量這些活動的有效性？

計劃是不包含在概要里的。團隊可以期望通過調查不斷的變化而去動態反應以抓住市場或組織內的機遇。

產出物概要示例

工作原則

為了長遠的有效性，產出物需要受到約束。我們不能讓部門和團隊做任何他們不想檢查的事，與此同時也不能束縛他們的交付能力。為此我們創建了一套分級的原則，這些規則與產出物無關，可適用于所有的活動。我們很期望每個團隊能根據自己的重要性創建自己的原則。原則可以在質量、溝通、職工管理、安全性、品牌化等領域或其他任何共公領域來約束團隊。

相關廠商內容

Facebook的項目開發流程和工程師績效管理機制

今日頭條服務化探索及實踐歷程

云端基于Docker微服務應用的架構實踐

Intel如何優化Spark應用的性能

云上應用Docker技術持續交付實踐

相關贊助商

QCon北京2016大會，4月21-23日，北京·國際會議中心，精彩內容邀您參與！

要意識到，每個原則會增加每項活動的成本和工作量。出于這個原因，原則應予以分級。你可以使用任何劃分優先級模型，但我一般會推薦MoSCoW。

• M - 必須有：沒有商量余地的原則，要想完成就必須要遵守它，無一例外。例如：所有活動必須在編碼之前就已經寫完相關的自動化單元測試（TDD）。
• S - 應該有：團隊需要遵守這些原則或證明它們是不適用的。例如：所有認證應該直接連接到公司的活動目錄系統。
• C - 可以有：可選的原則，可作為一個指導原則，由團隊自己來決定。例如：可以針對每個活動來寫OWASP安全性測試并作為回歸測試套件的一部分來執行。
• W - 不要有：團隊應該避免的反原則。

產出物之間的關系

各級組織的產出物有著天生的粒度。組織級產出物通常粒度較粗，關注的是收入、職工和產品。
部門級產出物通常會分解單獨的組織級產出物。分解的目的是在組織內專注于該產出物，并明確其所有權。高管將對此負責，比如CIO。

在團隊級，產出物會非常具體，并和部門級產出物相關。然而，如果組織級結構本身就很復雜，那么團隊級產出物可能還需要第二個父級產出物。不管它們之間有怎樣的關系，必須有一個單獨的團隊或部門經理來負責。
例如（創業公司的產出物）：
組織級產出物：以每股的價格出售公司，同時保證部門級產出物：每季度來自于訂閱的收入增加到X。
團隊產出物：免費到交付的轉化率增加到2%

意外結果

這個工作模型的最大風險是由于產出物的沖突導致的意外結果。當部門或團隊間缺乏交流溝通時，沒講清楚要描述的產出物時，不同產出物之間有優先級的沖突時或發展/變化和穩定/現狀之間天生的對立關系時，都會造成產出物的沖突。

對于技術性團隊而言（這是這一系列文件的背景），可以用4種方式來緩和這些意外結果。

1. 公開可用的活動畫布（Activity Canvas）：整個組織都可以看到每個團隊的活動畫布時，團隊就可以確認其他活動是否對它們有消極的影響了。這需要團隊積極地檢查與團隊密切相關的活動畫布。不過，一定要謹記一點，使可能會導致消極影響的任何變化都更加清晰、透明。
2. 定期重組團隊：讓價值交付團隊中的人定期流動一下，而不是僅僅分享一下技能和經驗，使大家不再因為“我們”還是“他們”的角色定位而產生不同的行為舉止。反過來說，這有助于促進協作的文化，在沖突發生之前就發現潛在的苗頭。
3. 自動化的測試、回歸測試和回滾：如果變更直接關系到技術環境，任何新做的和修改的功能都應該經過這三個系統的檢查。
   1. 自動化的測試系統 - 檢查它是否在按預期運行
   2. 自動化的回歸測試系統 - 驗證它沒有破壞其他的功能，以及
   3. 自動化的回滾系統 - 如果變更的地方有之前兩步未發現的問題，則撤消。
4. 工作原則：最后，每個活動的識別和提出都需要遵守既定的工作原則。這會保證從長遠來看那些會帶來短期收益的變更不會帶來大的問題。

把它們組合到一起

不把團隊與特定的輸出綁定，對產出物的增長有深刻理解（并為此做計劃）的組織能從根本上使自己適應市場的變化。管理控制以公共的工作原則和清晰定義的、無沖突的產出物來發揮作用。高級管理者可以委派價值交付團隊去決定“如何做（how）”，同時保留“做什么（what）”和“為什么做（why）”的決定權。

團隊組織

簡單說一下團隊組織。在前面文章中討論過，價值交付團隊不是圍繞職能筒倉（可能組織的剩余部分仍存在這種情況）建立的，而應該為滿足產出物的要求由適當的技能和角色混合而成的。不要把它錯誤地理解為矩陣組織中的項目團隊。理想情況下，這是一個向負責該產出物的一線經理匯報的執行團隊（或部分）。

noprojects的所有要點是，價值交付團隊將為努力完成目標產出物而做出改變。

產出物的度量

因為每個活動都很小，所以對產出物的影響可能也很小甚至可以忽略不計。我們感興趣的是所有活動對產出物的累積影響。如果產出物是團隊可量化的，那么就每隔一段時間針對基準來度量它們的進展。度量的形式取決于產出物以及它的量化方式。團隊也可以根據結果在收益概要內設定新的目標，或者徹底變更產出物。組織可以使用這些度量值做出明智的決定，以指導下一步的投資和戰略方向。

特殊情況——A/B測試和持續度量

在很多情況下產出物都很普通，可以直接通過度量來預測（比如維持運行的穩定性和安全性）。如果一些活動對產出物有不清晰/不確定的影響，那么我們建議使用A/B測試，并在可能的時候予以度量。

“顧名思義，A和B是兩個可對比的版本，它們除了一處會影響用戶行為的地方不同之外，其他地方完全相同。版本A可以是當前使用的版本（控制），而版本B是做過修改的。例如，電子商務網站上的購買漏斗就很適合用A/B測試，即便是稍微改善下降率也能代表銷售方面的有顯著提升。”——維基百科

度量一個活動的價值

每個對產出物負全責或部分負責的價值交付團隊將識別和從事一項特定的活動，閱讀之前的文章“關注價值，非項目”（http://www.infoq.com/articles/）了解更多的細節內容。每個活動的目的是在該產出物所在的環境中直接或間接產生價值。而你需要在此考慮5個方面。

1. 價值的衰減。這實際是#非項目的所有要點。如果你不能緊跟變化，那就已經失敗了。價值是通過任何活動產生的，一旦實現了，就會開始衰減。衰減的程度依賴于具體的環境，但遺憾的是衰減是必然會發生的。

   

2. 價值會隨時間衰減

   你不會總是先進行最具價值的活動。活動間是有依賴關系的，而且已經臨近到期日期的活動的優先級可能也會比高價值的活動更高。

   

3. 已發生的成本和已創建的價值的趨勢對比

   局部最大化。如果你發現你的活動未對產出物產生預期的改進，有時就需要削減該產出物的總體商業價值以便將來增強了。例如，為了簡化將來的開發而去削減一個產品的功能。當你已經達到了收益遞減點或變更（或創新）的成本呈指數增加時可能就會發生這種情況。

   

4. 價值隨時間推移呈現局部最大化

   活動失敗。并非所有的活動都將對產出物產生積極的影響，有些可能會沒有作用甚至會有負面作用。這也正是為什么活動要小、要獨立并可以合在一起來度量。

5. “又會如何”要素。在增加任何活動到活動矩陣之前先問問自己“如果不這樣做，又會如何？”

   產出物是那些專注于為組織創建價值的活動的衡量標準。理解這一點了，在采用#非項目之路上就已經成功了一半了。

隱性項目

與流程或技術變革相比，#非項目更多的是文化和行為上的變化，尤其明顯的是隱性項目的出現。隱性項目是在#非項目或持續變更的環境中出現的一種模式，它實際上模擬了項目的結構，只是沒有正確命名罷了。

識別組織中的隱性項目，它對于理解項目的特征來說極為重要。與我們息息相關的是項目天然的臨時性、約束性和獨立性。

臨時性

從定義來看，項目是為實現一個特定變化或一系列變化的臨時性組織結構。這完全背離了#非項目的原則，#非項目發揚的是持續變化的模型，價值在于不斷地開發新的能力。當為生產單個輸出（可能會被稱為產出物）而形成團隊并定期轉向到不同的輸出/產出物時，可能就會出現隱性項目了。如果團隊是分散的，并且可能會為了在最后時期重新再處理產出物而重組時，情況會更為復雜。

你要小心，別把這一點和最終不會產生預期結果的商業實驗給搞混了。同樣，別把它和投入產出比已經開始下降的產出物的生命末期給搞混了。

耗費的成本與創造的價值隨時間推移的趨勢對比

約束性

在商業中，約束極其重要，在#非項目中更加重要。然而隱性項目會給團隊施加人為的限制，通常是限定時間、成本或范圍。如果你的管理者在特定的時間內要求一個特定的產品或預定義的活動，那它其實就是個項目。
記住，雖然個人活動也可以有到期時間，但是這些約束和固定的范圍或既定的目標有著本質上的不同。

筒倉

職責筒倉間必然會有問責制、發起和移交。因為項目是一種臨時的結構，所以項目團隊的一線管理者往往和項目經理會有所不同。這會導致多重審批、責任移交和無效的矩陣結構。
當管理間或職能領域之間有隱性的（或類似的）審批流程時就會出現隱性的項目了。無論是價值交付團隊還是職能等級的結構，#非項目都需要有一個對所有可交付活動負責的點。換句話說，團隊的一線管理者和特定產出物的“贊助者”應該是同一個人。

最后的思考

從根本上說，如果管理者和職工未抱著#非項目的心態，那么隱性項目就會開始出現了。最好的情況是試圖堅持到最后以維持目前的現狀，最壞的情況是他們陰險地想要推翻#非項目最初的目的和目標。
只要你記得這些反模式，就可以在它們影響到你之前發現和解決掉它們。

關于作者

Evan Leybourn開拓了敏捷商業管理的領域，把精益和敏捷運動中的成功理念和實踐應用到了公司管理中。他忙忙碌碌地做著業務帶頭人、顧問、非執行董事、會議發言人、有國際影響力的作者和父親。Evan對構建有效而高效的組織有著濃厚的興趣，致力于讓組織充滿積極參與和注重承諾的人。他認為只有這樣組織才能繁榮發展。他曾經擔任過私企和政府的領導和董事會的職位，這些經歷促進了他在商業系統方面的工作，在本地和國際產業研討會上他也會定期演講這些主題。Evan不僅編寫了《敏捷組織指導》，目前還在幫助IBM新加坡，希望他們成為前沿的敏捷組織。像往常一樣，所有思想、理念和評論都是他的個人觀點，不代表他的客戶或員工。

查看英文原文： #noprojects - Outcomes: The Value of Change