# BizDevOps 概論 - Augustin Lu

{%hackmd @DevOpsDay/BJXaW1_k6 %}

遇到什麼問題, 才會有 BizDevOps, 不然其實 DevOps 就夠了

- 情境
- Mary : Sales (領域知識, 負責實現)
- Peter : PM (管理知識, 負責調控)
- John : Engineer （工程知識, 負責交付）
- 忽然發現，某個情境當初沒評估好，問題在哪？
- 需求的缺損 <- 情境與領域的缺乏
- 優先順序難以最佳化
- 自主性不好形成
- 信任感的負循環
- 價值無法**實現**
- 錯失機會

- john（工程團隊） 不了解市場，不知道問題處理的優先順序

Devops PaPa say
- 避免侷域的改善，應該循著**價值流**找尋實現*價值*的方法

價值是什麼(價值怎麼來)
- 提供者給的價值
- 消費者給的價值

- ref: [Outcomt over output 1/2: Effort, outcome, output, impact](https://youtu.be/NfrxSOtUWqI?si=utW1eW1zzKn41n-1)
- https://medium.com/@kentbeck_7670/outcome-over-output-also-impact-and-effort-8f9eb0ce0dbb

看見全貌-四個轉換
- 組織層面
- 領域知識
- 管理知識
- 工程知識
- 技術層面

BizDevOps 主要解決下面兩個問題：
看見全貌-兩個問題：
- 需求換手造成的情境缺損與傳遞不效率
- 對於技術側的觀點不同

完整的團隊
- 同儕的團隊，而非層次高低的團隊
- 部門的牆就真的會是牆，組織線就是溝通線

鄧巴數（Dunbar's number）：5，15，50，100 人
考慮溝通成本

要先改善工程團隊效率，再來談擴增
- 因為現階段團隊可能有所謂「浪費問題」
- 擴增可能能解決，但浪費的問題還是持續發生

資訊同步的方法：
可允許失敗, 但不要錯太多錯太痛


讓工程師逐步成為隱形（業務）代表->避免哪天找不到業務（？

觀點問題
- 同一個東西, 不同角色有不同的看法
- 需要想辦法產生一致的價值理解
- 別急著說明，讓對方理解

如何產生一致的價值理解
- 不要單純想要教會你的領域知識
- 基於各領域資料的關聯，來產生共同的價值
- 不用告訴sales什麼是技術債->告訴他有技術債，用戶數就會下滑`（？`

找出產品的價值鑽石
- 透明和易取得的指標來建立客觀且不模糊的觀察點。

簡單扼要什麼是 BizDevOps
- 以目標為起點，對需求全生命週期的探索。

----
以下是聊天室 :D