軟件項目估算與計劃不是一般的難_第1頁
軟件項目估算與計劃不是一般的難_第2頁
軟件項目估算與計劃不是一般的難_第3頁
軟件項目估算與計劃不是一般的難_第4頁
軟件項目估算與計劃不是一般的難_第5頁
已閱讀5頁,還剩15頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

摘要:估算、計劃、計劃跟蹤是項目管理的主要工作,難度之高超乎你想象!光靠學習項目管理理論難以管好項目,而往往真能管好項目的都是那些在具體項目中滾打出來的實干人士。本文將會讓你全面學習項目估算、計劃、計劃跟蹤的知識,體驗實際項目管理的難度,學到提高項目管理水平的一些方法。本文將會分7篇為你分享:從建筑工程說起估算要估啥?估算如何做出來?計劃有什么內(nèi)容?計劃是如何做出來的?如何跟蹤計劃?優(yōu)秀項目經(jīng)理是怎樣煉成的?從建筑工程說起大家都喜歡用建筑工程與軟件工程做比較,但我們常常所說的建筑工程只是指建筑施工部分,而不是一個完整的建設項目。我們常常將施工項目管理與軟件項目管理進行比較,這是不合適的。一個完整的建設項目,由甲方提出需求,設計院根據(jù)需求設計出圖紙,再由造價公司進行估價,然后公開招標,最后由建筑公司承擔建設。相對于軟件項目,建筑工程有以下特點:從需求到竣工,經(jīng)歷需求、設計、估價、建設等環(huán)節(jié),每個環(huán)節(jié)由不同專業(yè)的公司或人員完成。每個環(huán)節(jié)簽署不同的合同,每個環(huán)節(jié)對應不同的乙方。而軟件項目從需求到開發(fā)完成,基本上是簽署一個合同,只有一個乙方。整個過程可以認為是瀑布型的,需求和設計會在前期確定,后期基本上不會變動。而軟件項目就沒有這么理想了,需求和設計不斷在變。建筑工程只會采用最成熟的技術,可行性和設計方案要經(jīng)過反復論證,你看看港珠澳大橋就論證了好多年了。而軟件項目往往要采用不成熟的技術,邊設計邊嘗試。建筑工程的估算是在需求與設計都確定的基礎上估算的。而軟件項目不確定的東西太多,估算無法一次成型。軟件項目管理可能是最復雜的一種項目管理,因為軟件項目具備這樣的特點:需求、設計不明確。項目組需要在需求設計不明確的基礎上,承擔需求、設計、編碼、實施等全部工作。如果你是這樣項目的項目經(jīng)理,對你來說是多么大的挑戰(zhàn)啊!建筑行業(yè)發(fā)展了這么多年,整個建設工程的各個環(huán)節(jié)已經(jīng)有很多專業(yè)的公司,有很多設計院、造價公司、建筑公司等。而軟件行業(yè),幾乎很少見到專業(yè)的需求分析公司、軟件設計公司。這既是軟件行業(yè)的特點決定的,也是甲方習慣決定的。我們公司在一些項目嘗試和客戶簽署兩份合同,第一份合同只做需求的工作,而第二份合同則完成實現(xiàn)與編碼,但客戶往往不會接受。軟件項目管理難歸難,但我們還是要去面對的,我們應該如何應對軟件項目的估算與計劃呢?估算要估啥?很多人問如何才能做好估算?這個問題是問如何正確做事情的問題,而實際上要回答好這個問題,先要回答估算要估算什么內(nèi)容的問題,也就是什么是正確的事情問題。對于估算要區(qū)分以下幾種情況:甲方對項目的估算甲方想做某個系統(tǒng),會根據(jù)自己對系統(tǒng)的估計以及自己的預算估計出一個價錢。甲方往往不能準確對項目進行估算,項目的價錢往往是來自預算,而所有甲方都是想在有限的預算內(nèi)辦更多的事情。很多項目需要招標,其實重要目的就是希望找出性價比最高的軟件公司。乙方在投標階段對項目的估算作為軟件公司,要判斷該項目需要多少的成本,然后稍微'放大”成本作為投標價,這樣公司才能有利可圖。然則現(xiàn)實情況很殘酷:1) 需求大多數(shù)是不明確的,甚至甲方對項目的期望都沒有想清楚,這樣軟件公司無從估算。2) 很多招標其實甲方都“隱含”一個預算價,如果軟件公司的報價超出這個價錢,你就別想中標了。而這個預算價往往會小于軟件公司對項目的估算,讓你難以決定這項目做還是不做好!這個階段的估算是最難做的,除了考慮項目實際工作量,還要考慮項目是否要賺錢、客戶關系等因素。在我們公司,對于已經(jīng)產(chǎn)品化的項目,估價比較容易,這其實是一個積累的過程。而對于全新的以前沒有多少經(jīng)驗的項目,估價其實也是很難做得很好的,我們往往是由項目經(jīng)驗與技術經(jīng)驗都實力雄厚的總經(jīng)理來“拍腦袋”拍出來的。所謂“拍腦袋”,其實不代表亂猜,是以雄厚的經(jīng)驗和強大的知識為前提的。項目組開展項目時對項目的估算當我們要真刀真槍開干時,項目組需要對項目的實際工作量有充分的認識,并以此為基礎來做好項目工作。我們常常所說的項目估算問題,就是指這第三種情況,后文我們將重點講述這種情況。項目估算到底要估什么呢?項目的成本包括:人工費、差旅費、業(yè)務費用、招待費用、采購費用。人工費:包括項目組各人的薪金,以及公司運作分攤到項目組各人頭上的運作成本。公司運作成本包括非項目組人員的人工、場地設備費用、水電通訊費用、人員培訓招聘費用、人員閑適成本、研究失敗時的成本、商務活動的成本等。一般來說,項目組只需要估算出實際的項目工時就可以了,工時再乘以一個折合的人工成本單價就是項目的人工成本了。差旅費:項目組成員因項目出差的交通費、住宿費、通訊費、差旅補貼等。業(yè)務費用:公司領導、銷售人員與客戶進行商務談判、聯(lián)絡所花費的費用,例如送禮、回扣等的費用。這筆費用往往還很大呢,不過項目組一般不需要估算這部分費用。招待費用:項目組成員因工作需要,和客戶相關人員吃飯、娛樂的相關費用。例如:需求調(diào)研期間和客戶吃飯;項目實施階段因推動驗收和客戶一起加班,加班后請客戶吃飯。這筆費用一般不會很大,一頓飯一般就是幾十到一百多元,一個項目也不會請很多次吃飯。采購費用:采購項目所需的軟硬費用,如數(shù)據(jù)庫平臺、服務器等,如果項目部分內(nèi)容要外包出去,那還要包括外包的費用。有時候這筆費用會比較巨大,但這些費用都很容易估計。以上費用最難估計的就是人工費,人工費我們以工作量來考慮,下文開始我們重點講解項目工作量的估算。如何估計項目的工作量呢?簡單地說,我們需要將項目的所有工作進行分解,直到每個分解后的工作都能估計出具體的所需時間來。那項目的“所有工作”包含什么呢?回答這個問題其實就是回答“估算要估啥?”這個問題了。一般情況下,項目工作包括以下內(nèi)容:項目前期工作。包括商務談判、技術方案準備、投標準備、前期需求調(diào)研、前期技術研究等工作。當你接手項目的時候,這些工作往往已經(jīng)做了,你估算項目工作量時,不要忘記這些已經(jīng)花費的工作量。商務方面的工作。從客戶開始有意向做這個項目,一直到項目驗收、維護,整個過程中都會貫穿商務活動。前期的商務活動有商務談判、投標準備、合同簽署等,而簽訂合同后的商務活動有項目請款和催款、促進驗收等。某些商務活動屬于灰色地帶,如請客、送禮等,這些往往是花費巨大的。一般來說我們不需要估算灰色地帶的商務活動,灰色地帶的商務活動公司的高層會考慮的了,但我們需要對正常的商務活動進行估算。需求調(diào)研方面的工作。需求調(diào)研是一個“反復”的過程,一般來說能在前期確定80%已經(jīng)是很了不起的成績。需求調(diào)研的工作量一般由三部分組成:前期調(diào)研的工作量,后期需求細化的工作量,后期需求變更的工作量。前期調(diào)研的工作包括:項目組內(nèi)部討論、確認,與客戶討論、確認需求,編寫需求規(guī)格說明書及組織評審等工作。需求細化是指對之前已確定需求的進一步具體化、優(yōu)化或輕微調(diào)整,如:界面細節(jié)的確認、各業(yè)務概念的具體化等。需求細化一般是可預見可估計的。需求變更是指對之前已確認需求的“否定”,變更的原因主要有兩種情況:一是之前需求調(diào)研工作沒有能做好,理解錯客戶的真正意圖或者是遺漏重要的需求;二是客戶業(yè)務情況發(fā)生變化,與之前情況已經(jīng)不同。第一種情況應該盡量避免,而第二種情況一般是難以估計的。需求變更時需重新估算,和客戶簽訂需求變更協(xié)議。我們一般會充分估計前期需求調(diào)研工作量以及需求細化工作量,對于需求變更則暫不考慮,因為一旦變更我們會和客戶確認需求變更的費用。但有些項目有很特殊,項目報價中預留了少量的需求變更費用,這時估算中就需要適當考慮需求變更了。軟件設計方面的工作。不少項目為了“趕”進度,設計文檔很少,然則項目真的很簡單、不需要仔細考慮設計的情況是非常少的!軟件設計工作包括:1) 系統(tǒng)架構(gòu)設計。2) 技術方案選擇。3) 關鍵模塊設計。4) 數(shù)據(jù)庫設計。5) 用戶體驗設計。以上內(nèi)容具體項目可以有所取舍,但不可能全部都不用考慮。另外不要忘記了以下兩方面的工作:1) 各類設計工作產(chǎn)品的討論、確認、評審工作。2) 設計細化與優(yōu)化工作。設計是需要持續(xù)改進的,不要忘記這些工作。編碼方面的工作。要注意不要遺漏代碼返工、代碼評審、代碼調(diào)試、修復缺陷的工作量。需求、設計沒有做好,編碼質(zhì)量不過關,這些會嚴重增加代碼返工、代碼調(diào)試、修復缺陷的工作量。代碼首次完成的時間如果是100小時,那么后面代碼調(diào)試、修復缺陷等所需要的時間可能是200小時以上,往往我們估算時只考慮了前面的100小時。測試方面的工作。測試工作包括測試計劃、測試用例、測試文檔評審、測試環(huán)境準備、測試數(shù)據(jù)準備、執(zhí)行測試、回歸測試等內(nèi)容。軟件測試一般要經(jīng)歷多輪,我們估算往往只考慮了第一輪,就好象軟件只需要測試一回就不用再測試了。而測試環(huán)境準備、測試數(shù)據(jù)準備這些工作也很容易在估算時'忘記”了。實施方面的工作。實施工作包括實施計劃、實施方案的準備,編寫管理員手冊、用戶手冊,熟悉系統(tǒng),搭建實施環(huán)境并進行演練,在客戶現(xiàn)場安裝、部署、調(diào)試系統(tǒng),培訓客戶,協(xié)助系統(tǒng)上線,推動驗收等工作。我們公司通常的做法是:1) 系統(tǒng)在客戶處部署后,會推動客戶進行初步驗收,初驗標準是系統(tǒng)的所有功能跑就可以了。初驗成功,客戶需要支付相應的項目款項。2) 初驗后要協(xié)助客戶讓系統(tǒng)正式上線,讓客戶真正用上這套系統(tǒng),推動最終驗收。影響終驗主要有兩個因素,一個是客戶在使用系統(tǒng)過程中會提出各式各樣的問題,如果在需求范圍內(nèi)應該都予以滿足;而另外一個影響因素是客戶會因為各種各樣的原因推遲使用系統(tǒng),或者是使用不充分,讓項目終驗遙遙無期。估算時需要充分考慮這兩個影響因素。維護方面的工作。項目終驗后,一般都要提供半年到一年的維護服務,維護器后項目還會有最后一筆款項。維護期比較長,事情繁雜,一個不小心就很容易估算不足。維護的工作一般有:1) 用戶培訓;2) 協(xié)助客戶錄入資料;3) 修復被破壞的數(shù)據(jù)以及數(shù)據(jù)庫;4) 修改客戶或內(nèi)部發(fā)現(xiàn)的軟件缺陷;5) 代碼重構(gòu),提高部分程序的性能與可靠性;6) 修改一些界面文字或顯示風格;7) 回答客戶反饋的一些安裝與操作疑難問題;8) 提供合同中所要求的其它特殊軟件維護服務。在維護期,往往還需要發(fā)布數(shù)個小版本來解決客戶的問題。項目管理方面的工作。項目管理工作主要有編制項目計劃、持續(xù)更新項目計劃、跟蹤計劃執(zhí)行、各種工作協(xié)調(diào)、指導項目組成員完成工作等等。項目管理工作量一般占整個項目工作量的10-20%,項目不明確的東西越多、項目組成員水平越不足、項目組成員之間工作磨合度越不好,管理工作量就越大。項目管理在項目進行整個過程都需要持續(xù)進行,一般來說前期工作量會比較大,版本發(fā)布前后階段工作量也會比較大。項目管理前期工作抓得緊抓得好,會大大減輕后期的工作量。配置管理方面的工作。什么叫配置管理?簡單說就是對工作產(chǎn)品的管理,包括對各類文檔、各種記錄、代碼、數(shù)據(jù)庫、腳本、安裝程序、組件等等的管理。軟件生產(chǎn)過程的工作產(chǎn)品可分為兩類:中間產(chǎn)物和最終產(chǎn)物。中間產(chǎn)物有:1) 工程類:需求文檔、設計文檔、測試方案、代碼、數(shù)據(jù)庫腳本、數(shù)據(jù)庫、測試腳本等。2) 管理類:開發(fā)計劃、測試計劃、培訓計劃、采購計劃、實施計劃等。3) 記錄類:會議記錄、郵件、缺陷等。最終產(chǎn)物是指最終會交付給客戶的東西,一般有:組件、安裝程序、數(shù)據(jù)庫、用戶手冊、管理員手冊等。針對不同的工作產(chǎn)品應采取不同的針對性管理辦法,很多公司會制定單獨的配置管理計劃。質(zhì)量保證方面的工作。嚴格來說,質(zhì)量保證是靠項目組全體來保證的,這里所說的質(zhì)量保證是“狹義”的質(zhì)量保證,是指:要確保項目組按照既定的規(guī)定、過程、標準來工作,需按照既定的格式要求產(chǎn)出相應工作產(chǎn)品。對于以上十一點,實際項目估算中往往出現(xiàn)這樣的問題:忘記包含項目前期工作的工作量。沒有考慮商務、維護、配置管理、質(zhì)量保證方面的工作。需求調(diào)研、軟件設計、編碼、測試、實施方面的工作估計過少。項目管理方面的工作量估計不足。估算如何做出來?這里開始所說的估算,全部都是指項目組對項目的估算,這個估算的目的是用來指導項目的具體工作。有很多種估算辦法,大致可以分為兩類:先得到軟件規(guī)模,然后根據(jù)公司實際的生產(chǎn)率由軟件規(guī)模導出工作量。直接得到工作量。第一類的常見方法有:功能點法、代碼行法,第二類的常見方法有Delphi估算法、微軟的由底而上估算法。什么是軟件規(guī)模?我們先看看一個搬磚頭的估算。假設有1000塊磚頭,它們的大小和重量一樣,每名工人每天能搬100塊磚頭,于是我們可以估算到需要10人日來搬完。10人日的意思是1名工人需要10天完成,而10名工人只需要1天就搞定了。這個1000塊代表了工作的規(guī)模,而生產(chǎn)率就是100塊/日,這樣就可以推算出工作量為10人日。建筑工程可以得到土石方量、混凝土量、鋼筋量等代表工作規(guī)模的數(shù)據(jù),這樣就比較容易推算出完成這些工作需要的工作量。而軟件工程估算也希望能做到類似的效果,但用什么來代表軟件項目的工作規(guī)模呢?功能點和代碼行是常見的兩種軟件規(guī)模表示方式。軟件規(guī)模是與軟件具體生產(chǎn)技術、項目管理辦法、項目組人員水平等無關的東西,軟件規(guī)模只和軟件項目本身的性質(zhì)相關,如果我們能找到合適的統(tǒng)一的標準來度量每個項目的規(guī)模,這樣每個軟件項目之間就可以進行橫向比較了。功能點法和代碼行法都希望能達致這樣的效果。功能點法的基本思路是將復雜的軟件分解為一個一個獨立的粒度一致的功能點,附加一些調(diào)整系數(shù),得到軟件規(guī)模。我們的項目大部分是數(shù)據(jù)庫四輪馬車的操作(查詢、增加、修改、刪除),功能點法從比較高的層次對這些工作進行抽象,有一套嚴密的規(guī)則可以讓你將需求分解成一個一個的功能點。代碼行法思路也類似,不過分解的結(jié)果是代碼行而已。但一般來說代碼行與軟件的實現(xiàn)技術相關度太大,大家會更加偏愛功能點法。功能點法和代碼行法有比較長的歷史,也有很多詳細資料,大家可以去查閱一下。這方法理論上很理想,但實踐效果很差,我還沒有見到一家能成熟應用并且取得比較好效果的公司。功能點法和代碼行法有這樣的一些難以解決的問題:只適用于數(shù)據(jù)庫四輪馬車的操作的項目,高技術含量、創(chuàng)造性高的軟件不適用,如游戲軟件、計算機負責計算與決策軟件等。我們絕大部分項目是需求不明確、設計不明確,并且工期很趕的,這兩個方法都無法適應這樣的現(xiàn)實條件。需求不明確基本上無法得到軟件規(guī)模,建筑工程為什么能做到,是因為需求和設計都十分明確了。兩個方法的規(guī)則都很詳細,要花大量時間學習和實戰(zhàn)才能掌握。由工作規(guī)模導出工作量這樣的思考方式,難以適用于軟件項目。項目組還是習慣列出具體的任務,逐條任務估計時間,而且只有這樣的工作方式才能讓項目組感覺更加踏實。Dephi估算法是比較符合大家實際工作習慣,也是比較容易掌握的估算辦法。Delphi法的大致方法如下:找?guī)酌Y深專家,一起對項目進行WBS,把項目的工作分解為十幾條最多二三十條的工作項。全部專家各自估計每條工作項的工作量,并向其他專家闡述自己的理由。第一次各專家估出來的結(jié)果可能差異比較大,每位專家聽取別人的意見后,重新估算。按照上述辦法,各專家反復估算幾次,一般次數(shù)就是2-4次,各專家估計的工作量會越來越趨近,這個時候取全部專家的平均值。普遍認為各專家的經(jīng)驗與知識水平會嚴重影響結(jié)果的準確性,而我的實踐經(jīng)驗是:應該讓項目組每個人自己來估算,也就是讓大家來當專家,在這個基礎上可以再增加一兩名來自項目組外部的專家。有時候覺得估算這個問題搞得太復雜了,各式各樣的方法是不是太夸張了?其實最簡單的方法就是讓負責該項工作的人自己來估計工作量,微軟的由底而上的估算方法就是這樣做的,可謂返璞歸真??!微軟由底而上的估算方法大致是這樣的:對項目各項工作進行分解后(即俗稱的wbs:workbreakdownstructure,!作分解結(jié)構(gòu)),每個任務落實負責人,由負責人對自己的任務進行估計。這個辦法有以下好處:最終該任務是由這個人來完成的,他估計多少時間才能做完,這個時間才是最接近實際的。負責該任務的人進行估算的時候,肯定需要認真思考這個任務的風險,需要做哪些具體的工作,這樣更容易在未開始工作之前就發(fā)現(xiàn)更多的潛在問題。相反如果由項目經(jīng)理來分配時間,這個人就可能不會去思考這個任務了。做這個任務的人會有被重視和尊重的感覺,他會很重視自己承諾的完成時間,并且想法設法按時間完成。這樣會減少很多項目管理時間,因為每個任務負責人都會主動地跟蹤好自己的工作。其實微軟這個方法根本就沒有什么特別,所有正常人都可以想到這個方法,但仍然有很多人去追求那些不太靠譜的估算方法。這個方法還是有這樣的一些問題的:有人會估算偏小,比方他說需要5天,但往往10天還完不成。有人估算過于保守。項目的進度要求就是很緊,基本上你必須在指定時間內(nèi)完成,估算顯得毫無價值。第一個問題是比較常見的,但我們要這樣想:估不準也比不估算好,估算偏差哪怕超過100%,也比不估算好,至少有個譜。大家是會進步的,估不準往往是對任務和自己能力認識不到位,要讓大家不害怕估算,只要敢于估算,問題才會暴露出來,才能持續(xù)進步。第二個問題分兩種情況,有些人是確實是過分保守的對自己信心不太足,項目經(jīng)理可以多多來指導他的工作,看看他具體的進展,讓他更加充分地了解任務,更加充分了解自己的能力,增強他的信心,這樣他就能持續(xù)進步了。而另外一種情況就比較惡劣,少數(shù)人會故意增大時間,這樣他平時工作不必全力以赴,可以比較悠閑,甚至可以利用工作時間干私事。如果發(fā)現(xiàn)這樣的情況,就應該嚴肅處理了,不要做爛好人,這樣的人在團隊中存在是對團隊的極大傷害。第三個問題往往是各項目經(jīng)理心中的痛楚,他們會覺得:實在無奈??!做項目就是在有限時間有限資源內(nèi)做不可能完成的任務,在這樣的情況下,你就不要跟我扯估算了!我們的項目大部分情況都是非常大壓力的,應對這樣大的壓力越需要冷靜。實際上大部分項目盡管是有壓力,但只要發(fā)揮團隊的聰明才智,還是可以高效地做好工作的,不需要加班或者少加班。本文稍后會介紹這個問題的應對辦法。介紹了這么多種估算方法,每種都有很多問題,那到底怎樣才能做好項目估算呢?軟件項目的特點就是項目簽訂時,價錢是死的,工期是死的,而需求和設計是不明確的。我的經(jīng)驗告訴我,功能點法、代碼行法這些方法基本上是不靠譜的,我在實際項目中會綜合使用Dephi法和由底而上的估算方法,并予以改良,下面介紹一下我的一些心得體會。項目估算與其說是估出來,還不如說是做出來的。假設某項目是這樣的情況:1) 合同簽署的金額是100萬,工期是3個月。2) 需求只是大致寫了,并不明確。3) 老板要賺50萬,給你的預算只有50萬。我們很多項目都是這樣的情況,不是等你估算出比較靠譜的數(shù)字,然后才去報價簽合同的,我們經(jīng)常要在老板指定的預算下完成項目。你現(xiàn)在要負責這個項目,你會如何做估算呢?你需要做好兩個事情,才能保證項目實際成本控制在預算內(nèi)。第一個事情,控制好需求。需求不明確,這既是不利因素也是有利因素,應盡量往有利的方向控制。不明確的好處就是你有控制需求的空間,抓住客戶的關鍵需求,簡化不必要的花銷的需求,能極大地降低項目工作量。第二個事情:想盡辦法降低開發(fā)工作量。不要因為進度緊就不認真思考軟件的設計,應盡量采用簡單的成熟的設計方案,簡化工作。估算應該持續(xù)進行,持續(xù)細化。項目初期很難對項目做完整估算,但能估計的部分應先估計出來,并且針對不明確的部分安排計劃去搞清楚。估算是項目各種工作估算的總和。估算并不是只是得到一個項目估算的總體數(shù)字,項目的估算總數(shù)其實是由項目各種工作的估算組成的。前文介紹了項目的各種工作,每一種工作都需要認真估算。如果估算發(fā)生偏差,要能定位到具體是哪部分的估算出問題了,否則估算沒有指導項目工作的價值。功能點法、代碼行法的估算辦法,只能得到一個項目估算的總數(shù),而不能定位到具體的哪一部分工作,這樣得到的估算結(jié)果難以用來指導項目工作。估算依賴項目組的整體實力。如果你沒有軟件開發(fā)相關經(jīng)驗,只懂理論上的估算,你是不可能做好估算工作的。項目組由項目管理、軟件設計、編碼、測試、實施等各類專業(yè)人才組成,每個人在自己方面都是專家,每個人都是整個項目組中最有資格對自己專業(yè)方面的工作進行估算。前文列出了的項目各方面的工作,應該由相應的項目成員為主進行估算。項目組應該不斷學習、總結(jié)、進步,提高整體水平。需求不明確、設計不確定這是項目的特點,我們需要不斷地學習來提高水平,將這些不明確的因素逐步明確。沒有什么妙方能解決這些不明確的因素,靠的還是我們的知識和能力。項目組每個人都應該通過持續(xù)估算來發(fā)現(xiàn)自己的不足并提高水平。公司應該定期組織項目資深人士制定估算指南并持續(xù)更新。我們公司有一份估算模板,里面匯集了以前的估算經(jīng)驗,列出了所有需要考慮的估算內(nèi)容以及詳細的說明。我們以前沒有估算模板時,估算偏差會達到50%以上,總結(jié)經(jīng)驗發(fā)現(xiàn)偏差的主要原因是估漏!使用估算模板會幫助我們發(fā)現(xiàn)遺漏,后來我們的估算偏差基本可以控制在20%以內(nèi)。前文的“估算要估啥”小節(jié),我列出了項目通常要考慮的各種工作,也列出了容易估漏和估計不足的地方,大家可在此基礎上根據(jù)自己公司實際情況,修改和擴充這些內(nèi)容,寫出自己公司的估算模板或估算指南。先得到項目規(guī)模,再由規(guī)模導出工作量,這是一個很美好的想法,問題就是和我們的實際情況相去甚遠了。將工作分解,直到分解到可以估計工作量的程度,這個可能是最土最有效的方法了。但你可能會問,這樣的估算方法,項目之間就無法橫向比較了?項目估算第一目標是用來指導項目工作,如果這個目標都達不到,那么就不需要考慮項目之間的橫向比較了。另外我要反問:為什么非要用這樣的方式來作項目之間的橫向比較?有什么好處?國外優(yōu)秀的軟件開發(fā)工作室就不會做這樣無聊的事情,軟件開發(fā)可能是人類最厲害的智力活動,你覺得一定能量化度量嗎?要從本質(zhì)上提升估算水平,你不太可能用幾天時間去突擊學習某種估算辦法就能勝任項目實際的估算工作。提高估算能力靠你長期的積累,你的實力、你的項目團隊的綜合實力,還有你們公司的綜合實力,決定了估算的水平!估算是為項目服務的,后文你會看到如何利用估算來管理項目,又如何因應項目實際情況來更新估算。計劃有什么內(nèi)容?關于項目計劃,我們要先討論什么是正確的事情,然后再討論如何做正確的事情,我們先來看看項目計劃應該有什么內(nèi)容?讓大家做項目計劃,很多人以為用Project做一份開發(fā)進度計劃就完事了。而項目的開發(fā)工作只是占了項目工作的其中一部分而已,跟項目所有相關的工作,我們都需要計劃。諸如開發(fā)計劃、測試計劃、培訓計劃、溝通計劃、采購計劃等等,這些計劃的集合,我們稱之為項目計劃。項目計劃應該包含以下內(nèi)容:項目背景、目標、概述等。項目需要提交的工作產(chǎn)品,包括內(nèi)部工作產(chǎn)品和最終工作產(chǎn)品。風險分析及應對措施。項目估算。項目在成本、進度、質(zhì)量方面的管理目標。項目人員職責。對項目各項工作的安排,包括但不限于前文介紹的11種工作,如下:1) 項目前期工作2) 商務方面的工作3) 需求調(diào)研方面的工作4) 軟件設計方面的工作5) 編碼方面的工作6) 測試方面的工作7) 實施方面的工作8) 維護方面的工作9) 項目管理方面的工作10) 配置管理方面的工作11) 質(zhì)量保證方面的工作需客戶或第三方協(xié)調(diào)的工作計劃。采購計劃。項目所需的各種硬件資源,包括開發(fā)環(huán)境、運行環(huán)境、測試環(huán)境等。一般來說項目計劃有一個主計劃,多個子計劃。主計劃總體描述項目的背景、管理目標、任務概述等總體信息,而子計劃則有測試計劃、實施計劃、培訓計劃、配置管理計劃等。下圖是主計劃目錄示例:目錄TOC\o"1-5"\h\z引言 3,背景 3J定義 3+-113蚤考資料 3」項目概述 3+-1條件與限制 3J工作產(chǎn)品 31月底務 4風險 4估算 4項目管理目標 4哽目成本管理目標 4項目ifi度管理目標 W5-3. 客戶滿意度目標 5.4 軟件質(zhì)量目標 5'5.5. 費用控制目標 6+-1開發(fā)計劃 6.&.L, 任務概述 驢)5度計劃 6+-1項目培訓計劃 缺6一4. 采購計劃 6卜&5一 版本發(fā)布計劃 6己支持條件 7,7.1, 開發(fā)和運行環(huán)境 7」-J*“卜 ---—-—-—-——————————————_________________7473.需用戶單位承擔的工作 7J需外單位提供的條件 "其他關鍵貧源 7」S.裁敢 飛'9-版本[腰訂而史記錄 7J下面是進度計劃示例:

曲ILonlim+Rel?asel.2.021—0-022-攻目管查對編寫進度計勤24跟蹤及指導項目工作25+等日站立例會37-需京38編寫任蓉祺板需求39編寫報表及節(jié)暇日設置的需求40編寫各狀態(tài)下任務處理方式的需求41整合需求42-設計43編寫任客模相模塊設計44編寫報表及節(jié)暇日設置的模塊設計45-開發(fā)46十新功能開發(fā)53+修改缺陷57+改進與憂化&5-試66編寫測試用例67提前訓J試68制作數(shù)據(jù)庫升蟻腳本69正式測試70-發(fā)布71發(fā)布EC172編寫版本發(fā)布說明T32J發(fā)布E2.口74-實75修改用F文檔76部署實施該進度計劃按版本來組織任務,而每個版本則按照項目管理、需求、設計、開發(fā)、測試、發(fā)布、實施來組織任務。也會有些公司會將所有計劃集成一個大計劃,計劃的組織和表達方式并沒有固定方式,上述示例圖也只是僅供參考。上面講了很多項目計劃的內(nèi)容,其實我們只是需要想清楚為什么要做計劃,你就會知道項目計劃應該有什么內(nèi)容。項目計劃的幾個重要目的:明確項目人員、各人職責。(當然這可能會在立項通知書中明確。)明確完成項目所需要的各種資源。確定項目在成本、進度、質(zhì)量方面的管理目標。明確項目的各種工作產(chǎn)品。落實各項工作安排,保證項目成功。計劃是如何做出來的?、要站在戰(zhàn)略的高度。有時候我會問項目經(jīng)理這樣的問題:項目預算是多少?(注意前文提到的預算與估算的差別哦,預算是指公司打算花多少錢做這個項目。)合同要求在什么時候驗收?驗收一次進行還是分初驗、終驗?有些項目經(jīng)理答不出了,他們沒有去關注合同中的要點,也沒有向高層取得項目的戰(zhàn)略指示。一般情況下,在項目初期,你應該搞清楚這些戰(zhàn)略層面的內(nèi)容:合同價錢是多少,公司打算賺多少錢?公司為什么要做這個項目?想賺錢?想維持客戶關系?想積累業(yè)務和技術?本項目是公司戰(zhàn)略的其中一步?項目的工期要求。項目的驗收辦法、驗收標準。項目是如何收款的,客戶每次的付款條件是什么?你可以通過看合同,向公司高層請示,了解到這些關鍵信息。當然很多公司合同是保密的,你可能無法直接看到合同,但你可以直接問高層領導嘛,盡量獲取上述關鍵信息。做項目就像打仗,秦國名將白起沒有一次敗仗,主要是因為他每次打仗之前,都會處在戰(zhàn)略高度來審視國與國之間的大勢。你要做好項目,先要把握項目的大勢!二、 明確計劃的“輸入”。要做好計劃,你還需要了解清楚以下內(nèi)容:系統(tǒng)的需求。通常需求是不明確的,能明確多少算多少,同時你需要有計劃地去搞清楚。系統(tǒng)的設計。通常設計也是不明確的,你需要安排很多前期技術研究。項目組當前的能力情況。為成功完成項目,項目組還需提升哪些知識和技能。以上這些內(nèi)容,是項目計劃的“輸入”,良好的輸入是優(yōu)質(zhì)計劃的基本保證。三、 用估算來控制計劃,由計劃來調(diào)整估算。估算如果做得好,其實計劃就完成大部分了,你需要利用估算來指導計劃。為了說明'估算指導計劃”,下面我會虛擬一個例子。某項目估計完工需要1000人日的工作量,其估算明細如下:項目管理150人日。需求150人日。設計150人日。編碼250人日測試100人日。實施200人日。根據(jù)估算,你安排了詳細的進度計劃,進度計劃中的各任務可以分為六類:項目管理、需求、設計、編碼、測試、實施。請注意每一類工作量的總和,不能超過對應的估算,你需要用各子估算來控制這六類子任務。不少項目在安排具體進度計劃時,忘記做這個檢查,有時候進度計劃的總工時沒有超出預算,但可能編碼方面的任務已經(jīng)超出了編碼的預算了。在具體計劃時,往往會發(fā)現(xiàn)估算時遺漏考慮的內(nèi)容,這時很有可能實際計劃的總工時會超出估算,或者是某類別的工時超出相應的子估算。這是很正常的事情,項目組對項目的認識是逐步深入的,不太可能在估算時就100%考慮周到。遇到這樣的情況,我們通常這樣處理:如果僅是某類別工時超出相應的子估算,如果能從別的子估算挪一點過來'補數(shù)”,而總估算不受影響,則不需要申請估算調(diào)整;但如果總估算受到影響,則需要申請變更估算。前文講述估算時提到,會因為需求不能全部明確、設計也不能全部明確,估算往往不能一次完成,這時只需要估算能估算的部分就可以了。但我們需要隨著項目的開展,認識的加深,持續(xù)更新估算。估算與計劃的關系是:估算指導計劃,計劃反過來促進估算更新。四、制定可執(zhí)行可檢查的進度計劃。具體工作任務的制定是很講技巧的,如何做到'可執(zhí)行可檢查”是關鍵,下面是制定進度計劃的一些技巧:每個任務的時長不要超過5天。我們公司的項目,任務時長往往是在兩三天內(nèi)。任務只有完成與未完成兩種狀態(tài)。所謂任務完成90%之類的說法是不靠譜,任務應該足夠細分,不要安排周期長的任務,這樣能更好控制項目進展。每個任務都有可供檢查的工作產(chǎn)物。不要籠統(tǒng)安排“研究什么什么技術點”之類的任務,必須明確工作產(chǎn)物,如:研究某某技術點,編寫研究報告,提交演示程序。而任務完成標準就是:這些工作產(chǎn)物能達到期望的要求。一個任務一個人負責。一般不要安排類似“小甲與小乙共同完成某設計文檔”之類的工作,多人同時負責一個事情,效率會很低,效果也不太好。盡管實際工作中有可能需要多人同時做一個事情,你可以:1) 再次將任務分解,落實到具體的人頭上,如上述任務可以分解為兩個任務:小甲完成設計文檔的章節(jié)1、2、3,小乙完成章節(jié)4、5、6。2) 如果任務實在不好再分解,就只安排一個人去做。在我們公司,一般只有評審任務是多人參與的,別的任務都會落實到具體的人頭上。五、 細化近期計劃,定下遠期計劃大節(jié)點。我曾經(jīng)負責一個房地產(chǎn)公司的成本管理系統(tǒng),當時需求還沒有全部明確、技術也很不成熟,就被要求做出該項目的全部詳細計劃。我當時很郁悶,一個月后某一天誰干什么的事情也要計劃出來嗎?我只能明確近期一兩周的具體工作,而遠期的工作我只能定出大概,以后的事情可變因素太多,現(xiàn)在寫出所謂具體工作,其實是毫無價值的,浪費時間。近期兩周內(nèi)的工作能明確的工作,必須按照上述第四點的要求制定詳細的明確的可執(zhí)行的可檢查的任務,而對于將來的工作,則需要定出關鍵節(jié)點,如什么時候發(fā)布什么版本,什么時候驗收。六、 讓項目組各成員詳細計劃自己的工作。在項目經(jīng)理主持下,項目組全體共同來制定進度計劃框架,明確任務的先后關系。而對于每個人的具體任務,則可以在項目經(jīng)理的指導下,由每個人自己來確定。項目組由項目管理、需求、設計、編碼、測試、實施等各專業(yè)人才組成,每個人承擔起自己專業(yè)方面的管理工作,項目管理其實是項目組成員每個人的事情,不是只由項目經(jīng)理一個人來負責。七、 持續(xù)更新計劃。計劃不是死的,是活的!項目計劃不是一次成型就固定不變的,項目組需要持續(xù)更新計劃細化計劃,要隨時保證近期的任務都已經(jīng)明確,而遠期的任務如果能明確也應當盡量明確。任何項目組成員都可以發(fā)起計劃更新,項目經(jīng)理要推動大家管理好自己工作,讓大家主動更新計劃。這里要談談計劃變更問題,談到計劃變更很多人會“聞虎色變”,我們先要看看看什么叫“計劃變更”?“計劃變更”要與“計劃調(diào)整和細化”區(qū)別開來,調(diào)整和細化是指根據(jù)實際情況,不斷的適時地去修改計劃。任務微調(diào)是很經(jīng)常和很正常的時間,某某任務稍微延長一天,某某任務比計劃提早一天完成,某項目組成員請假等影響因素,都需要我們?nèi)フ{(diào)整計劃。與此同時,我們應當不斷去細化中遠期的任務,至少要一直保證近期的任務都是明細化的。而計劃變更是指,項目關鍵節(jié)點受到影響的重大變化,關鍵節(jié)點一般有:需求規(guī)格說明書通過評審的時間點、版本發(fā)布時間點、驗收時間點等。這些關鍵節(jié)點的變化,會影響合同條款的履行,會影響公司的戰(zhàn)略規(guī)劃。通常是因為內(nèi)因或外因?qū)е掠媱澴兏?,?nèi)因一般有:遺漏重要需求、軟件設計出現(xiàn)重大失誤、代碼質(zhì)量不過關;而外因一般有:客戶的需求變更,客戶未能做好項目上線準備,第三方未能及時完成相關工作(如:硬件提供商未能及時發(fā)貨)。在我們公司,計劃調(diào)整和細化只需要項目組內(nèi)達成一致便可,而計劃變更則需要報高層審批。如何跟蹤計劃?計劃做出來不是用來看的,而是要執(zhí)行計劃!跟蹤計劃執(zhí)行的難度和工作量比起做計劃要高出好多倍。計劃跟蹤并不是對照進度計劃,按時間檢查每個人的任務完成情況這么簡單,下面介紹一些計劃跟蹤的關鍵要點。建立便捷的項目組內(nèi)溝通機制。很多人強調(diào)加強溝通,雖然大家的意識算是加強了,但還是收不到理想效果。程序員不善溝通的特點(理科生往往是不善溝通),不是一下子能改變的。下面一些最佳實踐供大家參考:1) 所有人的工作產(chǎn)品必須share!我們要求大家的文檔要提交到項目網(wǎng)站,而代碼滿足提交條件的,每天都需要提交。工作產(chǎn)品不能幾天都只存在自己電腦上,哪天你不上班了,大家就無法接手。2) 每天站立會議??陬^溝通是最有效的溝通辦法,我在很多項目中實施了每天站立會議的做法,要求大家簡要地說明工作情況及遇到的問題,需要大家提供什么支援等。每次會議,如果有決議和代辦事項,我都會安排記錄下來,并將會議記錄公布在項目網(wǎng)站上。3) 有問題即反饋!很多項目組成員喜歡遇到問題就悶頭干活,不好意思問,也好像是怕被主管認為能力低。遇到問題有可能是任務本身有問題,也有可能是你的認識不到位,某些知識不具備等導致的。實際工作中遇到問題是很正常的事情,如果沒有人提出問題,這反而是項目的最大問題。我強調(diào)任何人都可以提問題和大家討論,任何人都可以發(fā)起項目會議討論問題。問題如果不在產(chǎn)生時消除,將來必定會因此徒增很多項目工作量。建立項目組成員的自信。我?guī)ьI過很多項目團隊,很多項目組成員是新手,甚至是應屆生,項目團隊中新手太多是很大的挑戰(zhàn)!在中國基本上不可能每個項目團隊一開始就是最強陣容的,大部分項目團隊是新老結(jié)合,中高低搭配的。我強調(diào)每個人的重要性,對于新手要給出更多的機會,更多的指導,更多的鼓勵!犯錯不要緊,犯錯多也不要緊,只要錯誤不是重復的,這就是好事!只要去做事情,就有機會犯錯,只要做未做過的事情,犯錯機會也會更大一點,關鍵是總結(jié)和進步!質(zhì)量投資,減少返工。項目時間緊,大家就會一頭扎到編碼中,想盡快弄出個東西來?!爸\定而后動”“磨刀不負砍柴工”等大道理大家都懂,但事到臨頭還是明知故犯,結(jié)果往往是工作質(zhì)量低、返工一大堆!要培養(yǎng)大家零缺陷意義,零缺陷意識包括零缺陷文檔、零缺陷代碼、零缺陷發(fā)布。我經(jīng)常和大家強調(diào),做一個事情只有兩種選擇,一種就是不做,一種就是認真做好!不要搞什么60分萬歲,不要應付完成,任何帶有缺陷的工作,會在將來帶來無窮無盡的'后患”。一步一個腳印,欲速則不達。除了向大家灌輸這種思想并要求大家這樣去做,作為項目經(jīng)理還需要盡早檢查和指導大家的工作。比方說:我安排小甲完成某模塊的設計文檔,我不會等文檔完成才去看,我會先要求小甲思考后找我口頭說明他的思路,大致沒有問題我就讓他動手寫文檔,而且我要求項目組所有人寫文檔都必需在線完成,我會隨時檢查文檔的質(zhì)量。(說明:我們用SharePoint來管理項目文檔,Word、Excel等文檔都可以在項目網(wǎng)站上在線編輯。)絕大部分項目是分秒必爭的,保證大家用正確的方法做正確的事情,才能最大限度地減少返工。不過上面提到的檢查辦法確實有點夸張,我一般對于新手才會這樣檢查,當新手已經(jīng)成長起來,你對他有信心,就不需要檢查得這么密了。不斷思考減少工作量的辦法

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論