項(xiàng)目經(jīng)理做項(xiàng)目開發(fā)管理經(jīng)驗(yàn)總結(jié)談

項(xiàng)目經(jīng)理做項(xiàng)目開發(fā)管理經(jīng)驗(yàn)總結(jié)談一、項(xiàng)目過程根據(jù)我們項(xiàng)目出現(xiàn)的問題，我自己的總結(jié)的一些經(jīng)驗(yàn)以及我在培訓(xùn)中學(xué)習(xí)得知識總結(jié)下項(xiàng)目中碰到的問題和解決方案。1.1簽訂協(xié)議我們項(xiàng)目的協(xié)議內(nèi)重要寫的很模糊，范圍可大可小，致使我們在后期的工作中項(xiàng)目越做越大，但是項(xiàng)目費(fèi)用是不變的。在國內(nèi)的協(xié)議仿佛都是在打單時(shí)是基本上都承諾，也不會到細(xì)節(jié)，在協(xié)議簽訂后啟動后才發(fā)現(xiàn)問題。但協(xié)議中可以寫明假如需求變更什么級別的怎么樣，多少錢等;簽訂協(xié)議也是一個(gè)很高的技巧，建議把系統(tǒng)的邊界及功能范圍和解決方案與協(xié)議一起簽署，這樣客戶提出的新功能就可以暫且擱置。1.2團(tuán)隊(duì)建設(shè)在立項(xiàng)后盡早擬定該項(xiàng)目的負(fù)責(zé)人及項(xiàng)目經(jīng)理，這個(gè)人員非常關(guān)鍵，需要很強(qiáng)的綜合能力，特別的人格魅力方面。盡最大的努力將客戶的人員加入到我們的項(xiàng)目團(tuán)隊(duì)來，這個(gè)人也是我們將來和客戶的統(tǒng)一聯(lián)系人，客戶指定一個(gè)人和項(xiàng)目組進(jìn)行溝通，不能是張領(lǐng)導(dǎo)、王領(lǐng)導(dǎo)都來說幾句，假如他們意見不一致，那你只有得罪領(lǐng)導(dǎo)的選擇了，所以，項(xiàng)目的最初就要定好規(guī)矩，項(xiàng)目組只認(rèn)一個(gè)的意見，有什么規(guī)定你們內(nèi)部先統(tǒng)一再和項(xiàng)目組談，我們不想卷入客戶內(nèi)部業(yè)務(wù)部門之間的矛盾和政治斗爭之中。很多項(xiàng)目經(jīng)理都沒有自己選擇成員的權(quán)利，那么，就盡量發(fā)揮你的影響力去尋找那些你想要的人吧。成員的組成根據(jù)項(xiàng)目不同，相差較大，很難有什么具體規(guī)定，但是，一定要有精通客戶業(yè)務(wù)的人，很多小項(xiàng)目里，這個(gè)人就是項(xiàng)目經(jīng)理本人，大項(xiàng)目里會配備行業(yè)專家(Industryexpert)，這樣和客戶溝通起來才不會雞同鴨講，雙方才可以互相理解。項(xiàng)目經(jīng)理需要了解每個(gè)成員的情況，用就要用每個(gè)員工的專長。軟件行業(yè)是個(gè)非常特殊的行業(yè)，從項(xiàng)目的管理以及人員的管理都有它的特殊性。作為項(xiàng)目經(jīng)理，其實(shí)腦子里就是幾樣?xùn)|西：做哪些事情、做到什么限度、怎么交貨、手上的資源以及各個(gè)事情的優(yōu)先級。所謂多快好省那是人類的夢想，這四個(gè)方面都是互相矛盾的，屬于典型的又要馬兒跑，又要馬兒不吃草的類型?？紤]問題的輕重緩急方面，往往是把快放在第一位，各方領(lǐng)導(dǎo)都會給你最后期限，所以保進(jìn)度是第一位的；省是第二位的，公司的主線目的是賺錢，假如收入不能增長的話，至少費(fèi)用要控制?。缓檬堑谌坏?，沒辦法，誰都想精益求精，但是，沒有強(qiáng)大的資源保障，質(zhì)量只好先犧牲了；最后是多，客戶的規(guī)定源源不斷，如何減少客戶的盼望值，讓他們從抱負(fù)回到現(xiàn)實(shí)也是項(xiàng)目經(jīng)理的分內(nèi)工作。1.3需求調(diào)研在需求調(diào)研分析階段，項(xiàng)目組對客戶的整體組織結(jié)構(gòu)、有關(guān)人員及其關(guān)系、工作職責(zé)等沒有足夠了解以致于無法得到完整需求或最終經(jīng)權(quán)威用戶代表確認(rèn)的需求。由于項(xiàng)目經(jīng)理和需求分析員的工作問題以及調(diào)研工作做的不夠細(xì)，客戶參與限度都不高，客戶方相關(guān)負(fù)責(zé)人不明確或?qū)Ψ秶托枨筘?zé)任心不強(qiáng)，提出的需求具有隨意性，項(xiàng)目前期對需求的確認(rèn)不夠積極；多個(gè)用戶代表各說各話、昨是今非但同時(shí)又希望軟件盡早交付；我們的做法重要注重領(lǐng)導(dǎo)的需求，基本上都是領(lǐng)導(dǎo)說什么就是什么，致使開發(fā)出來的功能在實(shí)際使用中不是真正的使用人所需要的，項(xiàng)目后期需求變化隨意，導(dǎo)致項(xiàng)目范圍的蔓延，進(jìn)度的遲延，成本的擴(kuò)大。同時(shí)在我們的結(jié)識中是需求調(diào)研很關(guān)鍵，很多公司只是概念上認(rèn)為該階段重要，需要投入的時(shí)間長，但是事實(shí)上很多公司做不到這個(gè)，總想不久進(jìn)入編碼階段。并且為了趕進(jìn)度總想省做某些工作，少寫某些文檔，使我們無法拿出客戶需求以及后來功能變化和原先功能之間的對比度。導(dǎo)致上述現(xiàn)象的因素是我們沒有全面了解所有項(xiàng)目干系人的需求以及對需求調(diào)研的重視限度不夠。軟件開發(fā)是沒有捷徑可以走的，省掉的工作后面會有更高的代價(jià)回報(bào)。全面的需求來自所有項(xiàng)目干系人，不同的干系人其愿望和追求的目的往往相差甚遠(yuǎn)，因此對項(xiàng)目干系人的愿望進(jìn)行平衡也許是相稱困難的事情。軟件開發(fā)項(xiàng)目的目的就是實(shí)現(xiàn)項(xiàng)目干系人的需求和愿望。假如對項(xiàng)目所有干系人沒有進(jìn)行足夠的溝通和影響，使其盡也許地參與項(xiàng)目，則也許由于項(xiàng)目開始時(shí)項(xiàng)目范圍和一些具體需求不夠完整清楚，也也許由于某個(gè)項(xiàng)目干系人后期由于結(jié)識的變化而提出新的需求，導(dǎo)致工期的延長，成本的增長，甚至項(xiàng)目的完全失敗。因此，應(yīng)當(dāng)從項(xiàng)目的啟動開始，需求分析員及其項(xiàng)目成員就要分清項(xiàng)目干系人包含哪些人和組織，通過溝通協(xié)調(diào)對他們施加影響，驅(qū)動他們對項(xiàng)目的支持，調(diào)查并明確他們的需求和愿望，減小其對項(xiàng)目的阻力，以保證項(xiàng)目獲得成功。以下是一些有效的措施1、盡快熟悉項(xiàng)目干系人全貌有些項(xiàng)目在做需求調(diào)查時(shí)，由于受進(jìn)度規(guī)定等客觀因素影響，需求分析員與建設(shè)單位的技術(shù)部門交流較多，向業(yè)務(wù)管理部門和實(shí)際使用者調(diào)查不夠進(jìn)一步，導(dǎo)致軟件試用后不得不再對需求做較大調(diào)整，"從頭再來"的部分比例很高，大大超過進(jìn)度規(guī)定期間。因此，熟悉項(xiàng)目干系人全貌是進(jìn)行需求調(diào)查的第一步，也是需求調(diào)查的基礎(chǔ)。在定制開發(fā)項(xiàng)目的項(xiàng)目干系人中，最重要的是建設(shè)單位中的人事組織、業(yè)務(wù)關(guān)系。最佳是可以用組織結(jié)構(gòu)圖畫出相關(guān)單位的組織結(jié)構(gòu)；建立調(diào)研對象通訊錄以保證調(diào)研及分析期間及時(shí)的溝通。與此同時(shí)要注意項(xiàng)目干系人的主次關(guān)系，以便在他們之間的需求出現(xiàn)矛盾時(shí)可以進(jìn)行合理的取舍。熟悉建設(shè)單位內(nèi)部相關(guān)部門的業(yè)務(wù)劃分及它們之間的互相關(guān)系，為功能分析準(zhǔn)備了必要的資料，同時(shí)可以熟悉用戶方的各類人員，并及時(shí)進(jìn)行廣泛、有效的溝通與交流。特別要與客戶方業(yè)務(wù)與技術(shù)的規(guī)劃者和實(shí)際使用者進(jìn)行進(jìn)一步探討，收集必要的原始資料，保證需求調(diào)查的完整性、對的性。建設(shè)單位只是項(xiàng)目干系人中的一部分（當(dāng)然是重要的部分），為了更好地了解項(xiàng)目干系人全貌,還應(yīng)當(dāng)在建設(shè)單位組織結(jié)構(gòu)圖基礎(chǔ)上全體項(xiàng)目干系人結(jié)構(gòu)圖，以便更好更全面地進(jìn)行需求調(diào)研分析。2、具體描述各項(xiàng)業(yè)務(wù)，以利于讓所有客戶確認(rèn)盡也許全面具體地調(diào)查并且描述原有系統(tǒng)（這點(diǎn)非常關(guān)鍵，需要調(diào)查清楚原有系統(tǒng)的局限性以及優(yōu)點(diǎn)，以及用戶在這些系統(tǒng)中的操作習(xí)慣）和用戶希望將來系統(tǒng)具有的各項(xiàng)業(yè)務(wù)的流程，并將這些業(yè)務(wù)流程文檔化后與客戶進(jìn)行討論，對描述錯誤或不準(zhǔn)確不精確的進(jìn)行修改，最終讓客戶進(jìn)行確認(rèn)。從個(gè)人認(rèn)為，對業(yè)務(wù)解決過程了解的完整性和準(zhǔn)確性非常重要。雖然對數(shù)據(jù)來說都是查增刪改傳，但具體業(yè)務(wù)都是分為若干環(huán)節(jié)，每個(gè)環(huán)節(jié)都有其業(yè)務(wù)名稱，同一環(huán)節(jié)也許對多個(gè)數(shù)據(jù)集進(jìn)行不同操作，需要調(diào)查了解清楚才干設(shè)計(jì)出適合各流程業(yè)務(wù)節(jié)點(diǎn)用戶業(yè)務(wù)特點(diǎn)和習(xí)慣的軟件，使開發(fā)出來的軟件更受歡迎。當(dāng)然在進(jìn)行軟件概要設(shè)計(jì)時(shí)，要盡量排除業(yè)務(wù)流程的制約，即把流程中的各項(xiàng)業(yè)務(wù)結(jié)點(diǎn)工作作為獨(dú)立的對象，充足考慮他們與其他各種業(yè)務(wù)對象的接，在流程之間通過業(yè)務(wù)對象的互相調(diào)用實(shí)現(xiàn)其業(yè)務(wù)流程，這樣，在業(yè)務(wù)流程發(fā)生有限的變化時(shí)，就可以比較方便地修改系統(tǒng)程序而實(shí)現(xiàn)新的需求。對于各項(xiàng)業(yè)務(wù)的調(diào)查可以通過對以下資料的收集整理分析，這些資料來自各種各樣的項(xiàng)目干系人：遵循的標(biāo)準(zhǔn)、組織發(fā)放的工作手冊、作業(yè)流程、有關(guān)業(yè)務(wù)的上級告知、有關(guān)業(yè)務(wù)的辦事指南、辦理業(yè)務(wù)時(shí)需要填寫的登記表、各種相關(guān)的記錄報(bào)表及通過其他途徑收集的類似系統(tǒng)的介紹、技術(shù)資料等等。3、可視化需求調(diào)研，引導(dǎo)各種客戶挖掘他們的需求很多客戶由于自己缺少計(jì)算機(jī)知識，無法提出完整準(zhǔn)確、隱含的或潛在的需求。但若這些需求不能滿足將導(dǎo)致用戶的不滿。因此需求調(diào)研分析人員應(yīng)善于想用戶所想，不要膽怯用戶的需求多，不僅要擬定明確的需求，還要善于用啟發(fā)的方式與用戶探討隱含的或潛在的需求，并結(jié)合各種調(diào)研分析技術(shù)挖掘超過客戶盼望的令人興奮的需求。這就規(guī)定需求調(diào)研分析員要盡快完整地熟悉相關(guān)業(yè)務(wù)，從而可以站在用戶的立場看待軟件需求，想用戶所想，做好業(yè)務(wù)與計(jì)算機(jī)之間的橋梁。運(yùn)用可視化需求調(diào)研的方法可以很好地啟發(fā)用戶進(jìn)一步挖掘潛在的需求?？梢暬枨笳{(diào)研就是使用圖表等工具來啟發(fā)引導(dǎo)用戶清楚地?cái)⑹鲂枨?，并且使需求更加全面完善。對于高層領(lǐng)導(dǎo)，可以提供系統(tǒng)總體框架圖；對于業(yè)務(wù)管理人員，可以用業(yè)務(wù)流程圖來描述新舊系統(tǒng)的業(yè)務(wù)流程；對于客戶中的技術(shù)人員，可以用數(shù)據(jù)流圖、實(shí)體關(guān)系圖或UML中的各種圖形對系統(tǒng)進(jìn)行各種角度的描述；而對于業(yè)務(wù)管理人員、客戶中的技術(shù)人員、以及各層次各流程中的用戶，畫出用戶界面圖來進(jìn)行需求挖掘，是個(gè)比較有效的溝通方式。這里特別說明一下用戶界面的重要性。用戶界面的設(shè)計(jì)按理來說是軟件設(shè)計(jì)的責(zé)任，當(dāng)然客戶自己對界面有特別提出規(guī)定的除外。但是，假如把它提前到需求調(diào)研時(shí)（緊接著原有系統(tǒng)調(diào)研分析和系統(tǒng)模型完畢之后）與客戶進(jìn)行討論，則可以大大改善需求調(diào)研的效果。由于這時(shí)客戶對于將來的系統(tǒng)還沒有一個(gè)形象上的概念，或者有一個(gè)模糊的預(yù)想的概念需要表述、驗(yàn)證、明晰化、完善化。從我們后來的項(xiàng)目先做界面和用戶交流的經(jīng)驗(yàn)看（系統(tǒng)原形應(yīng)當(dāng)在需求分析的時(shí)候開發(fā)人員在分析師的指導(dǎo)下完畢真實(shí)環(huán)境中的開發(fā)，當(dāng)然開發(fā)只是界面的功能模擬，沒有底層代碼的實(shí)現(xiàn)），畫出用戶界面草圖與客戶進(jìn)行討論，可以大大激發(fā)他們提供更為準(zhǔn)確全面的需求，并且這些界面在后期的開發(fā)中也可以運(yùn)用。本來收集資料，描述業(yè)務(wù)，說明系統(tǒng)模型到了山窮水盡的時(shí)候，這種方法可以達(dá)成柳暗花明又一村的效果。因此，所謂需求就是“當(dāng)你按下各種相關(guān)按鈕（或輸入各種相關(guān)命令）時(shí)系統(tǒng)做什么”，所謂設(shè)計(jì)就是“當(dāng)你按下各種相關(guān)按鈕(或輸入各種相關(guān)命令)時(shí)系統(tǒng)怎么做”。需求的最終目的事實(shí)上是完整準(zhǔn)確地描述系統(tǒng)需要的各種接或“界面”，及它們的互相關(guān)系或與外部環(huán)境的關(guān)系，如界面中的某個(gè)按鈕按下去時(shí)，也許產(chǎn)生新的界面、新的按鈕、或者調(diào)用其他軟件硬件完畢某些功能。自頂向下，把這些界面及涉及到的數(shù)據(jù)描述清楚，就是一份不錯的需求。4、與其他項(xiàng)目小組成員共同協(xié)作、連續(xù)完善系統(tǒng)需求需求文檔完畢之后，并不是萬事大吉，把它扔給后面的設(shè)計(jì)人員就了事了。作為項(xiàng)目干系人之內(nèi)的項(xiàng)目組其他成員，對需求的有效性也起到某種限度的驗(yàn)證作用。雖然軟件項(xiàng)目的生命周期按照各種開發(fā)模型有不同階段的劃分，但每個(gè)階段的結(jié)束不是簡樸地把階段工作成果塞給下一階段的成員就可以了。特別是高科技的軟件開發(fā)項(xiàng)目，上一階段的工作成果往往要通過多次的溝通才干更為清楚地被下一階段成員接受，其有效性、合理性也要被下一階段的工作所檢查，通過檢查有時(shí)也有必要對上一階段的工作結(jié)果進(jìn)行相應(yīng)的調(diào)整，需求更是如此。因此，無論是同一階段不同人員之間，或是不同階段人員之間都應(yīng)根據(jù)需要互相協(xié)作，互相配合，共同完畢軟件開發(fā)任務(wù)5、《功能規(guī)格說明書》，這個(gè)是我們項(xiàng)目中最大的失誤，致使后來客戶的改動讓我們很被動。《功能規(guī)格說明書》反映了客戶提出的所有需求功能，我們也是按照《功能規(guī)格說明書》來開發(fā)的。后期客戶的變化都可以和《功能規(guī)格說明書》對比，具體怎么變更按照我們的變更流程來做?！豆δ芤?guī)格說明書》作為產(chǎn)品需求的最終成果必須具有綜合性：必須涉及所有的需求。開發(fā)者和客戶不能作任何假設(shè)。假如任何所盼望的功能或非功能需求未寫入軟件需求規(guī)格說明那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。并且注意以下幾點(diǎn)：(1)完整性每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計(jì)和實(shí)現(xiàn)這些功能所需的所有必要信息。不能漏掉任何須要的需求信息。漏掉需求將很難查出。注重用戶的任務(wù)而不是系統(tǒng)的功能將有助于你避免不完整性。假如知道缺少某項(xiàng)信息，用“待擬定”作為標(biāo)準(zhǔn)標(biāo)記來標(biāo)明這項(xiàng)缺漏。在開始開發(fā)之前，必須解決需求中所有的“待擬定”項(xiàng)。⑵對的性每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能。做出對的判斷的參考是需求的來源，如用戶或高層的系統(tǒng)需求規(guī)格說明。若軟件需求與相應(yīng)的系統(tǒng)需求相抵觸則是不對的的。只有用戶代表才干擬定用戶需求的對的性，這就是一定要有用戶的積極參與的因素。沒有用戶參與的需求評審將導(dǎo)致此類說法：“那些毫無意義，這些才很也許是他們所要想的?！逼鋵?shí)這完全是評審者憑空猜測。⑶可行性每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)行的。為避免不可行的需求，最佳在獲取需求(收集需求)過程中始終有一位軟件工程小組的成員與需求分析人員或考慮市場的人員在一起工作，由他負(fù)責(zé)檢查技術(shù)可行性。⑷要性每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來?！氨匾浴币部梢岳斫鉃槊宽?xiàng)需求都是用來授權(quán)你編寫文檔的“根源”。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，如使用實(shí)例或別的來源。(5)劃分優(yōu)先級給每項(xiàng)需求、特性或使用實(shí)例分派一個(gè)實(shí)行優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。假如把所有的需求都看作同樣重要，那么項(xiàng)目管理者在開發(fā)或節(jié)省預(yù)算或調(diào)度中就喪失控制。(6)無二義性對所有需求說明的讀者都只能有一個(gè)明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡潔明了的用戶性的語言表達(dá)出來。避免二義性的有效方法涉及對需求文檔的正規(guī)審查，編寫測試用例，開發(fā)原型以及設(shè)計(jì)特定的方案腳本。⑺可驗(yàn)證性檢查一下每項(xiàng)需求是否能通過設(shè)計(jì)測試用例或其它的驗(yàn)證方法，如用演示、檢測等來擬定產(chǎn)品是否的確按需求實(shí)現(xiàn)了。假如需求不可驗(yàn)證，則擬定其實(shí)行是否對的就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗(yàn)證的。⑻一致性一致性是指與其它軟件需求或高層(系統(tǒng)，業(yè)務(wù))需求不相矛盾。在開發(fā)前必須解決所有需求間的不一致部分。只有進(jìn)行一番調(diào)查研究，才干知道某一項(xiàng)需求是否的確對的。⑼可修改性在必要時(shí)或?yàn)榫S護(hù)每一需求變更歷史記錄時(shí)，應(yīng)當(dāng)修訂文檔。這就規(guī)定每項(xiàng)需求要獨(dú)立標(biāo)出，并與別的需求區(qū)別開來，從而無二義性。每項(xiàng)需求只應(yīng)在文檔中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。此外，使用目錄表、索引和互相參照列表方法將使軟件需求規(guī)格說明更容易修改。(10)可跟蹤性應(yīng)能在每項(xiàng)軟件需求與它的根源和設(shè)計(jì)元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性規(guī)定每項(xiàng)需求以一種結(jié)構(gòu)化的，粒度好的方式編寫并單獨(dú)標(biāo)明，而不是大段大段的敘述。6、需求變化項(xiàng)目的需要變化是肯定有的，并且變化一般都很頻繁，我們怎么應(yīng)對客戶的這種需求變化呢，以不變應(yīng)萬變。一方面在前期的需求調(diào)研要做好，盡也許的替用戶考慮，達(dá)成功能質(zhì)量滿足最大化。需求調(diào)研前期的《目的與范圍》和需求調(diào)研末期的《功能規(guī)格說明書》都要跟客戶簽字確認(rèn)，這樣既能保證我們所理解的需求就是客戶所要的，也使得項(xiàng)目末期跟客戶驗(yàn)收時(shí)有據(jù)可依。在項(xiàng)目中期是發(fā)生需求變更是很常見的，這時(shí)要做好需求變更管理流程。需求變更表，小的變更自己掌握，客戶規(guī)定的變更有開發(fā)人員和設(shè)計(jì)人員共同商討后提交項(xiàng)目經(jīng)理，項(xiàng)目經(jīng)理預(yù)估變更損耗工程時(shí)間，在一定階段一起提交給客戶，大的變更直接提交客戶，并且要把需求變更對項(xiàng)目產(chǎn)生的影響讓客戶知道，把球盡也許的踢給客戶，讓客戶在進(jìn)度、功能、資源三者中取舍出一個(gè)平衡來。對需求進(jìn)行分類評級，關(guān)鍵部分不能改動的做特別確認(rèn)（如系統(tǒng)架構(gòu)等，假如改變等于從頭再來）。同時(shí)完畢客戶簽字確認(rèn)，當(dāng)然假如能將這部分寫成協(xié)議細(xì)節(jié)中去是最佳。以下是我認(rèn)為變更的環(huán)節(jié)：第一步：客戶提出變更內(nèi)容客戶提交的變更必須基于書面形式客戶提交的變更必須有充足理由假如變更被拒絕，對業(yè)務(wù)的負(fù)面影響假如變更被接受，對業(yè)務(wù)的正面幫助第二步：為能否實(shí)現(xiàn)變更作評估從實(shí)現(xiàn)方式上考慮新的變更可否實(shí)現(xiàn)對于較復(fù)雜的情形，輔以簡樸的說明。欲詳述，可作附件解決對于簡樸情形，例如頁面布局更改，則無須說明第三步：可以實(shí)現(xiàn)看進(jìn)度進(jìn)度幾乎是絕大部分項(xiàng)目關(guān)注的第一要素對于活動級別的進(jìn)度影響對于項(xiàng)目整體工期的影響第四步：變更成本人力相關(guān)的變更成本o是否需要額外的項(xiàng)目組成員o項(xiàng)目組需要增長的工時(shí)數(shù)是否正常工時(shí)（工作日加班、節(jié)假日加班）項(xiàng)目工數(shù)報(bào)價(jià)非人力成本軟硬件費(fèi)用資料費(fèi)用等第五步：質(zhì)量和風(fēng)險(xiǎn)變更對質(zhì)量的多方面影響分階段影響（需求、設(shè)計(jì)、編碼、測試、維護(hù)）可靠性、安全性、可維護(hù)性、可用性等也許對團(tuán)隊(duì)士氣的負(fù)面影響也許引發(fā)的間接任務(wù)對工期的負(fù)面沖擊開發(fā)方的成本承擔(dān)也許超過力所能及的范圍第六步：需求變化的擬定6.2架構(gòu)設(shè)計(jì)撰寫具體設(shè)計(jì)是一個(gè)逐步細(xì)化、進(jìn)一步的過程。沒有人能一次就設(shè)計(jì)出完美的東西，需要及時(shí)的溝通，涉及與客戶的反饋，與其他項(xiàng)目組成員的討論，這樣有助于減少開發(fā)時(shí)偏離需求的風(fēng)險(xiǎn)。也就是說，在開發(fā)之前題，是建立在設(shè)計(jì)者的想法有客戶的確認(rèn)和開發(fā)人員的理解的基礎(chǔ)之上設(shè)計(jì)撰寫人必須與系統(tǒng)分析員反復(fù)討論，以透徹理解用戶需求；一項(xiàng)需求也許有多種方式實(shí)現(xiàn)，設(shè)計(jì)者必須與系統(tǒng)分析員擬定該需求將采用何種方式實(shí)現(xiàn)，將達(dá)成何種效果，以消除將需求映射為設(shè)計(jì)的歧義；討論過程中還也許會發(fā)現(xiàn)需求有不完備甚至錯誤的地方，在需求重新擬定后設(shè)計(jì)者需修正設(shè)計(jì)。設(shè)計(jì)文檔必須寫清楚各個(gè)模塊/接/公共對象的定義，列明程序的各種執(zhí)行條件與盼望的運(yùn)營效果，還要對的解決各種也許的異常。此外設(shè)計(jì)文檔應(yīng)當(dāng)遵循一定的寫作模式與版面風(fēng)格，使用統(tǒng)一的術(shù)語或慣用語，使得小組成員很容易理解。以上這些活動綜合起來將是一個(gè)很細(xì)致、很耗時(shí)的工作過程。就個(gè)人所知，一些公司的具體設(shè)計(jì)通常是由程序主管或少數(shù)核心的程序員撰寫的，他們通常也是系統(tǒng)架構(gòu)的重要作者或維護(hù)者。由于他們在開發(fā)團(tuán)隊(duì)中技術(shù)最為精湛，對架構(gòu)最為熟悉，他們最有資格評價(jià)現(xiàn)有架構(gòu)是否能適應(yīng)新的用戶需求，采用何種方式實(shí)現(xiàn)需求對架構(gòu)的沖擊最小。但是由少數(shù)人來負(fù)責(zé)所有的具體設(shè)計(jì)也許導(dǎo)致開發(fā)過程中的瓶頸甚至是設(shè)計(jì)的錯誤。當(dāng)任務(wù)比較集中的時(shí)候，設(shè)計(jì)者也許忙得透但是氣，而負(fù)責(zé)實(shí)現(xiàn)的同事反而在等米下鍋，比較清閑。于是為了讓自己不成為拖累進(jìn)度的“罪人”，某些設(shè)計(jì)者就會采用一種快捷方式來交付設(shè)計(jì)：他們會與系統(tǒng)分析員進(jìn)行初步的討論，然后撰寫一份粗糙的但仍然叫做具體設(shè)計(jì)的文檔，把它交付給負(fù)責(zé)實(shí)現(xiàn)的同事，再通過討論、即時(shí)通工具、電子郵件等方式解答對方提出的疑問。但由于具體設(shè)計(jì)自身不完備，他們不得不花費(fèi)更多的時(shí)間和精力與負(fù)責(zé)實(shí)現(xiàn)的同事溝通；并且他們卻很也許忘了把這些交流的成果更新到具體設(shè)計(jì)中去?。ɑ蛟S是他們太忙，沒有足夠的時(shí)間，又或許是他們認(rèn)為既然產(chǎn)品已經(jīng)實(shí)現(xiàn)，那么具體設(shè)計(jì)也就不必維護(hù)了。）其結(jié)果很也許是當(dāng)產(chǎn)品開發(fā)出來后，我們才發(fā)現(xiàn)它跟用戶規(guī)定的完全兩樣！原本在具體設(shè)計(jì)階段就應(yīng)當(dāng)發(fā)現(xiàn)的需求漏洞與在那時(shí)應(yīng)當(dāng)擬定的技術(shù)方案在實(shí)現(xiàn)階段甚至測試階段才暴露出來，而這時(shí)大家往往有木已成舟的感覺，改動的難度比設(shè)計(jì)階段高數(shù)倍甚至十倍以上，畢竟任何再牛的人都有自己的局限。對于以上問題我提出全員設(shè)計(jì)，全員設(shè)計(jì)的含義就是把具體設(shè)計(jì)的工作進(jìn)行適本地分解，把它們分?jǐn)偟叫〗M內(nèi)其它同事身上，讓大家都參與設(shè)計(jì)。這可以說明如下：當(dāng)一組用戶需求基本擬定下來后，程序主管需要估計(jì)需求的相關(guān)性、需求的優(yōu)先級、設(shè)計(jì)的難易限度、設(shè)計(jì)的工作量等，將該組需求分解為一或多項(xiàng)設(shè)計(jì)任務(wù)，并指定給適當(dāng)?shù)耐?。參與設(shè)計(jì)的每個(gè)人必須負(fù)責(zé)至少一項(xiàng)設(shè)計(jì)的撰寫任務(wù)。設(shè)計(jì)者從系統(tǒng)分析員處獲得具體的用戶需求，并與系統(tǒng)分析員反復(fù)溝通以透徹理解用戶需求。他還要分析系統(tǒng)架構(gòu)及產(chǎn)品的已實(shí)現(xiàn)與/或已規(guī)劃部分，理解架構(gòu)的設(shè)計(jì)理念，理解產(chǎn)品不同模塊之間的協(xié)作關(guān)系，理解架構(gòu)與產(chǎn)品之間的約束和依賴。當(dāng)然對系統(tǒng)架構(gòu)和產(chǎn)品的分析不也許窮盡每一個(gè)細(xì)節(jié)，只要分析與即將開發(fā)的模塊相關(guān)的內(nèi)容即可。一項(xiàng)設(shè)計(jì)任務(wù)，它也許需要多個(gè)程序員完畢。比如用戶界面或網(wǎng)頁由某位或某組同事負(fù)責(zé)，而業(yè)務(wù)邏輯組件則由另一位或另一組負(fù)責(zé)，數(shù)據(jù)庫部分則又由其它同事負(fù)責(zé)。設(shè)計(jì)者必須考慮他們的立場，以各方面都相對容易理解的方式寫清楚重要的模塊/接/對象定義，明確相應(yīng)的調(diào)用規(guī)則與重要邏輯解決。假如某項(xiàng)設(shè)計(jì)任務(wù)所涉及的內(nèi)容太專業(yè)化，設(shè)計(jì)者并不熟悉相關(guān)的內(nèi)容（比如某位C#程序員并不熟悉如何編寫一個(gè)存儲過程），他可以用描述性的文字說明該部分的設(shè)計(jì)規(guī)定，并知會相關(guān)的同事補(bǔ)充。其它同事在補(bǔ)充時(shí)可以對這些描述性的文字重新整理，以更加確切地表達(dá)設(shè)計(jì)內(nèi)容，更符合文檔的書寫慣例。在設(shè)計(jì)文檔完畢后，設(shè)計(jì)者必須把他提交給程序主管或由程序主管指定的程序員審閱。個(gè)人推薦由其它程序員而不僅僅是程序主管來審閱。不用緊張等待多個(gè)人的審閱意見是否也許導(dǎo)致一份設(shè)計(jì)滯留很久。大家可以并行地工作，不必是A審閱后才干B審閱?？梢越徊鎸忛啠碅的設(shè)計(jì)由B、C審閱，B的設(shè)計(jì)由A、C審閱等。審閱意見可以用多種方式（如討論、即時(shí)通工具、電子郵件）反饋給設(shè)計(jì)者，設(shè)計(jì)者負(fù)責(zé)匯總這些意見并修正設(shè)計(jì)。以個(gè)人的經(jīng)驗(yàn)而言，通常設(shè)計(jì)交付審閱后半天內(nèi)就可以收到反饋意見了。設(shè)計(jì)通過反復(fù)地修正直至沒有人再提出修正意見，這時(shí)就可以由程序員實(shí)現(xiàn)了。以個(gè)人的經(jīng)驗(yàn)而言，一份設(shè)計(jì)通常兩、三輪反饋后就可以定稿了。假如多次反饋后仍不能定稿，極有也許是:a）需求尚未明確，各個(gè)方面（涉及客戶、系統(tǒng)分析員或設(shè)計(jì)者）對需求的見解不統(tǒng)一b）技術(shù)或系統(tǒng)架構(gòu)存在嚴(yán)重的限制，無法用較方便的方式實(shí)現(xiàn)全員參與設(shè)計(jì)好處、風(fēng)險(xiǎn)與不合用的團(tuán)隊(duì)如下：全員設(shè)計(jì)可以帶來以下明顯的好處有助于平衡工作量，加快開發(fā)進(jìn)度。具體設(shè)計(jì)的任務(wù)分解后，程序主管或核心程序員可以有更多的時(shí)間解決其它的事務(wù)，比如關(guān)注軟件的開發(fā)質(zhì)量或改善系統(tǒng)架構(gòu)。具體設(shè)計(jì)的撰寫任務(wù)分解后它們可以并行地撰寫，這將極大地提高設(shè)計(jì)撰寫的進(jìn)度，節(jié)約時(shí)間。有助于培養(yǎng)程序員的大局觀。每位撰寫設(shè)計(jì)的程序員不再僅僅只關(guān)心自己負(fù)責(zé)實(shí)現(xiàn)的模塊，他必須從更高的層次考慮和理解設(shè)計(jì)。有助于加強(qiáng)同事之間的交流與協(xié)作。設(shè)計(jì)者需要與系統(tǒng)分析員、其它程序員、審閱者進(jìn)行反復(fù)的交流和溝通，事實(shí)上每份設(shè)計(jì)都是多人協(xié)作的成果。更多的溝通有助于集思廣益，有助于避免一、兩個(gè)人的傾向性意見導(dǎo)致錯誤的設(shè)計(jì)。每位設(shè)計(jì)者都需要對自己撰寫的設(shè)計(jì)負(fù)責(zé)，他還要向其它同事的設(shè)計(jì)提供審閱意見或技術(shù)建議，彼此的工作是互相支持和依賴的，這有助于減少“只掃自家門前雪，不管別人瓦上霜”的想法。推行全員設(shè)計(jì)的潛在風(fēng)險(xiǎn)在某種意義上，全員設(shè)計(jì)也許增長交流的成本。兩個(gè)人之間有一條交流途徑，三個(gè)人之間最多有三條，四個(gè)人之間最多有六條。途徑越多，信息量就越大，而這些信息不見得都是有用的信息。具體設(shè)計(jì)的任務(wù)分解后，不可避免地有更多的人參與交流和溝通，大家要花更多的時(shí)間來理解別人的想法，也也許要花