【DevCloud · 敏捷智庫】軟件項(xiàng)目需求變更頻繁，如何做好有效的需求管理和規(guī)劃？

此文先發(fā)于華為云DevCloud專家服務(wù)論壇，鏈接：https://bbs.huaweicloud.com/forum/thread-24454-1-1.html

概述

圍繞項(xiàng)目需求變更頻繁，如何做好有效的需求管理和規(guī)劃，本文從背景、問題分析、解決措施、如何進(jìn)行需求結(jié)構(gòu)化管理？如何進(jìn)行需求優(yōu)先級(jí)管理？如何避免重要需求遺漏？幾個(gè)方面進(jìn)行了細(xì)致解答。全文字?jǐn)?shù)：__2662 字__，預(yù)估閱讀時(shí)間：___7 分鐘__。全程干貨。

背景

不管是項(xiàng)目型軟件開發(fā)還是產(chǎn)品型軟件開發(fā)，需求變更頻繁都是影響研發(fā)效能的第一號(hào)因素，在2019年中國DevOps現(xiàn)狀調(diào)查報(bào)告中也可以發(fā)現(xiàn)，超半數(shù)企業(yè)認(rèn)為需求的頻繁變更是阻礙軟件按時(shí)交付的主要原因。解決或緩解需求變更頻繁帶來的影響，是勢在必行的重要工作。

聯(lián)想閱讀

2019年中國DevOps行業(yè)現(xiàn)狀報(bào)告：中國信息通信研究院、華為云DevCloud、南京大學(xué)聯(lián)合發(fā)布

問題分析

由于每家企業(yè)的情況不同，包括客戶合作方式、人員能力水平、研發(fā)流程等各方面的差異，同樣是需求變更頻繁，所體現(xiàn)出來的具體癥狀卻有所不同，導(dǎo)致問題發(fā)生的根因也可能不同，所應(yīng)采取的措施也需要根據(jù)實(shí)際情況來選擇。根據(jù)我們的觀察以及與企業(yè)交流的經(jīng)驗(yàn)發(fā)現(xiàn)，一般都體現(xiàn)為如下幾種情況，接下來我們結(jié)合這些情況的部分實(shí)例來分析：

第一種情況：需求雜亂、經(jīng)常變更，難以管理；

第二種情況：領(lǐng)導(dǎo)或客戶時(shí)不時(shí)地要把某些需求提前，打亂了開發(fā)計(jì)劃；

第三種情況：做著做著發(fā)現(xiàn)有些需求遺漏了；

【第一種情況】軟件項(xiàng)目前期結(jié)構(gòu)清楚，開發(fā)到后期，需求變化多而細(xì)，如何管理，如何規(guī)劃。困擾我們的是前期需求不明確、不完善，導(dǎo)致后期需改動(dòng)，需求需要發(fā)生變更。而使用DevCloud的項(xiàng)目管理的支持不夠。

我們發(fā)現(xiàn)出現(xiàn)這種情況，往往跟客戶未能正確使用需求規(guī)劃有一定關(guān)系，存在著需求層次劃分不清晰、缺少規(guī)范機(jī)制等問題。例如，某客戶規(guī)劃一個(gè)用戶登錄功能，按照下圖所示規(guī)劃需求。用戶會(huì)將其中管理員登錄的Task放在第一個(gè)版本中發(fā)布，后期又增加了一個(gè)手機(jī)號(hào)登錄的需求，設(shè)置成Task放在第二個(gè)版本中發(fā)布，這樣一個(gè)Story里面存在多個(gè)不同版本（或迭代）發(fā)布的Task，不方便管理。由此我們可以將這個(gè)問題的根因定性為如何進(jìn)行需求結(jié)構(gòu)化管理的問題：

沒有區(qū)分跟隨項(xiàng)目進(jìn)展而持續(xù)產(chǎn)生的碎片化需求和系統(tǒng)/產(chǎn)品持續(xù)完善的功能特性；

對(duì)DevCloud提供的Epic-Feature-Story的需求結(jié)構(gòu)理解有誤，未能正確使用；

【第二種情況】軟件項(xiàng)目進(jìn)行過程中，領(lǐng)導(dǎo)需要提拉需求，在敏捷研發(fā)模式中該如何去操作？

提拉需求的意思也就是要將某些需求的優(yōu)先級(jí)提高，要求團(tuán)隊(duì)先實(shí)現(xiàn)它們，因而我們將此問題定性為需求優(yōu)先級(jí)管理的問題。解決此問題，我們需要了解：

為什么領(lǐng)導(dǎo)會(huì)要提拉需求？如果是合理的，那么我們就應(yīng)該提升響應(yīng)能力、優(yōu)化工作安排流程，使得優(yōu)先級(jí)調(diào)整對(duì)研發(fā)進(jìn)展帶來的影響最小化，且我們能夠盡快地響應(yīng)領(lǐng)導(dǎo)需要，先交付被提拉的需求；

這種情況發(fā)生頻率有多高？如果是經(jīng)常發(fā)生，那就是一種常態(tài)，而且是一種不好的常態(tài)，那我們需要去思考是什么導(dǎo)致了這種常態(tài)發(fā)生，并考慮如何從流程、制度、協(xié)作模式或人員能力等方面去做調(diào)整，減少過程中提拉需求情況的發(fā)生；如果是偶爾發(fā)生，那就可以特事特辦，為例外情況調(diào)整流程、制度反而會(huì)加重常態(tài)工作的負(fù)擔(dān)，沒有必要；

需要提拉的需求有無共性特點(diǎn)？比如是否都跟某個(gè)客戶有關(guān)，或者跟某個(gè)功能域（如退款）有關(guān)？如果能夠找到共性，那我們就可以針對(duì)這些共性去思考針對(duì)性的解決方案。

【第三種情況】由于外界原因經(jīng)常會(huì)臨時(shí)增加一些緊急需求，并且這是目前常態(tài)

臨時(shí)增加需求，首先是一個(gè)如何處理突發(fā)需求的問題；緊急需求，也就是說需要馬上就做，而且是插隊(duì)，那就不僅僅是緊急，肯定也是重要的需求，不然不需要插隊(duì)先做，所以這還涉及到需求優(yōu)先級(jí)管理的問題。但是當(dāng)兩種情況合在一起，我們需要將它定性為是重要需求遺漏的問題，反問一句就是?——?為什么這些緊急重要的需求無法更早預(yù)見？同樣的，我們需要了解：

具體是哪些外界原因？這些原因是否有共性，有的話，那就針對(duì)性處理；

增加的需求有無共性特點(diǎn)？有的話，可以針對(duì)性處理；

臨時(shí)增加有多臨時(shí)？我們是否有提高或改善響應(yīng)能力的空間，如果我們可以更快調(diào)整和響應(yīng)，使得這些臨時(shí)需求對(duì)我們產(chǎn)生不了什么影響，那么這個(gè)問題也就不再是問題了；

既然是常態(tài)，為何我們的流程沒有做出調(diào)整去應(yīng)對(duì)？是調(diào)整過流程或工作方式，還是無法解決問題，還是說不知道該怎么調(diào)整流程或工作方式去適應(yīng)？

解決措施

綜上，前面幾種參考情況經(jīng)分析后得出了根因，基于這些根因，我們將所要解決的問題重新描述如下：

如何進(jìn)行需求結(jié)構(gòu)化管理？

如何進(jìn)行需求優(yōu)先級(jí)管理？

如何避免重要需求遺漏？

如何進(jìn)行需求結(jié)構(gòu)化管理？

首先，并不是說任何情況下都需要進(jìn)行需求的結(jié)構(gòu)化管理。只有在需求較多、且需求之間存在關(guān)聯(lián)，而且即便是已經(jīng)實(shí)現(xiàn)的需求也需要進(jìn)行一定的管理、維護(hù)的情況下，我們才需要去思考需求結(jié)構(gòu)化管理的問題，此時(shí)，我們需要使用DevCloud提供的Scrum項(xiàng)目模板，因?yàn)槔锩嬗蠩pic-Feature-Story的需求結(jié)構(gòu)，以及需求規(guī)劃功能可以輔助我們進(jìn)行需求的結(jié)構(gòu)化管理。那么我們應(yīng)該以什么為脈絡(luò)來建立這個(gè)結(jié)構(gòu)呢？這就意味著，我們的需求結(jié)構(gòu)化管理，需要以產(chǎn)品或系統(tǒng)的功能特性的脈絡(luò)為依據(jù)。而軟件項(xiàng)目管理所需要關(guān)注的版本、客戶、模塊等信息，則可以通過需求的不同屬性甚至標(biāo)簽等方式來實(shí)現(xiàn)。

簡單來說，可以通過如下三個(gè)步驟來完成：

針對(duì)產(chǎn)品或系統(tǒng)建立DevCloud項(xiàng)目

確立Epic-Feature-Story的需求結(jié)構(gòu)

對(duì)不同模塊以及版本的管理，可以通過工作項(xiàng)的屬性來進(jìn)行管理

聯(lián)想閱讀

【華為云 · 敏捷智庫】如何進(jìn)行需求結(jié)構(gòu)化管理？

如何進(jìn)行需求優(yōu)先級(jí)管理？

需求優(yōu)先級(jí)的管理，其實(shí)是為了幫助我們確定先做哪個(gè)需求后做哪個(gè)需求，從而可以最大化我們的回報(bào)、最小化我們的風(fēng)險(xiǎn)或投入。要做好優(yōu)先級(jí)管理，或者更直接來說是優(yōu)先級(jí)順序管理，我們需要做到如下幾件事情：

確定優(yōu)先級(jí)模型：需要考慮的因素以及因素的綜合判斷原則，比如Kano模型；

排定需求優(yōu)先級(jí)順序：因素的具體量化和排序標(biāo)準(zhǔn)，例如成本收益法是按照收入還是按利潤的多少來排序；

調(diào)整需求優(yōu)先級(jí)順序；

改進(jìn)優(yōu)先級(jí)模型：根據(jù)反饋調(diào)整模型或模型的落地實(shí)施細(xì)節(jié)，以提升效果；

聯(lián)想閱讀

【華為云 · 敏捷智庫】如何進(jìn)行需求優(yōu)先級(jí)管理？

如何避免重要需求遺漏？

根據(jù)重要需求遺漏的事前、事中、事后的不同時(shí)間點(diǎn)，我們可以采取不同的措施。參照八二原則，我們需要確保常態(tài)問題有對(duì)應(yīng)的處理方式，軟件項(xiàng)目成員按照既定方案進(jìn)行處理即可，而特殊情況要有應(yīng)急機(jī)制指導(dǎo)現(xiàn)場處理、事后再復(fù)盤總結(jié)。

事中的處理：按照常規(guī)做法進(jìn)行處理，或是特殊情況特殊處理，先解決眼下的問題；

事后的處理：基于模型或思路進(jìn)行復(fù)盤，并落實(shí)為新的常規(guī)做法或特殊情況處理方式；

事前的處理：明確如何區(qū)分常規(guī)情況或特殊情況，并制定相應(yīng)的處理方式或應(yīng)急機(jī)制；

聯(lián)想閱讀

【華為云 · 敏捷智庫】如何避免重要需求遺漏？

參考附錄

相關(guān)文章

敏捷聯(lián)盟網(wǎng)站上的Epic術(shù)語解釋：https://www.agilealliance.org/glossary/epic

維基百科上的Kano模型詞條：https://en.wikipedia.org/wiki/Kano_model

相關(guān)書籍

Mike Cohn：《用戶故事實(shí)戰(zhàn)》

杰拉爾德·溫伯格：《成為技術(shù)領(lǐng)導(dǎo)者》

邱昭良：《復(fù)盤+：把經(jīng)驗(yàn)轉(zhuǎn)化為能力》

登錄 軟件開發(fā)平臺(tái) DevCloud

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。