成果導向

通常贊助軟體開發的人員對開發指標（例如速度或部署到生產環境的頻率）並不感興趣。他們更關心軟體將帶來的業務效益，例如降低手動工作量、提升銷售轉換率、提高客戶滿意度，也就是業務成果。成果導向團隊是受委託且具備能力來提供業務成果的團隊，此類團隊擁有具備執行所有必要活動以實現成果的能力的人員。相比之下，活動導向團隊既沒有能力也沒有受委託這麼做。他們只能執行實現成果所需的數項活動中的一項。

提供業務成果的委託與提供一定範圍的委託截然不同。提供範圍相對來說很容易。實現成果需要了解問題的人員與能夠為問題設計各種層級解決方案的人員之間的真正合作。最初的解決方案嘗試有助於更深入了解問題，進而導致進一步嘗試找出更好的解決方案。在產品管理組織與開發（提供範圍）組織分開的情況下，這行不通。

成果導向團隊必然是跨職能（多學科）的，而活動導向團隊通常是單一職能（單一專長）的。在最傳統的場景中，成果可能僅根據專案來定義。專案根據商業案例獲得資金，因此預期的成果是實現商業案例中承諾的內容。然而，根據專案規模，它可以組織成一個或多個團隊。當這些團隊沿著活動界線建立時，它將成為一個活動導向的專案（或計畫）組織。另一方面，我們透過將整體成果劃分為子成果，並將子成果分配給在提供子成果所需人員方面自給自足的跨職能團隊，來達成成果導向的組織。

Sriram 的書更詳細地說明如何使用成果導向結構建立有效的 IT 組織。

結果導向的潛在問題在於，從事相同活動的人們無法互相指導和學習。為了減輕這個問題，請建立實務社群，並指派具有指導能力且預算可組織社群活動、購買書籍和安排訓練的專家社群負責人。

以結果導向的設定執行大型專案絕對比以活動導向的設定執行更好。話雖如此，當我們擺脫以專案為中心的資金模式時，結果導向的方法才會真正發揮作用。在以結果導向的團隊執行的專案中，團隊的存續時間不會比結果與業務相關的時間長。專案結束時，團隊就會解散，這表示我們會在同一個領域的另一個版本以另一個團隊獲得資金之前，失去對結果的關注。這也會導致管理和報告結構不穩定的問題。這些都是以專案為中心的 IT 執行模式的限制，而透過 以業務能力為中心 的組織，可以克服這些限制。