「這個需求是重要客戶新提的，非常著急，趕快解決。」 「有使用者新發現了一個 Bug，比較嚴重，優先修復這個。」 「老闆說這個功能這周必須要上，你先把目前手頭的事情放一放。」

諸如以上的情況我們在開發工作中時常發生，研發團隊裡各個都是「救火隊員」，然而這些救火隊員盡心盡力的完成了任務，也未必能取得客戶滿意，未必能實現客戶和市場的價值。那麼出現此類問題的原因是什麼呢？

問題分析

1.支撐工作與開發工作混合，沒有明顯的優先順序 2.團隊正常進行開發工作的時候，客戶經常會提出一些干擾團隊的衝發性工作。

那麼在管理研發團隊過程中，如何應對突發性需求，以提高團隊工作效率，保證團隊成員完成衝刺目標呢？

解決措施

在 VUCA 時代下，敏捷開發方式是時代的選擇，被越來越多的研發團隊開始實踐和採用。以下解決方案的內容均以敏捷方式敘述，包括但不限於 Scrum 框架。

對於混合模式

支撐工作與開發工作混合，出現突發性工作是常態，這裡簡稱「混合模式」，可以從人員分工角度思考，建議團隊人員最好有工作側重點的劃分。一部分人員精力用於開發，另一部分人員側重於應對突發工作。應對突發工作的人員時刻準備著問題風險的對應（比如開發工作儘量領取簡單、鬆耦合的）。應對開發工作的人員專心完成開發內容。在這裡也建議可以使用一些工具作為輔助，在敏捷專案管理產品中，多數都有管理工作項的功能。

對於開發為主模式

開發工作為主，伴隨著出現突發性應急工作，也就是正常的需求變更。這裡簡稱“開發為主模式”，開發為主模式下，伴隨著突發性應急工作的型別二，是我們很多研發團隊中的常態，也是本解決方案著重描述術的情況。從根本解決工作項優先順序的問題，系統地學習怎麼樣應對需求變更才是根本。

明確需求責任人，做到需求來源唯一

在研發團隊中一般產品經理或者需求分析師（Business Analyst）充當這個角色。我們來明確下需求責任人到底負責什麼。需求責任人至少同時要面對兩個方向。

一方面，需求責任人必須很好地理解專案中的利益干係人、客戶和使用者的需要（包括前面提到的突發工作項）及其優先順序，以便能充當他們的代言人。從這個角度理解，一般是產品經理充當需求責任人。

另一方面，需求責任人必須與開發團隊交流要構建的特性及其構建順序。需求責任人還必須保證特性的接收標準已有明確說明，讓團隊可以確定在什麼情況下需求責任人可以認為特性完成了。在這個角度理解，一般是業務分析人員和測試人員的角色。

同時，需求責任人還要在版本、迭代和 Backlog 層面都能夠持續做出良好的經濟決策，管理經濟效益。為了統一叫法、便於理解，後面需求責任人都由產品經理充當（類似 Scrum 框架中的產品負責人）。

綜上所述，產品經理的主要職責如下圖所示：

梳理產品待辦列表

高優先順序的工作項放到迭代待辦列表（更多關於迭代待辦列表的內容請參考下面的“瞭解更多”）中先做。

產品待辦列表是一個按優先順序排列的、預期產品功能的列表。工作項是 Backlog 中的待辦事項。對使用者和客戶來說，大多數的工作項都是有實際價值的特性和功能，當然也包括一些需要缺陷修復、技術改進、知識獲取等工作以及產品負責人認為有價值的任何工作（當然有價值的突發性工作也屬於工作項）。如使用 Gitee 中的「里程碑」梳理產品待辦列表。

梳理 PBI

梳理是指三大重要活動：

1.確立並細化工作項； 2.對工作項進行估算； 3.為工作項排列優先順序。

關於梳理活動想必大家有所瞭解，但好像具體又無從下手。如何能有效地將條目梳理的活動管理起來呢，這時候工具的作用就體現出來了。（以 Gitee 企業版為例）

重新定計劃

確保團隊容量適合，合理更新迭代目標。我們的目標是快速地重新制定計劃並根據開發過程中不斷出現的、具有重要經濟價值的資訊進行調整。因此，通過梳理以後原計劃準備做的工作項可能被移入到下一個迭代中實現，這裡體現的是「等價交換原則」，這樣雖然在迭代中增加了新的工作任務，但是同時我們也移除了迭代待辦列表中一個等工作量的任務，所以保證了工作量不變，進而保證迭代的速率。

迭代回顧，識別改善點

迭代回顧是一個會議，目標是持續改進流程，根據團隊的需要改進和制定流程，以提高士氣，提高效率，提高工作產出速率。幾個迭代下來，需要對這類突發工作進行度量分析，識別改善點，持續改善。

這裡利用 Gitee 企業版給出一個很好的小實踐，可以提供客觀資料幫助回顧。新納入迭代待辦列表的突發性工作項可以在 Gitee 的「功能設定-任務型別與狀態管理」下進行任務型別新建管理。如下新建「突發性工作」任務型別如圖所示：

有了「突發性工作」任務型別後，我們在接收到突發性的類似培訓客戶的需求而建任務時，就可以相應的選擇「突發性工作」。如下圖所示：最後，在迭代回顧時需要對這類的突發性工作進行分析。比如走過幾個迭代後發現平均每個迭代大概都會有4個左右類似的任務（工作量在16小時左右），那麼在新的迭代時就要預留相應的16小時，以便更好的應對這類突發性的工作。如下圖所示，可以使用型別看板進行快捷的檢視突發性工作的數量。

同步進行人才培養

同步需要進行的是人才的培養，向跨職能型團隊努力。不僅僅是應對處理突發性工作，而是讓團隊更高效。

每個任務應該由誰來做，或者說突發性工作應該由誰來做？答案很明顯，應該是能夠最快且正確完成這個工作的人來做。如果這個人不在了怎麼辦？或者他正在做其他工作，抽不出時間，但這個任務需要馬上完成。團隊成員都有責任考慮各種不確定因素，做出最好的選擇。如果團隊成員都是 T 型技能的時候，每個任務都有好幾個人可以做，那麼團隊就能夠在迭代執行期間幾個人全力完成制約工作項流程的任務，更靈活地平衡資源，使團隊更高效。

總結

本文是基於敏捷開發方式給大家詳細闡述避免突發性需求導致迭代週期過長的解決方案，選擇一款趁手的工具能幫助更好的管理實踐，達到事半功倍的效果。推薦Gitee 企業版，一款基於敏捷思維設計的研發管理軟體，想開始小範圍測試的企業可以現在也可以免費註冊使用。

Gitee 企業版不僅能為需求管理、迭代規劃、進度跟蹤等經典 Scrum 環節提供工具支撐，而且能很好的幫助企業有序管理研發全流程而且還是國內首屈一指的程式碼託管平臺，雲端/本地均可靈活部署，已為 18 萬家企業提供服務。

點選連結：Gitee.com，或撥打專屬客服電話：400-606-0201，免費試用 Gitee 私有化部署賬號，助力企業有序規劃和管理軟體研發，高效實現一站式DevOps。

微信小程式定製