團(tuán)隊的軟件項目管理和開發(fā)流程

-.z團(tuán)隊的軟件工程管理和開發(fā)流程1目的用于指導(dǎo)公司的技術(shù)中心軟件開發(fā)工作定義了各部門與技術(shù)部的協(xié)作接口和流程定義了工程開發(fā)流程和管理方法定義了任務(wù)開發(fā)流程和管理方法2說明2.1

*圍本文檔只適用于技術(shù)中心針對****及其相關(guān)的一般性開發(fā)工作。包括：維護(hù)性開發(fā)工程開發(fā)本文檔不適用于運維護(hù)性的系統(tǒng)維護(hù)工作。不涉及：的網(wǎng)絡(luò)平安、FTP權(quán)限等數(shù)據(jù)庫的平安、備份等系統(tǒng)環(huán)境等凡運維性的系統(tǒng)維護(hù)工作請另參見?運維管理規(guī)*?文檔。2.2技術(shù)中心組織架構(gòu)技術(shù)中心組織架構(gòu)圖技術(shù)中心組織架構(gòu)說明目前技術(shù)中心從處理的工作性質(zhì)分為三大局部：運維、開發(fā)和測試。根據(jù)需求工作量的大和小，其中開發(fā)的工作又細(xì)分為兩類：維護(hù)開發(fā)工程開發(fā)根據(jù)具體的開發(fā)工作內(nèi)容不同，又可將維護(hù)開發(fā)組和工程開發(fā)組的人員細(xì)分前臺開發(fā)人員和后臺開發(fā)人員。各小組的職責(zé)*圍運維組：處理系統(tǒng)維護(hù)性的工作，包括系統(tǒng)安裝維護(hù)、網(wǎng)絡(luò)平安、數(shù)據(jù)庫調(diào)優(yōu)備份等。關(guān)于運維的工作本文檔不再詳細(xì)說明，請參見?運維管理規(guī)*?文檔維護(hù)開發(fā)組：處理的日常小問題的修改、新需求的增加〔但工作量不大〕等維護(hù)性的開發(fā)。工程開發(fā)組：處理新工程的開發(fā)。測試組：負(fù)責(zé)對維護(hù)開發(fā)和工程開發(fā)進(jìn)展測試。前臺開發(fā)人員：負(fù)責(zé)對前臺的功能進(jìn)展開發(fā)。后臺開發(fā)人員：負(fù)責(zé)對后臺的用戶管理、權(quán)限管理、開發(fā)、出票等后臺的功能進(jìn)展開發(fā)。由于人力資源的限制，目前沒有專職的維護(hù)開發(fā)和工程開發(fā)，在沒有新工程時，所有人員都可安排參與維護(hù)開發(fā)的工作。當(dāng)有新工程時再組建工程組。但有高優(yōu)先級的維護(hù)工作要處理而又人手不夠的情況下，工程組的人員必須優(yōu)先處理維護(hù)緊急事件。2.3工程與任務(wù)的定義什么是開發(fā)類工程〔工程〕滿足以下任意一條件進(jìn)展開發(fā)的工程均為開發(fā)類工程：以前從未開發(fā)過的系統(tǒng)；不存在或根本不存在可復(fù)用的技術(shù)、模塊，或業(yè)務(wù)邏輯、體系構(gòu)造等或者在原產(chǎn)品上進(jìn)展大的構(gòu)造性調(diào)整。在公司已有的成熟產(chǎn)品或可復(fù)用模塊或技術(shù)根底上，根據(jù)業(yè)務(wù)需要和客戶需求，新增獨立業(yè)務(wù)模塊，且開發(fā)工作量超過1人月，如果是2至3人開發(fā)工作但超過2星期根據(jù)情況也可劃為開發(fā)類工程。新彩種、新玩法、新產(chǎn)品的開發(fā)等都可以劃為開發(fā)類工程?！泊艘鬀]有硬性要求，可以視情況而定。〕例如：二期工程、增加福彩七樂彩、增加快樂十分游戲、足彩單場工程、無線工程、安微客服工程等。什么是維護(hù)類開發(fā)〔任務(wù)〕在現(xiàn)已運行的根底上，根據(jù)運營的需要或者市場規(guī)劃的需要，提供補(bǔ)丁、實現(xiàn)新的需求工作量通過技術(shù)部經(jīng)理評估小于1人月但超過1個小時的。例如：頁面的調(diào)整、促銷專題頁面，日常運營中發(fā)現(xiàn)的問題等。3.需求管理3.1需求來源需求來源類型：技術(shù)部提出運營部〔包括客服組〕提出市場籌劃部提出技術(shù)部需求提出人：技術(shù)部經(jīng)理或技術(shù)骨干提出原因：1.隨著新加游戲、玩法，注冊用戶增多等，對的可擴(kuò)展性、穩(wěn)定性、平安性等提出了更高的要求，在時間允許的情況下，技術(shù)部有對進(jìn)展技術(shù)優(yōu)化的需求。此種情況的執(zhí)行和跟蹤轉(zhuǎn)根據(jù)工作量的大和小轉(zhuǎn)工程管理或任務(wù)管理。2.在用戶還未發(fā)現(xiàn)的問題，但技術(shù)部清楚存在的缺陷，需要對進(jìn)展打補(bǔ)丁升級。此種情況的執(zhí)行和跟蹤轉(zhuǎn)任務(wù)管理。提交文檔：如果是任務(wù)，填寫?需求變更申請單〔技術(shù)部〕?；如果是工程，編寫?需求說明書?和給出?工程方案〔初步〕?運營部需求提出人：運營部的所有人員〔包括客服、編輯等〕提出原因：在日常運營過程中會發(fā)現(xiàn)一些問題和提一些完善的建議。發(fā)布后，面對廣闊用戶，用戶在使用過程中會產(chǎn)生大量的問題和意見。這些問題和意見由客服組統(tǒng)一收集，然后反應(yīng)給運營負(fù)責(zé)人。根據(jù)工作量的大和小轉(zhuǎn)工程管理或任務(wù)管理。提交文檔：如果是任務(wù)，填寫?需求申請單〔運營部〕?；如果是工程，編寫?需求說明書?和給出?工程方案〔初步〕?注：客服在接收客戶的問題和建議后，如果是影響交易的，可以直接向技術(shù)部經(jīng)理反應(yīng)，否則把問題反應(yīng)給運營負(fù)責(zé)人，由運營負(fù)責(zé)人按正常流程處理。市場籌劃部需求提出人：籌劃部主管提出原因：總結(jié)、提煉客戶原始需求，推出升級版本、根據(jù)市場需要推出新產(chǎn)品、活動促銷等。根據(jù)工作量的大和小轉(zhuǎn)工程管理或任務(wù)管理。一般工作量比擬大，轉(zhuǎn)工程管理。提交文檔：如果是任務(wù)，填寫?需求申請單〔籌劃部〕?；如果是工程，編寫?需求說明書?和給出?工程方案〔初步〕?其它上述只列出了三個部門的需求來源，但公司歡送任何人向我們公司和產(chǎn)品等提出問題和建議?？梢酝ㄟ^口頭或書面的形式向運營主管或籌劃主管先提，運營主管或籌劃主管再整理需求提交給需求管理負(fù)責(zé)人安排處理。3.2需求的接收和審批技術(shù)中心指定一名專職需求管理負(fù)責(zé)人，專門接收來自各部門的需求，協(xié)助技術(shù)部經(jīng)理作進(jìn)度的安排等。需求的審批分為兩種情況：技術(shù)部經(jīng)理審批：一般情況由技術(shù)經(jīng)理直接審批審批小組審批：技術(shù)部經(jīng)理不確定的情況下由審批小組進(jìn)展審批。需求響應(yīng)時間：接收需求后，必須在半天以內(nèi)向需求申請人反應(yīng)對需求的處理結(jié)果。包括處理意見，處理人，方案完成時間等信息。需求管理負(fù)責(zé)人職責(zé)：專門分類匯總、整理提交的需求。初步劃分是任務(wù)還是工程。整理后交給技術(shù)部經(jīng)理進(jìn)展劃分整理后如果是工程交給審批小組進(jìn)展評估和審批。審批小組組成：根據(jù)需求的內(nèi)容臨時組建審批小組。成員一般包括與該需求有關(guān)的各部門主管、業(yè)務(wù)專家、技術(shù)主干等。審批小組職責(zé)：批準(zhǔn)立項是否成立根據(jù)?需求優(yōu)先級規(guī)則表?劃分需求的優(yōu)先級確定是工程還是任務(wù)指定解決的部門或個人。安排解決的時間。3.3需求申請流程需求的申請流程分為任務(wù)需求申請和工程需求申請。任務(wù)需求申請任務(wù)需求申請流程說明：1.需求申請人填寫?需求申請跟蹤單?，并確定緊急程度；2.申請部門的主管或經(jīng)理審批需求，通過后將需求轉(zhuǎn)給技術(shù)中心需求管理負(fù)責(zé)人，不通過則繼續(xù)修改或取消；3.1需求管理負(fù)責(zé)人接收需求后，再次初步劃分是任務(wù)還是工程和優(yōu)先級等，然后轉(zhuǎn)給技術(shù)部經(jīng)理進(jìn)展具體的排期、評估工作量、分配處理人等3.2根據(jù)情況，如果技術(shù)部經(jīng)理不確定，則轉(zhuǎn)審批小組進(jìn)展審批和安排4.

按照任務(wù)管理或工程管理進(jìn)展處理。需求管理人跟蹤進(jìn)度；是任務(wù)，需求申請人跟蹤進(jìn)度；是工程，則工程經(jīng)理跟蹤進(jìn)度。工程需求申請工程需求申請流程說明：工程需求的提出人一般是需求部門主管和經(jīng)理根據(jù)重要性直接要求，然后安排執(zhí)行人。1.需求執(zhí)行人編寫?需求說明書?和?工程方案?〔如果能給?工程建議書?更好〕，寫完后提交給技術(shù)中心需求管理負(fù)責(zé)人2.技術(shù)中心需求管理負(fù)責(zé)人接收工程后，組織審批小組進(jìn)展審批和安排3.按照工程管理進(jìn)展執(zhí)行。需求管理人跟蹤進(jìn)度，工程經(jīng)理跟蹤進(jìn)度。3.4需求響應(yīng)優(yōu)先級表優(yōu)先級類別內(nèi)容響應(yīng)高

重大事故

無法。不能翻開，或局部網(wǎng)頁不能翻開

用戶無法注冊、沖值

派獎金額錯誤

無法出票

用戶無法交易立即響應(yīng)注：出現(xiàn)此類問題，不需要填寫需求申請單，發(fā)現(xiàn)人直接與技術(shù)部經(jīng)理交流中

問題不影響交易，但影響運營

促銷活動的任務(wù)

新彩種、新玩法、新產(chǎn)品的開發(fā)。例如：二期工程、增加福彩七樂彩等

頁面的調(diào)整、促銷專題頁面按正常流程處理低

完善性的需求，屬于錦上添花的功能。先處理中級別任務(wù)，有時間再處理低級別需求4工程管理4.1立項管理立項管理〔ProjectInitializationManagement,PIM〕的目的是：〔1〕采納符合機(jī)構(gòu)最大利益的立項建議，通過立項管理使該建議成為正式的工程〔即合法化〕?！?〕杜絕不符合機(jī)構(gòu)最大利益的立項建議被采納，防止浪費機(jī)構(gòu)的人力資源、資金、時間等。立項管理是決策行為，其目標(biāo)是“做正確的事情〞〔dorightthings〕。而立項之后的研發(fā)活動和管理活動的目標(biāo)是“正確地做事情〞〔dothingsright〕。只有“正確的決策〞加上“正確地執(zhí)行〞才可能產(chǎn)生優(yōu)秀的產(chǎn)品。立項評審機(jī)構(gòu)領(lǐng)導(dǎo)組織一個評審委員會進(jìn)展立項評審。評審委員會根據(jù)?立項建議書?、?立項調(diào)查報告?、?立項可行性分析報告?以及立項建議小組的辯論，投票決定是否同意立項〔按少數(shù)服從多數(shù)原則〕。評審委員會應(yīng)根據(jù)機(jī)構(gòu)的實際情況〔開展戰(zhàn)略、資金、人力資源等〕，對?立項建議書?提出改良意見。機(jī)構(gòu)領(lǐng)導(dǎo)對立項具有最終審批權(quán)。如果機(jī)構(gòu)領(lǐng)導(dǎo)贊同評審委員會的決策，則他們將共同分擔(dān)決策責(zé)任。如果機(jī)構(gòu)領(lǐng)導(dǎo)行使“一票否決權(quán)〞，則他將對該決策負(fù)全部責(zé)任。工程啟動正式成立工程組時，必須要有工程啟動會議，高管也參與會議，作任命工程經(jīng)理的說明，并簡要介紹工程的內(nèi)容和目標(biāo)簡要說明。然后工程經(jīng)理介紹工程方案，包括工程目標(biāo)，內(nèi)容，時間進(jìn)度，組員分工安排等。工程經(jīng)理被任命之后，機(jī)構(gòu)領(lǐng)導(dǎo)協(xié)助工程經(jīng)理獲取工程經(jīng)費、人力資源、軟硬件資源等。要注意的是，如果工程所需的資金和資源難以按時到位，此時工程經(jīng)理不可老在等待或只是抱怨，應(yīng)當(dāng)主動設(shè)法克制困難，盡早行動起來。很多時候，資金和資源是爭取來的，而不是等來的。如果必要的資金和資源已經(jīng)到位，工程經(jīng)理和工程核心成員根據(jù)實際情況撰寫?工程方案?，執(zhí)行工程研發(fā)和管理工作。4.2工程開發(fā)流程不強(qiáng)調(diào)太復(fù)雜的流程和多數(shù)量的文檔。主要以工程管理的方式來進(jìn)展管理?？傮w的流程思路按照需求設(shè)計開發(fā)測試上線開發(fā)流程說明1.市場的籌劃人員收集用戶需求，整理成?用戶需求說明書?調(diào)查、分析用戶的需求2.1技術(shù)部的系統(tǒng)分析人員，將用戶的原始需求從技術(shù)的角度翻譯成可實現(xiàn)的?產(chǎn)品需求規(guī)格說明書?2.2市場的籌劃人員根據(jù)?用戶需求說明書?，與技術(shù)部的相關(guān)人員進(jìn)展協(xié)商，設(shè)計界面原型。3.1技術(shù)部的系統(tǒng)設(shè)計人員將依據(jù)?產(chǎn)品需求規(guī)格說明書?開展系統(tǒng)設(shè)計工作。形成?系統(tǒng)概要設(shè)計說明?，包括的架構(gòu)，數(shù)據(jù)庫，后臺，核心流程，模塊劃分等。3.2運營部的籌劃人員細(xì)化界面4.1技術(shù)部的開發(fā)人員依據(jù)?系統(tǒng)概要設(shè)計說明?一邊做詳細(xì)設(shè)計一邊開場編碼。時間允許的情況下寫?詳細(xì)設(shè)計說明書?，不允許的情況下直接編碼4.2美工人員做圖片，flash等4.3測試人員根據(jù)需求規(guī)格說明書和詳細(xì)設(shè)計說明書以及設(shè)計界面寫測試方案和測試用例5.測試和問題修改。6.上線注：本文檔只是簡要列明工程的開發(fā)過程，具體的實踐操作請參見?技術(shù)中心工程開發(fā)過程規(guī)*?。4.3開發(fā)方法界面原型法。需求除了用文字描述之外，直接畫成圖形界面來表達(dá)功能。界面直接反映了該所具有的功能情況。缺乏點能立即發(fā)現(xiàn)和修改，防止工程的后期返工。4.4質(zhì)量保證方法建立評審制度，對開發(fā)各階段的工件進(jìn)展評審，如：需求階段的用戶需求說明書和界面原型等進(jìn)展討論。評審方法：評審前，文檔編寫人員先提前半天，一天甚至兩天將自己的工作成果文檔等發(fā)送給所有將需要參與評審的人員進(jìn)展查看，以便有個初步了解。需要確定評審的主題。需要一個評審主持人，控制討論不要偏題和討論的進(jìn)度。否則討論沒完沒了。需求編寫人員分享自己的思路其他人員發(fā)表意見。文檔編寫人員及時記錄需要修改的意見。4.5工程進(jìn)度監(jiān)控和管理工程經(jīng)理對整個工程負(fù)責(zé)。進(jìn)展監(jiān)視本錢、進(jìn)度和質(zhì)量。目前的本錢主要是人員的薪水，包含在進(jìn)度中。即工程經(jīng)理對整個工程進(jìn)展管理，監(jiān)控進(jìn)度和質(zhì)量。QA輔助工程經(jīng)理對工程進(jìn)度進(jìn)展跟蹤。在開發(fā)流程和管理給予支持，幫助工程經(jīng)理爭取資源等。白板展示管理法將工程的階段、執(zhí)行人、時間、進(jìn)展?fàn)顟B(tài)展示在公司的公告欄上。工程進(jìn)度更新為每周五下午進(jìn)展一次更新。如果完成一個大的里程牌，也可當(dāng)即更新。周五更新后，工程成員在周一時繼續(xù)按照工程進(jìn)度方案來處理安排給自己的工作。4.6工程結(jié)項管理立項管理與結(jié)項管理是前后照應(yīng)的兩個過程域，使得工程管理過程“有始有終〞。工程完畢有兩種狀況：一是正常完畢，二是異常完畢。前者是指工程按預(yù)定方案完畢。后者原因有多種，歸根結(jié)底都是由于該工程不再符合機(jī)構(gòu)的最大利益。例如有些工程因不適應(yīng)市場而被中途淘汰，有些工程在執(zhí)行過程中大大因偏離方案〔如進(jìn)度延誤、費用超支〕而被取消。不管工程屬于正常完畢還是異常完畢，都要按照結(jié)項管理規(guī)*處理。有價值的結(jié)項管理至少包括三項內(nèi)容：對工程的有形資產(chǎn)和無形資產(chǎn)進(jìn)展清算，既要防止資產(chǎn)流失，又要及時地利用這些資產(chǎn)。對工程進(jìn)展綜合評估。例如評估工程完成情況、工程質(zhì)量、投入產(chǎn)出分析、工程的市場價值、工程對企業(yè)的奉獻(xiàn)等等。該評估報告可以作為考核工程人員業(yè)績的重要依據(jù)?？偨Y(jié)經(jīng)歷教訓(xùn)，使整個機(jī)構(gòu)受益。工程結(jié)項標(biāo)準(zhǔn)測試后，嚴(yán)重問題0個，一般嚴(yán)重問題1~3個?？梢陨暇€。試運行上線后，運營交給運營部。上線后的前兩個星期為試運行階段，在該階段技術(shù)部和運營部都參與，一旦發(fā)現(xiàn)問題，技術(shù)需立即響應(yīng)進(jìn)展修改和測試，運營可以提出問題和建議給技術(shù)。提出方式還是以問題的方式，在TD中填寫B(tài)UG，開發(fā)人員修改自己下的BUG。正式運行兩星期后，一般視情況，問題的多和少來決定試運行的時間。在試運行沒有什么大問題后，進(jìn)入正式運行階段。全權(quán)交與運營部接收。正式運行后，如果有什么問題或建議，則由運營部填寫?需求變更申請跟蹤單?，按照任務(wù)處理流程進(jìn)展處理。5任務(wù)管理5.1任務(wù)開發(fā)流程任務(wù)開發(fā)流程圖任務(wù)開發(fā)流程說明注：接收的需求不包含頁面、圖片的調(diào)整。如有頁面、圖片的調(diào)整直接轉(zhuǎn)設(shè)計部。1.接收客服、運營、市場籌劃或技術(shù)部提出的需求2.需求接收人a.預(yù)審需求內(nèi)容；b.根據(jù)“任務(wù)優(yōu)先級規(guī)則表〞預(yù)排優(yōu)先級；3.需求預(yù)審?fù)ㄟ^后，技術(shù)部經(jīng)理a.進(jìn)一步評審需求內(nèi)容；b.評估開發(fā)工作量；c.確定優(yōu)先級；d.分配執(zhí)行人；e.安排開發(fā)時間進(jìn)度。需求內(nèi)容：如果有需要則由相關(guān)領(lǐng)導(dǎo)和業(yè)務(wù)專家組成評審小組來討論需求優(yōu)先級：對于特珠的需求，超出“任務(wù)優(yōu)先級規(guī)則表〞*圍，則由領(lǐng)導(dǎo)小組來指定。4.

執(zhí)行開發(fā)5.

執(zhí)行測試6.上線5.2任務(wù)響應(yīng)優(yōu)先級表優(yōu)先級類別內(nèi)容響應(yīng)高

重大事故

無法。不能翻開，或局部網(wǎng)頁不能翻開

用戶無法注冊、沖值

派獎金額錯誤

無法出票

用戶無法交易立即響應(yīng)注：出現(xiàn)此類問題，不需要填寫需求申請單，發(fā)現(xiàn)人直接與技術(shù)部經(jīng)理交流中

問題不影響交易，但影響運營

頁面的調(diào)整、促銷專題頁面按正常任務(wù)流程處理低

完善性的需求，屬于錦上添花的功能。先處理中級別任務(wù)，有時間則處理低級別任務(wù)5.3任務(wù)進(jìn)度監(jiān)控和管理任務(wù)會有許多個，并且是并發(fā)進(jìn)展的。每一個任務(wù)不可能指定一個任務(wù)管理人。需要一個專人對任務(wù)進(jìn)展跟蹤和監(jiān)視，并在任務(wù)出現(xiàn)異常時隨時向領(lǐng)導(dǎo)匯報。白板展示管理法將這個月的任務(wù)、優(yōu)先級、執(zhí)行人、時間、進(jìn)展?fàn)顟B(tài)展示在公司的公告欄上。任務(wù)進(jìn)度更新為每周五下午進(jìn)展一次更新。如果該任務(wù)完成，也可當(dāng)即更新。周五更新后，任務(wù)執(zhí)行人在周一時繼續(xù)按照任務(wù)進(jìn)度方案來處理安排給自己的工作。5.4任務(wù)完畢管理任務(wù)完畢標(biāo)準(zhǔn)測試后，嚴(yán)重問題0個，一般嚴(yán)重問題1~3個。測試通過上線后，由運營部接收。上線后先試運行一段時間，如果有問題，運營直接反應(yīng)給技術(shù)部的相關(guān)人員進(jìn)展修改。試運行沒問題后轉(zhuǎn)入正式運行。附錄相關(guān)文檔模板：需求申請跟蹤單工程建議書工程方案用戶需求說明書需求規(guī)格說明書客服問題記錄跟蹤單工程團(tuán)隊組建的根本原則①根據(jù)工程*圍和預(yù)算確定團(tuán)隊的人數(shù)工程初始階段，工程經(jīng)理也許只了解到一些有關(guān)工程*圍、交貨期限方面的信息以及客戶對一些功能需求的簡單描述。為了對工程人力進(jìn)展估計，有必要進(jìn)一步細(xì)化工程*圍。◆首先在企業(yè)內(nèi)部爭取到一個比擬得力的助手，他可能是工程未來的開發(fā)經(jīng)理、系統(tǒng)分析員或高級程序員。這一點很重要，既然你的工程組一定會有其他人的參與，與其到外面去招，不如在內(nèi)部找你熟悉和信賴的同事加盟。因為你不僅了解他們的能力，而且作為老員工，他們的穩(wěn)定性也相對有保障，更重要的是，工程一開場你就不再是孤軍奮戰(zhàn)，至少有一個得力的助手和你一起討論，分擔(dān)你的工作壓力。經(jīng)歷說明，在有人一起討論的情況下，工作的積極性、決策的準(zhǔn)確度等通常都會提高?！粝乱徊骄褪呛退黄鸹ㄒ恍r間與客戶溝通，把手頭上的工程*圍和功能需求描述盡可能再細(xì)化一些，包括每個功能需求都有哪些子需求，這些需求是如何配合形成一個業(yè)務(wù)鏈的。有哪些系統(tǒng)數(shù)據(jù)需要維護(hù)，有多少*報表要出，哪些需求是要優(yōu)先完成的，系統(tǒng)需要實現(xiàn)的業(yè)務(wù)有多復(fù)雜，哪些外圍系統(tǒng)和當(dāng)前系統(tǒng)有關(guān)系，是否有數(shù)據(jù)接口和數(shù)據(jù)轉(zhuǎn)換方面的需求等等?！舭鸭?xì)化后的工程*圍錄入工程管理系統(tǒng)〔推薦使用MSProject〕，根據(jù)客戶要求的優(yōu)先級把工程劃分成假設(shè)干階段，每個階段提交一局部功能并預(yù)留一些風(fēng)險準(zhǔn)備時間，根據(jù)需要加上需求分析、系統(tǒng)設(shè)計、編碼、測試以及工程管理等方面的活動?！魧ζ渲械娜蝿?wù)，找實現(xiàn)技術(shù)相近的已完成的工程進(jìn)展對照，估算出每個任務(wù)大致需要的man-day數(shù)，然后參考以下方法粗略估計出工程需要的人數(shù)。人數(shù)=man-day總數(shù)/〔距交貨期限的工作日數(shù)×工作效率〕其中工作效率指的是日有效工作時間與日總工作時間的比值。例如：企業(yè)采取8小時工作制，組員可能只有6～7小時真正投入到工作中，有1～2個小時可能會心不在焉，四處走動或處理一些私事，則工作效率就介于6/8=0.75和7/8=0.875之間，根據(jù)經(jīng)歷一般取0.8比擬合理。Y提示*估算*一任務(wù)的man-day數(shù)時，最好兩個人獨立估算，然后再進(jìn)展比對，差距較大時，聽一聽對方的考慮，再得出結(jié)論。*估算*一任務(wù)的man-day數(shù)時，估算人應(yīng)該依據(jù)目標(biāo)角色的平均水準(zhǔn)而不是他自己的能力標(biāo)準(zhǔn)來進(jìn)展估算〔除非該項任務(wù)就是由他本人負(fù)責(zé)的〕。*成熟的IT企業(yè)一般建有工程資源庫，也會提供一些標(biāo)準(zhǔn)的經(jīng)歷統(tǒng)計值，這些都是很好的參考，但還是建議和對照工程的負(fù)責(zé)人好好聊一聊，取取經(jīng)，可以獲得更加準(zhǔn)確的信息。*這個估算值是比擬粗略的，因為有好些因素還沒有考慮進(jìn)去。例如：組員的休假方案，特別是一些可預(yù)期的長假方案，任務(wù)之間的制約關(guān)系，人員未必是一次性全部到位的?！羧绻蝿?wù)超過5個man-day，需要把它進(jìn)一步拆分成相關(guān)的多個子任務(wù)，這樣每個子任務(wù)就可以只分配給一個人完成，并且在一周內(nèi)就可以得到明確的進(jìn)度反應(yīng)?？紤]到任務(wù)之間會有一定的制約關(guān)系，有些任務(wù)必須等到其他任務(wù)完成后才可以開場，有些任務(wù)必須與其他任務(wù)同時開場或同步完成，盡量把這些最根本的約束關(guān)系明確下來。很多工程管理軟件提供了甘特圖功能，可以方便地完成這些事情?！粢灾按致怨烙嫷娜藛T數(shù)目為基準(zhǔn)，根據(jù)人員的目標(biāo)角色