最好的流程是沒有流程
英文原文：The Best Process Is No Process
前年，Wikispeed團隊掀起了一場業界風暴。它們把敏捷實踐應用到了最傳統的行業：汽車制造業。它們在3個月的時間里就研發了一款綠色汽車，而這原本需要經歷10-25年的產品生命周期。
而且，得益于獨立組件的測試驅動開發，這款新車的設計具有很高的質量標準。這款車還遵循了非常高的安全標準。他們只用了3天的時間就研制出了一個漂亮的車體。這款車采用了業內能夠達到五星安全等級的最輕的底盤。他們在迭代中快速應對變化。這些全都不是什么問題，因為他們在設計中非常注重模塊化。他們可以把它由一輛敞蓬車改裝成敞蓬的小型卡車，而這只需要改裝一下底盤。
團隊創始人Joe Justice說，下面幾點是他們最重要的成功因素。WikiSpeed團隊：
- 使用了很少的材料
- 積極把變更成本降到了最低
- 在士氣高昂的分布式團隊上的協同工作
- 用結對的方式去削減培訓和寫文檔的時間
- 可視化了工作流程，發現不需浪費時間就可以創造性地解決問題
雖然Wikispeed最初的成功對敏捷社區來說還不算什么太大的新聞，但它卻對敏捷有著重大的意義。特別要提的是，它把敏捷應用在了軟件開發之外的領域中，證明了那些產品管理模式是多么缺乏效率。它揭露出令人難以想象的低效。
Wikispeed把產品生命周期從10年降到了3個月，他們的團隊效率比汽車制造業的產品研發團隊快了40倍。雖然產品相同，但為了節省開支他們只使用了常用的工具和高中生。這些高中生并不是專業的汽車設計人員，但他們是樂于奉獻、充滿幻想的業余愛好者。
他們的成績表明流程和敏捷文化的重要性。特別要提出的是，他們為了創造性地解決問題而持續不斷地消除任何障礙。他們的成績表明流程債對汽車制造業（乃至許多其他行業）的影響。
對于產品研發人員來說，流程雖然有用但也是無可避免的災難
比方說你要解決一個特定的問題。你并不在乎是否已經交付了如下的這些解決方案：
- 軟件
- 遵循的流程
- 具備某些功能的實物產品
你知道自己頭痛（偏頭痛）。你只想治好它，并不太關心治療方式。
你要的是一個解決方案。像Ted Levitt諷刺的那樣，“人們只想要個4分之一英寸的洞，而不想買臺4分之一英寸的打孔機”。他們只想要一個特定規格的洞。以此類推，從本質上說流程就是企業家為了交付解決方案而創建的“業務系統”。
產品研發本身就是一個流程。通常它由團隊來執行。產品研發最終可能產出流程、軟件或滿足特定需要的實物產品。如果一切順利，這個產品的研發流程就為該企業家和其他將來的企業家贏得了經濟效益。
簡單來說，對于許多產品研發人員來講流程是無可避免的災難。流程是為了滿足需要的交付機制。它組織我們的工作。經過一段時間以后，一個好的流程不僅能夠創造價值，而且它本身也是盈利性公司的財富。這些公司產生利潤并持續增值。所有人都希望產品開發流程能保持輕量級。我們希望流程是易于管理的，尤其是我們自己的公司。如果我們在這個流程下工作，就希望流程更貼近于實際的工作。Wikispeed證明了輕量級流程可以大幅提升生產力。
流程債
如前文所述，Wikispeed團隊積極地試圖消除流程債，因為他們要把變更成本降到最低。流程債是已有流程中慢慢形成的捷徑、變通方法和死鎖。經過一段時間以后，所有這些東西都會糾纏在一起。它就像盤意大利面，你拉出一根，就會有半盤也跟著動。流程債相當于商業層面的技術債。它是無用的復雜度。最重要的是，流程債破壞了有效的溝通。人們躲在流程、“最佳實踐”和“首選供應商”的身后，而不去討論和解決問題。使流程制度化是“行不通”的。它使團隊成員覺得被疏遠了，權利被剝奪了。
如果你們已經積累了數年古怪的變通方法，從沒有真正地考慮過做事的工作效率，那么現在就要付出時間的“代價”，因為你們過去走了捷徑。這種捷徑就是一種時間上的轉換。問題應該在早期解決。應該通過徹底“根治”杜絕此類問題的再次出現。反之，它就會在將來一次又一次地出現，你們必須要不斷地花時間去彌補。更糟糕地是，它還可能會影響到其他相關的部門。這反過來又會進一步引發更多的問題。最終，這會影響到客戶，無論他們知不知道。
在這種情況下，這種債務是用時間來計算的，特別是員工的時間。一個捷徑最終導致重大返工。這通常被認為是標準的“技術債”，這已經得到了充分地證實。技術債本身是大規模“時間轉移”商業問題的一個子集。它使你喪失主導權。
如果你把技術捷徑帶到產品中，就會使運維工程師執行浪費時間的變通方法。為了處理那些額外的復雜度，他們還需要一些額外的培訓和文檔。如果開發團隊欠下技術債，就會隨后影響到整個公司。于是它將不再只是技術債，而成為更加普遍性的問題。
就像Steve McConnell所指出的，技術債的影響要看具體的環境。從這層意義上來說，流程債很像金融債。有時，貸款還是有很多好處的。負債能幫你達成戰略目標。例如，你按揭購房，再把房子租出去，然后用租金還清利息和按揭。在這個例子里，貸款幫你創造了財富，否則你沒有其他的辦法。與此相反，某種類型的負債會快速瓦解財富。雖然你可以選擇辦理一張新的信用卡，用它來做15個月零利率的余額轉賬，但這可不是一個什么好主意。
許多開發人員都清楚，流程通常都可以被自動化。像流程一樣，軟件也可以被用來作為交付機制。腳本可以有效地替代一項服務和自動化一項服務。假設需要很多人月的工作量才能投產，你能做到哪種程度的“敏捷”呢？在最近人氣很旺的DevOps活動中（特別是在那些要求持續交付的敏捷實踐中）就采用了這樣的假設。
如果你可以用腳本實現發布流程，你的敏捷完全就是另外一個層次的概念了。雖然持續交付看起來是關于代碼的，但它實際上卻是關于擁有非常簡單的、合理的和自動化的流程的。它還把產品開發團隊解放出來去討論更多緊急的問題。
作為一名客戶，過多的流程債阻止你得到那些想要非常快速得到的東西。于是，偏頭痛又發作了怎么辦？
流程債與技術債相比是有區別的
它們最核心的區別在于，流程債是業務流程中過多的復雜度，而技術債是代碼中過多的復雜度。它取決于討論問題時以哪種層次的抽象去映射實際的問題域。假設你能以較少的復雜度做到完全相同的事情，你正在慢慢感受著流程債的影響。它正在勒緊你脖子上的繩索。假設你曾經嘗試腳本化一個已有的流程，不料卻從公司內不同的派系中發現拜占庭式的、多余的和前后矛盾的需求，你會發現它不是完全相同的。代碼都沒出現，怎么會是技術債呢？
在工作流程中，這兩種債有著截然不同的邏輯矛盾。
- 技術債，包括變量和成員函數的作用域不佳、關注點分離得不夠清晰、意想不到的負面影響。
- 流程債，就意味著不清晰的目標、狀態和組織職能，混亂的企業特性，由于部門間缺乏交流溝通而帶來的一些意料之外的負面影響。
Melvin Conway在1968年提出：“一個設計機構……不自覺地設計出反映自身組織結構的產品。”按照Conway定律，復雜度會以涓滴效應深入到代碼之中；而且，它是破壞人們之間的溝通和缺乏信任的根本原因。流程債導致技術債。
大多數公司能夠容忍某種流程債。企業可能基于戰略意圖會接受某些流程債，就像之前講的那個按揭購房的例子。然而，大多數流程債并不是戰略性管理級的，只是因為公司并沒有把它當成是個問題。舉個例子，即使在你的軟件里沒有欠下技術債，但是如果你的發布流程還沒有完全腳本化，那么你也欠下了流程債。
如何處理流程債
大多數建議都屬于那種“我知道了，以后再處理吧”的情況。我們應該立刻處理它，尤其是那些會降低效率的問題。這么做能讓你更加快速地前進。你們會提高客戶的滿意度，特別是當他們不滿意你們的彈性或速度不夠快的時候。
反復澄清戰略，直至人人皆知
Fortune Magazine指出，超過70%的公司無法成功執行戰略。在《聚焦戰略的組織》中，Kaplan和Norton發現大多數公司在每個月要花大約一個小時的時間來討論戰略，而他們大多數的時間都花在了無用功上。當公司討論戰略的時候，只會由很少的資深決策者秘密地開展。這種方式不利于戰略的實施。它必定無法得到一線員工的認同，事實上他們需要改變這種工作方式。
相比之下，在《像CEO一樣激勵》中，Suzanne Bates指出CEO的任務就是要不斷地宣傳戰略，努力地把它融入到每天的工作中。理想情況下，戰略應該簡潔明快、朗朗上口。戰略是由大家共同探索出來的，這包括公司中的每一個人。它找出所要完成的最重要的一件事。理想情況下，CEO要幫助員工在每天的日常工作中運用戰略。當你知道戰略是什么的時候，實現就沒那么難了。因此，如果你想讓大家根據戰略采取行動，就必須讓戰略淺顯易懂。
我在負責本地非盈利性俱樂部的時候，已經認識到了這項任務的復雜性。我通過和每個人單獨談話，幫助集團確定了最重要的組織目標。一旦這些都明確下來之后，我的主要目標就變成了以新穎的、適當的方式去交流優先級，以便志愿者們能夠感受到自己的貢獻是有價值的。與盈利性環境不同的是，我不需要向那些為我提供幫助的志愿者們支付費用。他們主要是想要一種精神上的滿足，他們完成了這些事，他們幫助了其他人。通過以合作的方式識別最高優先級并有計劃有步驟地交流溝通，我幫助組織在一年之內把規模擴到了兩倍。
混亂的戰略思維導致混亂的執行。搞清楚戰略的“拐點”能讓它發揮更大的作用。如果你有正確的戰略，就很容易取得成功。帶有充分理由的理性思維能讓你事半功倍。
如果你沒有澄清戰略，處理流程債就沒什么意義。你的戰略將定義哪些流程是戰略性的，哪些流程是可以被淘汰的。如果你對效率沒有一個清晰的認識，那么提高效率也沒什么意義。換句話說，如果你行駛在錯誤的方向上，跑得再快也沒什么作用。
使用軟件自動化工作流程
你只要澄清戰略，就可以簡化或替換那些沒用的流程，自動化那些有用的流程。對于軟件公司來說，自動化的工作能產出最大的收益。
作為一名面向客戶的開發人員，我曾經遇到過這樣的一位客戶，他讓會計師每個月花一周以上的時間為投資人做報表。這位會計師要先從數據庫里手工提取數據，隨后修改成精確的格式。隨著投資人的不斷增加，他不得不提供越來越多的預定義報表。
我在參加極客之后使用腳本語言編寫了幾個VBA，用幾個動態下拉框組織SQL查詢語句，它們可以在幾秒鐘之內生成完全相同的報表。從投資者的角度來看，軟件生成的報表也可以一樣使用。它們提供了完全一樣的價值。
他們讓開發人員把報表制作過程降到了幾秒鐘，會計師再也不用花上一星期的時間了，實際上以前那種報表制作過程是繁重的手工勞動，很容易出錯。這樣就把時間從最少1星期降到了最多5秒鐘：一次12,096,000%的生產力提升。而且，如果最終客戶和他的投資人認可報表的邏輯（比如不存在邏輯上的錯誤），那么這個過程就是有效無誤的。這還可以把會計師解放出來做其它的事情，去處理那些更需要思考、討論和分析的問題。這使他們非常地激動。
消除依賴
在一個流程里，當一個特定的資源被多人使用時我們往往會引入依賴。資源的競爭成了瓶頸。這就大大減緩了整體的進度。
多線程軟件開發是一種很好的類比。就像兩個線程間的沖突一樣，當它們訪問同一個資源時，你用互斥鎖確保線程不會覆蓋數據。在某些特定環境下，這種做法可能會產生死鎖。死鎖使這些代碼永遠掛在那里，消除這種死鎖通常能讓代碼即時執行。
假設你正在開發一個多線程應用程序，開發新特性時遇到了性能問題。你可以輕而易舉地找出原因。實際上，這種情況通常意味著你該查查哪個線程被鎖住了，你要防止應用的其他部分等待一個漫長的執行過程。如果線程鎖住了，通常你要把消息發送給線程反饋隊列，等著這個線程被釋放。
《產品開發流程》的作者Don Reinersten認為半成品和未發布的特性會嚴重影響大多數軟件開發的積極性。 “可以憑借工作量觀測產品開發清單：增加的周期時間、延遲的反饋、不斷調整的優先級和狀態報告。”如果列表中堆積了一堆未完成的特性顯然是一種極度的浪費，罪魁禍首往往都是項目死鎖。項目之中的依賴慢慢地搞砸了一切。
在軟件組織中，消除依賴是提升交付速度的最快方法。理想情況下這意味著項目會變得更小了。你可以專注于以產品和客戶優先。
這容易提升客戶滿意度。從根本上來看，特性可以被更加快速地發布。它們不必浪費時間去排隊。
通過移除不需要的細節來減少變數
如果你已經欠下了流程債，如果你在每天的工作中減少“符號”、變量或數據點，那么你會極大地提高生產率。這能增加溝通中的信噪比，讓你能夠更加地專注于感興趣的問題，而不必時常去處理那些“錯綜復雜的遺留問題”。
在九十年代末，流行記錄每個單獨的文件版本的源代碼版本控制資源庫。但是今天，大多數源代碼控制系統會把系統作為一個整體去跟蹤它的版本。對于一個擁有許多文件和可移植組件的大型系統，你只需要管理系統大的版本號，這就顯著降低了大多數流程的復雜度。這讓你能更容易地討論那些具體的問題。你只需要寫少量的文檔。一旦你的版本控制合理化了，測試、發布和運維就會得到簡化。
當然，使用這個具體方法會遇到很多困難，比如數據庫包的版本控制或者不同組件之間不一致的發布計劃。在這種復雜的局面下，你要減少所有的“阻力”，避免它們引發過于復雜的流程。
盡可能地消除默認情況下的承諾
缺乏信任會導致許多問題，比較常見的是會讓管理者引入一些在早期強加承諾的方法，這會破壞價值。許多工具（比如微軟的Project）試圖以大量依賴和截止日期去創建詳細的日程表。雖然這種粒度的出發點是增加計劃的可信度，但對中間的截止日期做出不必要的承諾往往使你忽略了本質上更加重要的優先級。充其量，你只能花費巨大的整體代價做做局部優化。保證一個項目按時交付，就得把其他項目往后排。這反而降低了詳細計劃的可信度，然后就意味著更多的詳細計劃。
在微軟的Project中，“結束后開始”（FTS）任務依賴隱藏著許多瀑布模型中的流程債。它也是微軟Project里默認的任務依賴。使用FTS的時候，你必須在特定的時間內完成特定的任務，所以你要指定所有的依賴任務必須要盡早地開始，以保證其他任務有充足的時間可以按時完成。
雖然這聽起來像是個很有水平的好主意（比如時刻記得“以終為始”），但它在任務的層面增加了很多不必要的硬性要求。你用FTS承諾了確定的期限，你就要在截止日期之前完成這些工作。如果有很多任務，就很難識別出最重要的任務或特性。承諾日期掩蓋了優先級。經過一段時間之后，你們忘記了優先級。每個人只記得承諾的日期。
在軟件專業人才之中，已經展開了一場#不估算的運動。它反對任何工作量估算。”#不估算”的支持者們聲稱，強迫開發人員估算會導致企業陷入這種FTS的思維方式。它最終會妨礙開發人員的工作，因為這種預期經常帶來不必要的壓力。過度的壓力不利于創造性的解決問題。它最終會讓企業和開發人員之間產生一些不必要的矛盾。
不必要的承諾不僅影響開發，對流程也具有深遠的影響。由Hope和Fraser合著的《超越預算》極力反對傳統的預算流程。雖然預算是上世紀50年代大型汽車公司履行財政紀律的有效方法，但同時預算也造成了大量的浪費。人們花數月的時間去辯論未來可能看上去會如何發展，他們需要什么財政資源，但他們實際上根本就看不清未來。反之，他們可能非常清楚現在的工作重點。
與此相反，還有類似于作業成本核算（ABC）的方法。ABC定期（理想情況下是每天）從本質上計算每項作業、每個客戶和每個產品的損益。這讓每個人都有了可以做出良好財務決策的工具，因為他們可以迅速得到與決策相關的財務影響。信息沒有藏在門后，而是已知的。這涉及每個人的利益，包括每一個一線員工。即時反饋影響員工的決策，他們的決策又影響公司的贏利能力：這就形成了良性循環。
使問題解決者專心地傾聽
很多時候，為了在極為繁雜的流程里“控制”復雜度而人為地設立了壁壘和邊界。很遺憾的是，這通常意味著那些最重要的信息永遠不會被真正地傳遞。沒有人行動，因為大家不了解全局。你要給他們發言權，讓他們談談最嚴重的挫敗。通常底層員工很清楚公司出現了什么問題，但公司恰恰忽略了他們的意見。他們只會在小范圍內講這些事情。因為他們害怕一些負面的后果。他們可不愿意成為那種大煞風景的人。
如果你覺得很難提供一個公開場所，可以試試創造一個只有幾位同事的場合。雖然這看起來可能有些怪，但這實際上是一套精練的即興演講技能。由于開始之前沒人知道具體話題，所以每個即興演講者必須與臺上的每個人做深入地溝通。
因此，他們為每個提議尋找最理想的回應，發現其中的矛盾。這件事自然而然地開展，然后推向高潮。通常（但不一定），當場就能完成提議的論證。系統化的創新來自于認真的傾聽。
這是一個協作創新流程的理想示例。在Tom Salinsky的《即興演講手冊》中闡述了即興演講的原則，即以“不錯，然后”推動團隊的創新流程。當開發一個課題時，兩位即興演講者同時登臺。他們只需要帶著自己的想象力。一旦其中一個開始演講，另一個要對首個“提議”做出直接地反饋。這臺短劇的目的是把這份提議變成“現實”。事實上，聽眾必須從內心深處認可提議的“創造力”。每個演講者并不清楚對方會有什么提議。這種不可預測性正是現場的魔力。每位演講者都要認真傾聽其他人在臺上的演講，只有這樣才能正常運行下去。這需要高度的緊張和信任。
在開始對話的時候，即興演講者要永遠認可上一個人講過的觀點。如果說“不行”或“還行，但是”就會扼殺創新的動力。這會使他人的動力驟減。與之相反，“不錯，然后”能推進協作。如果這個環境要求每個人都在其他人的基礎上去想其他的創意，那么就會迸發出很多好的想法。
在即興演講中，要格外關注互動本身的質量。一步一步向前推進，你們要用“不錯，然后”推進團隊的想法。你正在快速向前推進。隨著這種互動發現你們正在做什么（想想Dan North的刻意地發現）。這種互動需要充分地重視。當你想要實行同事們的提議時，需要把它充分融入到同事們正在做的事情里。
如果設計一個新的特性或是軟件架構，也可以使用“不錯，然后”，它也可以帶來同樣的生產力。起初最理想的結構還只是未知數，因為這依賴于要解決的問題。團隊就這些問題展開討論。首先，他們發散性地思考軟件最終可能會做成什么樣。這就會是一系列“不錯，然后”的提議。最終，它們都會體現在解決方案中。最好的解決方案就浮出水面了。有些想法之間可能會有矛盾之處，但是每個參與者仍要始終堅持一種“不錯，然后”的態度。
流程……阻礙了發展。流程經常強調“不行”或“還行，但是”，這扼殺了解決問題的創造性。當某些流程必不可少時，它們就會阻礙解決問題的創造性，延緩你整個企業的發展。
@theagilebastard：“人和交互優于流程和工具” 1985年Nelson Mandela在獄中說。#哲理 #敏捷 #看板法
好消息
通過減少流程債，你可以：
- 加快你交付產品的能力
- 減少出錯次數
- 使公司充滿活力，具有高昂的斗志
理想情況下，你的研發和生產流程可以像軟件一樣融入到公司里，比如，靈活編寫自動化構建腳本，讓它能夠根據客戶獨特的需求組合你的產品。你們可以用持續集成中運行驗收和單元測試套件去驅動發布的流程，然后由甲方簽收。你們甚至還可以直接發布，當然，這取決于你們做的是什么類型的軟件（比如網頁軟件）。某些團隊，比如工藝品批發商Etsy.com每天會發布30到50次。
最好的流程是沒有流程，只是一段寫得很好的腳本。它找出問題的本質。它所提供的解決方案就是按一下按鈕。它解放了人們解決問題的創造力。團隊成員能以最好的狀態完成工作，不需要被迫重復那些相同的單調的乏味的任務。
盡管人們（尤其是那些剛接觸敏捷的新人）關注敏捷流程，但卻容易忽略為什么會有敏捷流程。敏捷已經特意地簡化了流程。一旦你步入職業生涯，就可以專注于個體和交互。因為你用敏捷減少了無謂的流程，那些了不起的人推動了敏捷的效率。這可以向Wikispeed團隊咨詢。
如果你想減少企業中的流程債，就可以去克服流程債下載一本免費的工作手冊。
留言列表
