什么是業產技分層協作？
「業產技」是業務團隊、產品團隊、技術團隊的縮寫，代表研發流程中的三個典型的職能團隊。
在經典的研發協作流程定義中，更偏向于技術相關職能角色的分工定義，例如需求管理、迭代排期、缺陷跟蹤等協作流程，即使這些流程中有產品團隊和業務團隊的參與，協作流程的核心仍然是研發交付過程。
在企業的創業初期，業務人員、產品經理、技術人員可能都在一個部門，以項目的形式進行產品的研發，這個階段的協作效率較高，經典的研發協作流程一般可以滿足團隊的訴求。隨著企業產品線的演進和業務線的不斷發展，很多企業都會形成獨立的業務部門、產品管理部門、技術研發部門，由不同的主管分別管理。這三個部門的部分人員可能會形成虛擬團隊進行項目協作，完成產品研發和業務交付。
業產技分層協作方案就是描述這三個職能團隊的協作過程，實現從業務到技術的完整的價值單元交付過程。
業產技分層協作模式與SCRUM有什么關系？
SCRUM是一種被廣泛采用的敏捷研發協作模式。當技術團隊面對源源不斷的產品需求時，SCRUM可以幫助技術團隊找到一個科學的工作節奏，通過一個接一個的迭代，持續交付需求，并且可以對研發過程中的問題進行快速的改進，在下一個迭代就能馬上得到驗證，這樣不斷的探索整個技術團隊的極致工作效率。
而業產技分層協作模式，不僅僅關注研發交付過程，而是對業務、產品、技術三個團隊的工作流程分別定義，再通過分層的方式，讓三個團隊的協作有機的融合在一起。在業產技的“技”這個領域，SCRUM其實是業產技方案中的一環，是技術團隊的一種選擇。
建議：技術團隊我們推薦采用SCRUM敏捷研發的模式進行交付過程管理，云效也提供了成熟的項目模板技術團隊快速落地SCRUM；
我的團隊是否適合采用業產技協作模式？
SCRUM模式更注重的是研發團隊的交付效率，所以經常看到的關鍵詞是：“敏捷”、“高效”、“持續交付”，在SCRUM實施成功的研發團隊，我們能看到需求的交付時間較短，需求的吞吐率很高，但是仍然有兩個問題比較難回答：
技術團隊所做的需求，是否很好的支撐了公司的業務發展？
產品演進的中長期規劃是什么，現在所做的需求對于產品的發展是否具有價值？
第一個問題如果回答的不好，就會出現技術團隊很忙，效率也很高，但是仍然無法滿足公司的業務發展，或者無法讓業務團隊感到滿意。第二個問題如果回答的不好，就會出現產品技術團隊每天在不斷的接需求、做需求，功能在不斷增加和堆疊，但是產品的競爭力卻沒有提高，時間長了對產品的演進危害很大。
如果您的公司已經發展出獨立的業務、產品、技術的獨立部門，技術部門一般按照產品線進行劃分，而產品經理可能獨立出來，歸口在一個部門。業務部門通常按照業務領域或者地域進行劃分，由不同的業務經理分管。業務部門的原始訴求會首先經過產品部的確認和規劃，才轉到技術部門進行開發。
這三個部門的分工會讓工作流程更加專業，但是也會逐漸形成“部門墻”，并且您的企業已經形成上面的組織架構，并且被上述兩個問題所困擾，那么我們建議您選擇業產技分層協作模式來改善跨團隊的協作模式。
分層協作的“分層”是指的什么？
業產技分層協作模式覆蓋三個職能團隊，每個職能團隊關注的工作重點不同，因此需要為他們設計不同的工作流程，這些工作流程中的一些關鍵步驟又可以互相銜接在一起。在云效的產品方案中，不同團隊的工作流程需要用工作空間和工作項來承載。這里的分層指工作空間的分層和工作項的分層。
在以前沒有分層的協作模式下，多個團隊一般是在一個工作空間中進行協作，工作事項的類型也是比較單一的類型，一個需求從提出到完成，只有一條記錄，很像多人維護的excel表格。而在分層協作模式下，工作事項的類型出現多元化，不同的職能團隊有自己所負責的工作事項類型，這些事項通過關聯形成“拓撲狀”的需求結構關系，并且不同職能團隊的事項都在自己的工作空間中進行管理，避免了多個團隊在一個空間里的管理混亂。既做到了工作管理的獨立性，又實現了協作關系的連通。
醫院就診場景與分層協作非常類似，病人到醫院首先是“掛號”，醫生會根據這個號填寫病歷，相當于病人的原始訴求（主訴），然后檢查單、檢驗單、處方這些“事項”，并不會直接在病歷上操作，而是另外創建，并且和病歷建立關聯。每個事項的負責人只需關注自己的事項，而病人可以通過病歷（原始訴求）查看所有事項的進展。
分層協作可以解決哪些問題？
對于業務團隊：
·不確定核心業務目標是否得到產品研發團隊的有力支持；
·難以掌握研發進度和風險；
·不清楚產品下一步的規劃，是否能滿足業務的發展戰略；
以前僅scrum的交付方式，研發交付空間里面的需求顆粒度非常細，需求數量非常多，業務團隊在交付空間很難獲得更多有價值的信息，業務團隊的工作和技術團隊的工作基本是脫節的，需要進行大量的線下溝通，才會掌握最新信息，并且經常會出現信息滯后和延誤。
對于產品團隊：
·產品缺乏規劃，只是傳遞業務團隊的需求，產品競爭力難以提升；
·產品規劃停留在PPT，難以連接業務團隊的目標規劃和研發團隊的交付過程；
如果只是傳遞業務團隊的訴求到技術團隊，那么產品團隊會很容易迷失，會忽略對產品最有價值的一些特性建設，其實產品團隊經常需要做取舍，既要滿足業務的發展，又要為產品規劃一些中長期的產品專項主題，缺乏規劃的產品，可能會在一段時間后，出現產品競爭力下降，難以支撐業務發展的問題。
以前產品團隊都是把這些產品規劃/產品主題落在文檔/PPT中，這解決了需求按照產品主題歸類的問題，但是這些產品長期規劃和業務目標的關聯關系以及需求的進度（在交付空間中）到底如何，又是看不到的。
對于技術團隊：
·搞不清需求的源頭是什么，也就很難確定需求的價值；
·擔心技術資源沒有投入最重要的核心業務，沒有為業務創造價值
在“需求價值”的話題上，技術團隊和業務團隊其實有著同樣的共識。業務團隊希望最有業務價值的需求能夠得到技術團隊的大力支持，同樣，技術團隊也希望自己的優勢兵力投入到公司的核心業務里面。單純使用SCRUM研發交付模式，開發的工作內容跟業務團隊、產品團隊的工作是分離的，技術團隊希望能夠參與到業務規劃和產品規劃的工作中來。
接下來讓我們開始體驗一下業產技分層協作在云效產品中是如何實現的。
根據組織架構創建工作空間并設置工作項類型
分層協作最先需要確定的是工作空間和工作項的分層設置，這里要參考各個職能團隊的組織架構關系，下表給出了云效推薦的三層協作的模式，并且在云效的項目模板中也預制了業務空間、產品規劃空間、SCRUM研發交付空間的三類模板，供用戶選擇。
建議：業產技協作模式默認分為三層，用戶也可以根據團隊的實際情況進行調整，比如產品主導的企業，可以分為產技兩層，業務主導的企業可以分為業技兩層；
工作空間 | 工作事項 | 參與團隊及職責 | 關鍵詞 |
業務空間 | 客戶訴求 用戶反饋 | 業務團隊：
產品團隊：
| 原始訴求收集 建立需求依賴關系 跟蹤交付進度 驗收 |
產品空間 | 產品主題 產品類需求 | 產品團隊：
| 產品主題 需求價值評估 產品規劃路線圖 |
研發交付空間 | 產品類需求 技術類需求 研發任務 缺陷 測試用例 | 產品團隊：
技術研發團隊：
| 需求池 迭代規劃交付 應用變更 測試計劃 缺陷跟蹤 |
預制模板里已經設置好了工作項的類型和工作流程，用戶可以直接使用云效的預制模板，也可以在云效·Projex的企業設置里，根據實際的要求重新設置工作空間模板和工作項模板。
云效的工作項分為以下幾個大類，每個大類下可以根據用戶的要求創建工作項小類：
工作項大類 | 工作項小類（可自定義） | 填寫內容 | 創建人/負責人 |
原始訴求 | 客戶訴求 用戶反饋 |
| 由業務團隊創建，產品團隊負責 |
主題 | 產品主題 |
| 由產品團隊創建，也是產品團隊負責 |
需求 | 產品類需求 技術類需求 |
| 產品團隊創建，技術團隊負責 |
任務 | 設計任務 開發任務 測試任務 |
| 根據實際情況確定 |
缺陷 | 缺陷 故障 |
| 測試團隊創建，開發團隊負責 |
通過需求結構化掌握原始訴求的依賴關系和交付進度
業務空間創建好以后，業務團隊可以直接錄入來自客戶/用戶的原始訴求，指派給產品團隊，共同決策是否接受這個訴求，并確定實現的優先級。
建議：通過產品評審會的方式，業務團隊/產品團隊一起對原始訴求進行評審和澄清，再做決定；
建議：原始訴求的字段里可以增加「業務域」「產品線」這些字段，便于以后的分類跟蹤和匯總統計；
一旦決定接受原始訴求，產品經理需要盡快創建/關聯產品類需求，這樣把原始訴求和產品需求之間建立“依賴”關系。看到原始訴求的狀態更新為“已接受”，并且訴求有依賴的產品需求，業務團隊便可以知道自己的訴求有了著落，接下來只需要跟進依賴的產品需求的進度即可。另一方面，產品團隊也可以在產品需求中看到原始訴求的來源，更容易理解需求的價值。有時很多客戶會提出相同的訴求，這時就可以看到一個產品需求有多個原始訴求的依賴，這些信息會幫助產品團隊決定產品需求的優先級。
業務團隊可以直接在原始訴求的列表查看交付進度，也可以在訴求的詳情頁查看更具體的進度信息。在列表頁云效會展示原始訴求所依賴的產品需求的狀態進度，在詳情頁可以查看需求結構的完整拓撲圖，包括了產品需求下的技術任務都會在一張圖完全展示出來，如果有哪個節點的進度出現逾期，或者狀態長時間處于不合理狀態。
（需求全景圖在開發進行中）
建議：如果產品需求如果改動范圍較小，方案比較確定，可以將產品需求直接轉移到“研發交付空間”，如果產品需求規模和方案不太確定，不合適直接轉交給開發團隊，建議先轉到產品規劃空間，經過規劃和排期再轉交給開發團隊。
工作項詳情頁提供了詳細的分階段進度展示，業務團隊可以清楚的掌握工作項當前的所處階段和之前經歷階段的停留時間，幫助用戶從整體上了解原始訴求的進度，對完成的時間也有一個大概的預測。
規劃產品主題來選擇最有價值的產品需求
產品團隊是銜接業務團隊和技術團隊的一個重要職能團隊，產品規劃空間就是產品團隊進行產品發展路線圖規劃的工作空間。當產品需求數量急劇膨脹，需求的價值難以評估，研發團隊整日忙于交付需求，卻對產品中長期發展規劃不明確的時候，我們建議啟用產品規劃空間來規劃產品最有價值的需求，并進行合理的規劃排期。
產品規劃空間的核心工作項是產品主題和產品需求，產品需求描述一個具體的功能點，比較細碎，單個功能點之間是比較難進行價值對比的；而產品主題是描述一個完整的用戶使用場景，能夠較好的評估這個場景的用戶價值，在多個主題并行的時候，也比較容易橫向進行對比。
建議：當產品需求急劇膨脹的時候，梳理用戶核心使用場景，并創建對應的產品主題，每個產品主題的個數在10～20個左右為宜。
產品主題有兩個重要屬性：影響和成本。影響是對于產品目標/業務目標的價值，成本是粗略估算的開發成本，這兩個屬性都采用了“十分制”，然后通過影響和成本的比值，可以橫向對比多個主題之間的ROI。
建議：這幾個屬性值都可以用于排序，但僅僅是給產品團隊的參考，云效提供了手工排序的功能，用戶可以根據自己的要求進行排序；
產品主題下可以拆分出產品需求，也可以將已經存在的產品需求關聯到產品主題。通過產品主題的梳理和價值評估，可以從繁多的產品需求中找到一個產品演進的主線，在滿足業務團隊的原始訴求的基礎上，選擇更高價值的產品需求進行交付，不斷提升產品競爭力；
建議：產品主題的規劃和業務團隊的原始訴求之間要保持一個有機的聯系，原始訴求所依賴的產品需求，可能只有一部分會關聯到產品主題，沒有關聯上的，不代表不重要，如果完全以產品主題的優先級規劃產品需求，可能造成客戶的原始訴求的交付效率下降，因此需要尋找合理的平衡點；
通過研發任務/應用變更完成需求的交付
對于技術團隊的工作模式，本文不做過多的介紹，您可以參考云效SCRUM敏捷研發的最佳實踐說明。
建議：將產品需求拆分為多個技術任務，分配給不同的技術人員，共同完成產品需求的開發交付
由于技術團隊的分工不斷細化，很多技術團隊都會出現設計師、前端開發、后端開發、測試等多個職能小組，共同協作完成一個需求，這時如果在一個需求“工作項”上進行操作，會出現很多問題，比如前端開發完成，后端還在開發中，這時需求的狀態難以表達這種區別。如果將需求拆分為兩個技術任務，分給前端和后端，就比較容易區分。
小結：
業產技分層協作方案希望解決的是讓業務、產品、技術團隊清晰地看到產品交付的價值，用價值將團隊聚合成一個整體。
業務團隊建立業務空間，管理原始業務訴求。這些訴求可以來自業務目標的規劃拆解，可以來自客戶的反饋，再通過原始訴求與產品主題和產品需求的連接，清楚的掌握產品團隊的規劃和技術團隊的交付進度，還可以進行階段性的總結分析，與產品團隊、技術團隊一起review產品技術是否很好的支持了核心的業務目標。
產品團隊在產品規劃空間，對產品主題和產品需求進行價值評估和排期規劃，成為了銜接業務和技術的關鍵樞紐，共同決策出最優的產品發展路線。
技術團隊一方面在研發交付空間不斷優化提升研發效率和質量，另一方面通過與業務空間和產品規劃空間的連接，清楚的掌握需求的源頭和價值，并且積極參與到需求規劃決策過程中來，將研發資源投入最重要的業務目標或者產品目標。