建構更優流程 第一部分：流程應該是工具驅動還是需求驅動？

本文將從概念上探討流程為何應以需求為導向。此外，還將涉及如何設定目標，以實現能夠反映需求的流程，從而反向推導出理想結果。第二部分將提供一些指導，幫助您權衡需求，並將其融入您對流程最終形態的願景中。

在建構敏捷流程時 DevOps 對於正在進行數位轉型的組織而言，IT 領導者希望專注於優化。理想的流程應涵蓋所有必要的交付成果，納入治理等優先事項，並力求實現最高效的價值創造－同時允許對產品和流程本身進行迭代改進。 

然而，許多IT領導者可能會遇到一個障礙：工具。 DevOps 團隊使用的工具往往會決定工作流程和端到端流程的架構。於是他們面臨這樣一個問題：我應該妥協，讓工具環境決定我們的流程結構嗎？還是應該根據我們實際的目標需求不斷評估這種結構？

直截了當地回答標題提出的問題：流程必須以需求為導向，毋庸置疑。如果需求得不到滿足，就會對產品產生負面影響，並阻礙組織充分發揮其生產潛力。員工會感到沮喪，大量精力會耗費在流程本身，而不是為最終客戶和內部利害關係人創造可衡量的價值。

達到需求能夠驅動流程的地步

說「一切都應該以需求為導向」很容易，但這意味著組織必須花時間進行腦力激盪、研究，並制定一套真正量化需求的方法。需求也應基於能夠最終確保創造出更有價值的產品，並確保內部工作能夠有效率、持續地產出高品質成果的標準。

堅持流程必須符合要求，不排除使用特定工具。在某些垂直產業，例如航空航太和國防軟體開發領域，尤其需要使用特定工具，例如合規性監控工具。在這些情況下，工具本身至關重要，因為沒有其他方法可以滿足這些要求。

企業可能面臨的另一個挑戰是，人們更容易逐一產品選擇解決方案，而不是尋找符合特定需求的標準或功能。企業通常必須從需求出發，反向推導，才能發現需要哪些工具功能和標準才能滿足自身需求。最後，企業可能不得不為了滿足某些需求而對其他需求做出妥協。 

即使存在這些公認的挑戰，制定新流程或修訂現有流程的總體目標應該是不要讓工具（或其誘人的功能）左右流程架構。 DevOps 相反，應該讓需求驅動架構，並專注於團隊最終想要實現的目標。然後，提出一些關鍵問題，例如需要對流程進行哪些更改，才能找到最適合團隊的工具。

企業面臨選擇有限，被迫從需求出發，反向推導工具比較。

在產品驅動的世界裡，確保流程完全以需求為導向似乎不太現實。預先建置的現成解決方案通常只提供一套特定的功能和特性。即使解決方案可以定制，企業通常只能從有限的選項中選擇。

企業也可以選擇從零開始建立客製化解決方案，但如果要在所有流程中全面實施，成本可能會很高。企業可能會被迫“重新發明輪子”，一點一點地建立流程，而實際上，它應該做的是建造一個能夠創造價值的產品。 

此外，企業可能並不清楚應該在這些專有解決方案中建構哪些具體功能。除非他們本身就是解決方案提供者，否則他們無法憑空捏造規範。他們必須主要依賴現有解決方案來規劃其自研方案的配置方向。當然也有一些值得注意的例外，例如某些團隊創造了全新的架構（如 Slack），但在許多情況下，企業只是試圖建立現有解決方案的自有版本，通常會融合一些最受歡迎工具的功能。

因此，組織的流程必然反映出其使用的工具，無論這些工具是購買的還是自建的。承認這一點後，要始終將需求置於採購選擇或流程變更的首要位置就變得異常艱難——但這卻是一場必須打贏的仗。否則，工具最終會主導工作流程，並設定績效預期。團隊最終會感覺他們的勞動成果受限於工具的功能，而非流程最終應達到的預期目標。

無論是在尋找解決方案還是建立解決方案時，請確保流程以需求為導向。 DevOps 管道，或改造您目前的管道

誠然，當可供選擇的方案迫使你專注於特定的功能集或特性時，很難完全專注於需求。即使是從零開始建構或進行定制，組織也常常感到受限於現有方案或被認為合理可行的方案。

當被困於特定流程而導致結果不如預期時，問題就可能出現。就像家庭廚師的烹飪選擇僅限於有限的幾種食材一樣，當組織讓工具決定其創造力時，他們也會感到不滿。

為了確保需求得到充分認可，更遑論得到滿足，組織應定期盤點自身需求，並對目前使用的解決方案提出尖銳的問題。他們應列出滿足既定需求的功能和特性，然後評估各種解決方案，反向推導，採購/建構能夠最佳整合所需功能的工具。此外，他們還必須定期重新評估現有方案，以便根據需要改進流程或更換工具。 

組織領導者可以協作制定正式的需求清單、框架或矩陣，並利用這些來評估解決方案或流程是否「符合要求」。評估工具範例包括： CMMI——能力成熟度模型集成該組織還可以建立一個類似於以下框架： 航空航太業的DO-178B法規產品評估工具.

無論採用何種方法，都不要被工具本身所迷惑。畢竟，任何組織都可以拿起並使用相同的工具。這就像你去參加一個工藝品展銷會，結果發現每個人都只提供用從愛好商店貨架上買來的同一種工具包製作的相同產品——沒有差異，也沒有創新。只有當工具的運用能夠滿足特定需求並與獨特的願景相契合時，組織才能提供具有寶貴且不可替代價值的產品。

本文第二部分將深入探討如何編制需求清單、確定其優先級，然後利用這些需求形成流程願景，以便更好地反映目標結果。

學習如何評估工具選項，並視覺化您的選擇如何影響端到端流程。 DevOps 我們最近網路研討會上的管道：“揭秘 DevOps 景觀 Periodic Table of DevOps 工具 ＆ DevOps 圖表產生器“不"