愛華網(wǎng)典型場景：最近比較煩，煩客戶！我們現(xiàn)在正在給長江市政府做一個電子政務(wù)項(xiàng)目，其中有一項(xiàng)功能是網(wǎng)上婚姻申請登記功能。因?yàn)榍耙欢螄艺呷∠藦?qiáng)制性體檢這個環(huán)節(jié)，所以我們的工作流程也相應(yīng)的變更。沒想到客戶從中得到啟發(fā)：我們的許多工作流程做好后改動的可能性很大（例如政策調(diào)整、部門變動、領(lǐng)導(dǎo)班子重組等），干脆給我們做成可定制的功能，我們提一個最大的功能集合，你們做好了我們自己就可以隨需而變，嗯，這樣好！
可是對項(xiàng)目組來說這可是個災(zāi)難??！因?yàn)榭啥ㄖ频墓δ芡馕吨ぷ髁康谋对觯?p>分析：先說說大家對于這種現(xiàn)象的應(yīng)對方法吧。最典型的是通過與客戶的溝通來解決問題。怎么樣溝通呢？因?yàn)橛绕涫菍τ谲浖?xiàng)目的合同很難在簽訂之初就能夠精確定義的每項(xiàng)功能，所以靠合同是幫不上忙的。aihuau.com我和許多IT公司的老總們作交流，我開玩笑說我們IT公司都是清政府。為什么是清政府？清政府的特點(diǎn)之一就是喪權(quán)辱國的條約太多。大家往往只有苦笑：有什么辦法呀，客戶著急了就是一句潛臺詞：做不做，不想做滾蛋！想做的公司多著呢。所以你看合同是沒用的，那怎么辦呢？通常都是通過感情聯(lián)絡(luò)爭取客戶的同情。就像上面的場景中談到的一樣，明明是不合理的要求，可是客戶也會狡辯呀，“憑什么不給我們做，這可是合同范圍內(nèi)的工作！”。因?yàn)樵瓉碇徽f要實(shí)現(xiàn)工作流，而沒有談到定制的工作流算不算。問題出來了，看看怎么辦吧。當(dāng)然了，如果現(xiàn)在遇到類似的問題，您的組織都可以舉重若輕的化解，那您就不用往下看了。我們常聽到一句話就是“合情合理”，大家說這有什么好希奇的呀，老生常談！不過這句話在軟件項(xiàng)目的變更管理中卻有獨(dú)特的表現(xiàn)形式。從感情上與客戶去溝通很重要，但是您注意到它只做了一半工作，還有一半工作需要去講理。大家會反駁我說：講什么理！我們的客戶就是上帝，讓你做你就做！哪兒那么多廢話呀你。我注意到一個社會現(xiàn)象：客戶方的直接項(xiàng)目負(fù)責(zé)人從年齡上來看往往有年輕化的趨勢——三四十歲居多。這些人有什么特點(diǎn)呢？首先從教育程度上講他們往往都接受過正規(guī)教育，所以還比較講理——或者是因?yàn)楝F(xiàn)在職位還不夠高（開玩笑）？其次這些人是真正希望在工作上出成績的。當(dāng)項(xiàng)目真遇到負(fù)面的風(fēng)險時，他們愿意去說服自己的領(lǐng)導(dǎo)而不是不作為。正是基于以上兩點(diǎn)分析，我們先來介紹需求變更管理方法——變更管理七步法。七步法印證了我經(jīng)常鼓吹的項(xiàng)目管理三部曲：細(xì)化、量化、圖形化，七步法主要驗(yàn)證了細(xì)化和量化的必要性和好處。我們先來看看下面這幅圖：大家一看就明白了：噢，原來是項(xiàng)目管理三角形，扯上它干嗎呀。范圍可以理解為一個項(xiàng)目需要完成的內(nèi)容的多少，而時間質(zhì)量和成本則意味著完成這么多內(nèi)容的工作必須投入的時間成本以及對應(yīng)的質(zhì)量水平。我們再看下面這幅圖：這幅圖一看就不得勁，為什么？第一副圖中三角形內(nèi)切于圓，而第二副圖則完全破壞了這種內(nèi)切關(guān)系，所以顯得不倫不類。為什么應(yīng)該內(nèi)切？工作任務(wù)與投入應(yīng)該相適應(yīng)，這么一個常識性的東西在我們的IT行業(yè)中竟然被破壞得極為徹底！好，下面我們就一起來看看怎么樣這樣一幅項(xiàng)目三角形的圖形來講理！正如我們從變形的項(xiàng)目管理三角形所得到啟示：項(xiàng)目范圍變了，對應(yīng)的時間、質(zhì)量和成本也應(yīng)該發(fā)生變化！我們首先來看下面這張變更表表一：變更表所以一看這個表您就明白了，其實(shí)這個表反映了一個最樸實(shí)的道理：就是項(xiàng)目三角形在發(fā)生變形時需要保持的對應(yīng)關(guān)系。大家會說，我看明白了，可是這張表應(yīng)該怎么去使用？誰去填表？什么時候填表？如果有人不愿意填，那該怎么辦？下面我們分七個步驟來討論操作中可能會遇到的問題第一步首先得說到變更流程的事情。不管什么樣的變更，首先都有第一步：變更申請。有人就不樂意聽了：我們的客戶都是“變更命令”！這個回頭再說。只要有人提出變更，我們就稱之為變更申請。我們來看第一節(jié)變更內(nèi)容描述：大家會說哎呀，這個首先行不通！我們的客戶從來都是口述，打電話或當(dāng)面交流。這個我們不怕，客戶只要說出來，我們是不是就可以記錄下來（有人又不高興了：憑什么他說我記呀？別急，這樣做對項(xiàng)目組有好處）？除非客戶不做任何表示讓我們猜啞謎，我們是一定能夠把客戶的需求變更轉(zhuǎn)成文字記錄。大家可能又會說，我們可以幫他們記錄，可是他們不愿意簽字那怎么辦？簽字不是關(guān)鍵，此處我們關(guān)心的是把變更描述記下來，我們能不能把紀(jì)錄的描述給客戶看，客戶會不會翻臉不認(rèn)賬：“不是我說的！” ？不會的，果真這樣我們就不做了！第一個問題是不是解決了？往后看這可有點(diǎn)懸，什么叫對業(yè)務(wù)的影響呀？客戶要改需求還需要理由嗎？您說需要不需要？有人可能會說那是客戶的事情，我們干涉不了。這個說法可是大謬不然也！業(yè)務(wù)上不需要的功能我們?yōu)槭裁匆觯坑腥藭f:客戶不需要的功能他們會提出來給我們做嗎？老大，您可是真糊涂了！你還以為客戶每提一個需求都那么深思熟慮嗎？所以得先讓客戶想一想！又有人說了，您搞形式主義！客戶直接就寫“如果做，對業(yè)務(wù)是極大促進(jìn)；反之會對業(yè)務(wù)造成負(fù)面沖擊”，你有什么辦法？如果有人竟然有這樣的想法，我真是替你們的領(lǐng)導(dǎo)難過：什么叫斗智斗勇？你要動腦筋呀！你能不能從客戶的談話中間去捕獲信息？！你能不能去了解客戶的業(yè)務(wù)了解變更的必要性？??！當(dāng)然可以，要不還做什么項(xiàng)目！徹底成了客戶的跟班了！怎么樣？這個問題是不是也解決了？第二步我們再看第二步：技術(shù)評審。技術(shù)評審評什么？就是我們能不能做得了？比如說有這么一個糊涂客戶提出說他們要求訂單的最大處理時間是0.1秒，你應(yīng)該做什么？直接告訴別人做不了。當(dāng)然，大部分情況下技術(shù)還是可以滿足新需求的。好，第二步問題也解決了吧？第三步好，接著來看第三步。第三步評價對工期的影響，有人可能馬上會反駁說，工期評價沒用，反正是自己消化掉。其實(shí)此處將工期、成本、質(zhì)量都要量化的重要目的之一就是強(qiáng)迫我們的項(xiàng)目組先要想清楚，一個變更意味著什么。一定要把它落實(shí)到具體的數(shù)據(jù)上？為什么？我們在項(xiàng)目中、甚至工作和生活中，因?yàn)闆]有確切量化數(shù)據(jù)的情況比比皆是，而結(jié)果就是導(dǎo)致不必要的矛盾和摩擦。這也就是為什么細(xì)化、量化、圖形化，在細(xì)化的基礎(chǔ)上去量化才有意義。先看對具體活動工期的影響，可能是7天也可能是5天或其他；再看對于整體工期的影響，大家應(yīng)該對關(guān)鍵路徑的概念應(yīng)該比較熟悉了。一個額外活動的工期需要10天，但是體現(xiàn)在整體工期卻不一定是10天，還有可能是5天或者是0天，因?yàn)樗锌赡苷檬且豁?xiàng)非關(guān)鍵路徑上的活動。所以這兩種情況我們都要了解，簡單吧？好，第三步就這么簡單。第四步來看第四步，第四步也不會有什么歧義。因?yàn)橐豁?xiàng)變更有可能導(dǎo)致項(xiàng)目中需要添加新的人手（可能因?yàn)楠?dú)特的技術(shù)背景），而現(xiàn)有的人員怎么樣加班也是無濟(jì)于事的，所以項(xiàng)目組人員可能會增加。在看對應(yīng)的工作量增加，這個應(yīng)該相對容易，估算需要幾個人（很多情況會是一個人）、多長時間（天或小時），自然工作量就出來了。小時工資率是什么？我們國內(nèi)企業(yè)發(fā)工資一般會是基于工作天數(shù)的月薪，而許多外企則是基于工作小時數(shù)的月薪，所以這里有一個區(qū)別：一天可以是8個小時也可以是18個小時，難怪我們國內(nèi)企業(yè)加班是家常便飯：沒有請你周六周日來啊，不就是每天多那么幾個小時嘛！而外企加班相對少許多：額外的工作時間要付加班費(fèi)的（或許是工商局對它們看得比較嚴(yán)，而對我們國內(nèi)的企業(yè)則網(wǎng)開一面的緣故吧）。說遠(yuǎn)了，小時工資率的設(shè)定與計(jì)算可依據(jù)組織的特點(diǎn)設(shè)定，自己搞不定請財(cái)務(wù)部門幫你出個數(shù)吧。人時乘以小時工資率不就是人員工作量對應(yīng)的成本嘛！其他的有時候可能涉及到材料費(fèi)用、軟硬件的采購費(fèi)用、差旅費(fèi)用等，我們統(tǒng)一將它歸結(jié)為非人力成本好了。這樣我們將這兩部分相加就得到需求變更對應(yīng)的成本增加情況。第四步也是這么一目了然，沒有問題吧。第五步要說第五步還真不太容易給一個統(tǒng)一的建議，這得取決于項(xiàng)目組的情況。如果項(xiàng)目組沒有量化的歷史數(shù)據(jù)參考，只能以定性的方式去描述需求變更對于項(xiàng)目不同階段的影響。例如我們在測試階段的后期實(shí)施一項(xiàng)大的變更，那么它對測試階段的質(zhì)量影響是可以想見的：因?yàn)橐胄鹿δ芑蚋墓δ?，一定?dǎo)致更多的缺陷，而在回歸過程中如發(fā)現(xiàn)新的問題需要修改的話又可能帶來更多的問題。所以對于測試階段的質(zhì)量是負(fù)面的。對于產(chǎn)品運(yùn)行階段的質(zhì)量影響也是顯然的：系統(tǒng)的穩(wěn)定性、可靠性、安全性可能都會受到波及。當(dāng)然，如果項(xiàng)目所在的組織有些歷史數(shù)據(jù)作參考，那判斷起來就容易多了。如果變更的需求是30個功能點(diǎn),又假定測試階段缺陷密度是0.4/FP到0.8/FP之間,我們?nèi)菀淄茰y變更將導(dǎo)致增加的缺陷個數(shù)介于12到18個之間；而如果殘余缺陷密度是0.02/FP到0.05/FP之間，則上線后暴露給客戶的問題數(shù)目為0.6個到1.5個之間，也即一到兩個。我們將對質(zhì)量的影響是不是也可做相應(yīng)的分析？當(dāng)然嘍！第六步這個小節(jié)關(guān)注的是風(fēng)險，變更往往意味著更多的功能，更多的功能意味著更多的工作要做，因而面臨更多的變數(shù)，也即我們就常所說的風(fēng)險。比如說變更往往伴隨著工期的延長，而對于在外地開發(fā)的項(xiàng)目此種情形尤其有可能導(dǎo)致項(xiàng)目組成員普遍的厭倦情緒，對應(yīng)的風(fēng)險表述就是項(xiàng)目組士氣低下，導(dǎo)致工作效率下降，甚至?xí)鹑藛T的流失，對于項(xiàng)目組來說不得不預(yù)見這種類型的風(fēng)險，所以變更分析應(yīng)該做出對應(yīng)的風(fēng)險分析。第七步這一步就很簡單了，主要是根據(jù)前面的給定的各方面信息權(quán)衡以后做出是否變更的決定。有人又說了：才不是呢，如果是需求變更，那一定得客戶簽字，客戶如果不簽字，我們一點(diǎn)招數(shù)都沒有！我們再一次退而求其次：能不能把客戶的名字寫上，表明他（她）知曉這件事情？應(yīng)該是可以的吧至于表頭信息，我想應(yīng)該沒什么問題，所提供的相關(guān)信息主要是供以后做統(tǒng)計(jì)分析之用。好，到此為止，我們介紹了軟件需求變更管理七步法。
愛華網(wǎng)本文地址 » http://www.klfzs.com/a/9101032201/384368.html
