有多少次...
我們在各自的觀點與理解下，一起錯過了該有的機會？！
明明是再簡單不過的功能需求，卻無法實現？!
投影片中，Mary 洞悉市場了解領域知識，Peter 熟於管理需求的實現，John 則是有著豐沛經驗的工程師。良好的機會本應帶來甜美的果實，但最終卻是以 Mary 痛哭流涕作結。到底是什麼問題導致了這樣讓人遺憾的結果？
需求的缺損！
市場驅動需求的產生，接著我們會探索需求並且描述需求的樣貌，然後透過工程與管理進而實現需求，並且交付需求。過程中，具備不同職能的專家會依照自己的觀點與理解來傳達資訊，一些隱含在需求中的情境資訊，免不了會在傳遞過程中遺失。然而，只有完整的需求才能創造真正的價值。因此，改善需求傳遞時，情境缺損所造成的需求缺損是一個直觀且重要的議題。此外，不同角色對於軟體產生的過程也有不同的關注點。銷售人員關注的是產品是否實現需求，管理人員關注的是如何調控過程，然而工程人員關注的是如何交付需求。不同的關注點會造成對於需求價值的認知不同，進而影響需求的流動。
BizDevOps 正是為了解決上述的問題而存在，所以 BizDevOps 就是：
在原汁原味的產品需求理解下，讓商業人員、管理人員和工程人員能夠有共同認知並且協作達成商業目的
實現 BizDevOps 該處理的第一件事：需求理解問題
如上述，需求傳遞免不了因為情境和領域知識的不夠，而使得不同的人對於需求有不同程度的理解。為了能夠解決這樣的問題，組建一個完整的團隊對於解決理解需求是相當重要的事情。
完整的團隊存在著具有不同技能的成員。為了讓團隊能夠盡量有能力獨立實現需求，團隊中的成員需要不排斥擁抱跨職能，跨職能不是只意味著一人多用，或者是取代誰的工作，更重要的是讓團隊成員能夠在需要的時候互相幫忙，並且可以擁有共通的知識讓溝通和理解更加順利。常見的團隊人數為 8~12 人，然而最佳的人數還是得回到實際開發的需求。根據 Dunbar’s number 可以知道團隊人數在 15 人以內時，成員之間可以建立深厚的信賴關係，所以在組建團隊時別忘了考量人數規模。人不是多就好，多人就會提高溝通與管理的成本。
團隊必要的人有時就太忙，而無法好好參與團隊的開發，該怎麼辦？
面對上述狀況時，要理解的是部門牆就真的是牆，組織線就會是溝通線。因此，我們需要根據利害關係人對需求實現的影響力，建立不同的資訊溝通與交換的方式，並且透過培養團隊內專責窗口來吸收利害關係人的情境知識與領域知識，以便改善情境缺損的狀況。
實現 BizDevOps 該處理的第二件事：觀點問題
軟體開發不像硬體開發，需求有些具體(功能性)，有些則相當不具體(非功能性)，因此擁有不同職能的專家對於需求的重要與否就會有不同的解讀，而這常會為軟體開發和 Day2 帶來顯著的不穩定性。
軟體開發大致上有四類任務，這四類任務分別為軟體帶來價值，它們分別是：
- 功能
- 臭蟲
- 風險
- 債務
為了能夠讓團隊內的所有人和利害關係人能夠對齊價值的觀點，教會對方相關知識往往不是首選，更重要的是建立共識基準。所謂共識基準最好的選擇便是客觀的數值，換言之，就是讓資料說話，而非使用膽量和直覺來大聲囔囔。舉例來說，將上述四類任務在團隊總任務數量所佔比例與商業目標 KPI (e.g. 使用者數量, etc) 對綁，進而得到彼此的連動關係，以便讓所有人知道任務類型的偏重對於商業目標的影響。如此一來，便能讓不同觀點與背景的人了解到相同的事情(結果)。這種基於資料所建立的共識，便是滿足需求打造有價值產品的價值洞見。
不過值得一提的是數值運算與轉換也同樣會使得細節消失，因此當透過價值洞見發現異常時，別忘了到現場(Gemba)弄清楚事情的全貌，再採取行動！
最後，用一句最簡單的話來描述 BizDevOps，那就是：
以目標為起點，對需求全生命週期的探索與實現
最後小小工商一下
CPHT 對 DevOps 有著最完整的了解與掌握。
如果您想要擁抱 DevOps 或想要追求更好的 DevOps 實現，歡迎聯絡我們！
讓我們與您一同從轉變中找出未來的可能性。