項目事態(tài)升級管理程序

項目事態(tài)升級管理程序一、令人煩惱的需求變更作為一個軟件項目經(jīng)理，在項目開發(fā)進行中，你是否遇到過這樣的問題：客戶的一個電話，就推翻了之前你與客戶、與你自己的開發(fā)團隊，經(jīng)過再三討論而確認定下來的需求。之后你就重新開始了和客戶、和你的開發(fā)團隊進入新一輪的需求談?wù)撝?，甚至是無休止的談?wù)摚踔烈匦略O(shè)計現(xiàn)有的架構(gòu)。而面對這種情況，作為項目經(jīng)理的你是否會說：“我們無法拒絕客戶，但也無法立即滿足他的新需求，所以只好是推到以后再進行完善?！被蛘?，更極端些的想法：客戶總是在異想天開，客戶的需求在技術(shù)上根本無法實現(xiàn)……在與客戶新的需求論證中，你是否會對需求確認的重要性產(chǎn)生懷疑。因為在一開始已經(jīng)多次和客戶溝通，也在沒有任何異議的情況下得到了明確的答復(fù)，但當開發(fā)項目在不斷演進，客戶對系統(tǒng)的理解逐步加深之時，他們最終還是推翻以前自己想要的需求。而這時你會認為對于需求，只有獲取，沒有確認。而因為需求變更的原因，致使項目多次的延期后，客戶仍然說這不是他們想要的。你還是在抱怨客戶的需求像天氣一樣一直變個不停，最終，無論是你的抱怨還是客戶的需求變更只會令項目組中的開發(fā)人員疲于奔命，無所適從。在你的軟件項目進行開發(fā)之前，你和你的項目成員是否有過這樣的想法，在這次軟件項目開發(fā)中，一定要消除需求變更，不讓談?wù)摵玫男枨蟀l(fā)生任何的變更？首先，這種想法和認識是錯誤的，軟件項目開發(fā)中的需求變更是不能被完全消除的。無論是項目經(jīng)理還是項目開發(fā)人員，最好在項目開始之前就消除這種想法。需求變更是不可能被消除的，而〃消除需求變更”的想法卻需要被消除。消除需求變更的所有的努力和想法，在項目開發(fā)進行中通常都是費力不討好。項目開發(fā)過程中，需求的變更是不可避免的。雖然一般情況下，項目經(jīng)理花費了大量的心力和氣力去避免需求變更，可最后需求變更總是會出現(xiàn)。但這并不意味著項目不應(yīng)該做這方面的工作，無論是項目經(jīng)理，還是開發(fā)人員對于需求變更的正確態(tài)度應(yīng)該和對待軟件測試的態(tài)度一樣，在需求變更發(fā)生之前盡量減少需求變更發(fā)生的情況，以將需求變更帶來的風(fēng)險降到最低。在軟件開發(fā)項目中，需求變更可能來自方案服務(wù)商、客戶或產(chǎn)品供應(yīng)商等，當然，也可能來源于項目組內(nèi)部。對于需求變更發(fā)生的原因，細細追究起來無外乎以下幾種原因：范圍沒有■定就開始細化細化工作是由需求分析人員完成的，一般是根據(jù)用戶提出的描述性的、總結(jié)性的短短幾句話去細化的，提取其中的一個個功能，并給出描述（正常執(zhí)行時的描述和意外發(fā)生時的描述）。當細化到一定程度并開始系統(tǒng)設(shè)計時，范圍會發(fā)生變化，那細節(jié)用例的描述可能就有很多要改動。如原來是人工手動添加的數(shù)據(jù)，要改成根據(jù)信息系統(tǒng)計算出來，而原來的一個屬性的描述要變成描述一個實體等。2■沒有指定需求的基線需求的基線是指是否容許需求變更的分界線。隨著項目的進展，需求的基線也在變化。是否容許變更的依據(jù)是合同以及對成本的影響，比如軟件整體結(jié)構(gòu)已經(jīng)設(shè)計出來，是不容許改變需求范圍的，因為整體結(jié)構(gòu)會對整個項目的進度和成本有初步預(yù)算。隨著項目的進展，基線將越定越高（容許的變更將越少）。3,沒有良好的軟件結(jié)構(gòu)適應(yīng)變化組件式的軟件結(jié)構(gòu)就是提供了快速適應(yīng)需求變化的體系結(jié)構(gòu)，數(shù)據(jù)層封裝了數(shù)據(jù)訪間邏輯，業(yè)務(wù)層封裝了業(yè)務(wù)邏輯，表示層展現(xiàn)用戶表示邏輯。但適應(yīng)變化必須遵循一些松耦合原則，各層之間還是存在一些聯(lián)系的，設(shè)計要力求減少會對接口入口參數(shù)產(chǎn)生變化。如果業(yè)務(wù)邏輯封裝好了，則表示層界面上的一些排列或減少信息的要求是很容易適應(yīng)的。如果接口定義得合理，那么即使業(yè)務(wù)流程有變化，也能夠快速適應(yīng)變化。因此，在成本影響的容許范圍內(nèi)可以降低需求的基線，提高客戶的滿意度。三需求變更控制前面已經(jīng)說過了，在軟件開發(fā)項目開始之前，就要消除〃絕不允許發(fā)生需求變更”的思想。在項目進行，一旦發(fā)生需求變更，更不要不一味的抱怨，也不要去一味地迎合客戶的〃新需求”，而是要管理和控制需求變更。1■分級管理客戶需求軟件開發(fā)項目中，"客戶永遠是對的”和"客戶是上帝”并不完全的正確，因為在已經(jīng)簽定的項目合同中，任何新需求的變更和增加除了影響項目的正常進行以外，還影響到了客戶的投入收益，所以有的時候項目經(jīng)理反倒應(yīng)該為客戶著想。對于項目中的需求，可以實行分級管理，以達到對需求變更的控制和管理?！饕患壭枨螅ɑ蜃兏┦顷P(guān)鍵性的需求，這種需求如果不滿足，意味著整個項目不能正常交付使用，前期工作也會被全部否定。這個級別的需求是必須滿足的，否則就意味著否定自已的項目成員和成員的所有努力，所以定為“Urgent”。這通常是屬于補救性的debug類型，要救火?！鞫壭枨螅ɑ蜃兏┦呛罄m(xù)關(guān)鍵性需求，它不影響前面工作內(nèi)容的交付，但不加以滿足，新的項目內(nèi)容無法提交或繼續(xù)，所以是“Necessary”。一般新模塊關(guān)鍵性的基礎(chǔ)組件，屬于這個級別。△三級需求是后續(xù)重要的需求，如果不被滿足會令整體項目工作的價值下降，為了體現(xiàn)項目價值，也是開發(fā)人員自已的技術(shù)價值的證明，所以定為"Needed”。一般性的重大的有價值的全新模塊開發(fā)，屬于這個級別。以上三個等級是應(yīng)該實施的，但時間性上可以作優(yōu)先級的排列?！魉募壭枨笫歉牧夹孕枨?，沒有滿足這類需求并不影響已有功能的使用，但如果實現(xiàn)了則會更好，定級為"Better”。界面和使用方式的需求，一般在這個檔次?！魑寮壭枨笫强蛇x性需求，更多的是偶是一種設(shè)想，以及一種可能，通常只是客戶的的一種個人喜好而已，定級為“Maybe”。對于四級需求，如果時間和資源條件都允許的話，不妨做下去。對于五級需求，正如對它的描述一樣，做與不做是“Maybe”。2、全生命周期的需求變更管理各種規(guī)模和類型的軟件項目的生命周期大致可以分為三個階段，即項目啟動、項目實施、項目收尾。不要以為需求變更的管理和控制只是發(fā)生在項目實施階段，而是要貫穿在整個項目生命周期的全過程中。站在全局角度的需求變更管理，需要采用綜合變更控制的方法。項目啟動階段的變更預(yù)防正如前面強調(diào)的，對于任何軟件項目，需求變更都無可避免，也無從逃避，無論是項目經(jīng)理還是開發(fā)人員只能積極應(yīng)對，而這個應(yīng)對應(yīng)該是從項目啟動的需求分析階段就開始了。對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟項目經(jīng)理提出需求變更的幾率就越小。如果需求沒做好，基準文件里的范圍含糊不清，被客戶發(fā)現(xiàn)還有很大的“新需求空間”，這時候項目組往往要付出許多無謂的犧牲。如果需求分析做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另夕卜收費。這個時候，項目經(jīng)理一定要據(jù)理力爭，此時這并非要刻意賺取客戶的錢財，而是不能讓客戶養(yǎng)成經(jīng)常變更的習(xí)慣，否則后患無窮。項目實施階段的需求變更成功的軟件項目和失敗項目的區(qū)別就在于項目的整個過程是否是可控的。項目經(jīng)理應(yīng)該樹立一個理念，即〃需求變更是必然的、可控的，并且是有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風(fēng)險和修改基準文件?？刂菩枨鬂u變需要注意以下幾點：△需求一定要與投入有聯(lián)系，如果需求變更的成本由開發(fā)方來承擔，則項目需求的變更就成為必然了。所以，在項目的開始，無論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投人也要變?！餍枨蟮淖兏?jīng)過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更?！餍〉男枨笞兏惨?jīng)過正規(guī)的需求管理流程，否則會積少成多。在實踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認為降低了開發(fā)效率，浪費了時間。但正是由于這種觀念才使需求逐漸變?yōu)椴豢煽?，最終導(dǎo)致項目的失敗?！骶_的需求與范圍定義并不會阻止需求的變更。并非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非需求寫細了,它就不會變化了?！髯⒁鉁贤ǖ募记伞ｍ椖块_發(fā)過程中的實際情況是用戶、開發(fā)者都認識到了上面的幾點間題，但是由于需求的變更可能來自客戶方，也可能來自開發(fā)方，因此，作為需求管理者，項目經(jīng)理需要采用各種溝通技巧來使項目的各方各得其所。,項目加階段的總結(jié)能力的提高往往不是從成功的經(jīng)驗中來，而是從失敗的教訓(xùn)中得來。許多項目經(jīng)理不注重經(jīng)驗教訓(xùn)總結(jié)和積累，即使在項目運作過程中碰得頭破血流，也只是抱怨運氣、環(huán)境和團隊配合不好，很少系統(tǒng)地分析總結(jié)，或者不知道如何分析總結(jié)，以至于同樣的問題反復(fù)出現(xiàn)。事實上，項目總結(jié)工作應(yīng)作為現(xiàn)有項目或?qū)眄椖砍掷m(xù)改進工作的一項重要內(nèi)容，同時也可以作為對項目合同、設(shè)計方案內(nèi)容與目標的確認和驗證。項目總結(jié)工作包括項目中事先識別的風(fēng)險和沒有預(yù)料到而發(fā)生的變更等風(fēng)險的應(yīng)對措施的分析和總結(jié)，也包括項目中發(fā)生的變更和項目中發(fā)生問題的分析統(tǒng)計的總結(jié)。需求變更管S原則雖然需求變更的內(nèi)容和類型有各種各樣，但需求變更管理的原則卻是萬變不離其宗。實施需求變更管理需要遵循如下原則：(1)立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)(1)過評審后(用戶參與評審)，可以建立第一個需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線。(2)制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循