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

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

1目的

用于指導(dǎo)公司的技術(shù)中心軟件開發(fā)工作？定義了各部門與技

術(shù)部的協(xié)作接口和流程？定義了項(xiàng)目開發(fā)流程和管理辦法？

定義了任務(wù)開發(fā)流程和管理辦法

2說明

2.1范圍

本文檔只適用于技術(shù)中心針對XXXX網(wǎng)站及其相關(guān)的一般性開

發(fā)工作。包括：？網(wǎng)站維護(hù)性開發(fā)？項(xiàng)目開發(fā)

本文檔不適用于網(wǎng)站運(yùn)維護(hù)性的系統(tǒng)維護(hù)工作。不涉及：？

網(wǎng)站的網(wǎng)絡(luò)安全、FTP權(quán)限等？數(shù)據(jù)庫的安全、備份等？系

統(tǒng)環(huán)境等

凡網(wǎng)站運(yùn)維性的系統(tǒng)維護(hù)工作請另參見《運(yùn)維管理規(guī)范》文

檔C

2.2技術(shù)中心組織架構(gòu)

技術(shù)中心組織架構(gòu)圖

技術(shù)中心組織架構(gòu)說明

目前技術(shù)中心從處理的工作性質(zhì)分為三大部分：運(yùn)維、開發(fā)

和測試。根據(jù)需求工作量的大和小，其中開發(fā)的工作又細(xì)分

為兩類：？網(wǎng)站維護(hù)開發(fā)？網(wǎng)站項(xiàng)目開發(fā)

根據(jù)網(wǎng)站具體的開發(fā)工作內(nèi)容不同，又可將維護(hù)開發(fā)組和項(xiàng)

目開發(fā)組的人員細(xì)分前臺開發(fā)人員和后臺開發(fā)人員。

各小組的職責(zé)范圍

運(yùn)維組：處理系統(tǒng)維護(hù)性的工作，包括系統(tǒng)安裝維護(hù)、網(wǎng)絡(luò)

安全、數(shù)據(jù)庫調(diào)

優(yōu)備份等。關(guān)于運(yùn)維的工作本文檔不再詳細(xì)說明，請參見

《運(yùn)維管理規(guī)范》文檔

維護(hù)開發(fā)組：處理網(wǎng)站的日常小問題的修改、新需求的增加

（但工作量不大）

等維護(hù)性的開發(fā)。

項(xiàng)目開發(fā)組：處理新項(xiàng)目的開發(fā)。

測試組：負(fù)責(zé)對維護(hù)開發(fā)和項(xiàng)目開發(fā)進(jìn)行測試。

網(wǎng)站前臺開發(fā)人員：負(fù)責(zé)對網(wǎng)站前臺的功能進(jìn)行開發(fā)。

網(wǎng)站后臺開發(fā)人員：負(fù)責(zé)對網(wǎng)站后臺的用戶管理、權(quán)限管

理、開發(fā)、出票等

后臺的功能進(jìn)行開發(fā)。

由于人力資源的限制，目前沒有專職的網(wǎng)站維護(hù)開發(fā)和項(xiàng)目

開發(fā)，在沒有新項(xiàng)目時(shí)，所有人員都可安排參與網(wǎng)站維護(hù)開

發(fā)的工作。當(dāng)有新項(xiàng)目時(shí)再組建項(xiàng)目組。但有高優(yōu)先級的維

護(hù)工作要處理而又人手不夠的情況下，項(xiàng)目組的人員必須優(yōu)

先處理網(wǎng)站維護(hù)緊急事件。

2.3項(xiàng)目與任務(wù)的定義

什么是開發(fā)類項(xiàng)目（項(xiàng)目）

滿足以下任意一條件進(jìn)行開發(fā)的項(xiàng)目均為開發(fā)類項(xiàng)目：？以

前從未開發(fā)過的系統(tǒng)；

不存在或基本不存在可復(fù)用的技術(shù)、模塊，或業(yè)務(wù)邏輯、體

系結(jié)構(gòu)等或者在原產(chǎn)品上

進(jìn)行大的結(jié)構(gòu)性調(diào)整。

在公司已有的成熟產(chǎn)品或可復(fù)用模塊或技術(shù)基礎(chǔ)上，根據(jù)業(yè)

務(wù)需要和客戶需求，新增

獨(dú)立業(yè)務(wù)模塊，且開發(fā)工作量超過1人月，如果是2至3人

開發(fā)工作但超過2星期根據(jù)情況也可劃為開發(fā)類項(xiàng)目。新彩

種、新玩法、新產(chǎn)品的開發(fā)等都可以劃為開發(fā)類項(xiàng)目。（此

要求沒有硬性要求，可以視情況而定。）

例如：網(wǎng)站二期項(xiàng)目、增加福彩七樂彩、增加快樂十分游

戲、足彩單場項(xiàng)目、無線項(xiàng)目、安微客服項(xiàng)目等。

什么是維護(hù)類開發(fā)（任務(wù)）

在現(xiàn)已運(yùn)行的網(wǎng)站基礎(chǔ)上，根據(jù)運(yùn)營的需要或者市場規(guī)劃的

需要，提供補(bǔ)

丁、實(shí)現(xiàn)新的需求

工作量通過技術(shù)部經(jīng)理評估小于1人月但超過1個(gè)小時(shí)的。

例如：頁面的調(diào)整、促銷專題頁面，日常運(yùn)營中發(fā)現(xiàn)網(wǎng)站的

問題等。

3.需求管理

3.1需求來源

需求來源類型：技術(shù)部提出

運(yùn)營部（包括客服組）提出？市場策劃部提出

技術(shù)部需求

提出人：技術(shù)部經(jīng)理或技術(shù)骨干提出原因：

1.隨著網(wǎng)站新加游戲、玩法，注冊用戶增多等，對網(wǎng)站的可

擴(kuò)展性、穩(wěn)定性、安全性等提出了更高的要求，在時(shí)間允許

的情況下，技術(shù)部有對網(wǎng)站進(jìn)行技術(shù)優(yōu)化的需求。此種情況

的執(zhí)行和跟蹤轉(zhuǎn)根據(jù)工作量的大和小轉(zhuǎn)項(xiàng)目管理或任務(wù)管

理。

2.在用戶還未發(fā)現(xiàn)的問題，但技術(shù)部清楚存在的缺陷，需要

對網(wǎng)站進(jìn)行打補(bǔ)丁升級。此種情況的執(zhí)行和跟蹤轉(zhuǎn)任務(wù)管

理。提交文檔：

如果是任務(wù)，填寫《需求變更申請單（技術(shù)部）》；如果是

項(xiàng)目，編寫《需求說明書》和給出《項(xiàng)目計(jì)劃（初步）》

運(yùn)營部需求

提出人：運(yùn)營部的所有人員（包括客服、編輯等）提出原

因：

在日常運(yùn)營過程中會發(fā)現(xiàn)一些問題和提一些完善的建議。網(wǎng)

站發(fā)布后，面對廣大用戶，用戶在使月過程中會產(chǎn)生大量的

問題和意見。這些問題和意見由客服組統(tǒng)一收集，然后反饋

給運(yùn)營負(fù)責(zé)人。根據(jù)工作量的大和小轉(zhuǎn)項(xiàng)目管理或任務(wù)管

理。提交文檔：

如果是任務(wù)，填寫《需求申請單（運(yùn)營部）》；如果是項(xiàng)

目，編寫《需求說明書》和給出《項(xiàng)目計(jì)劃（初步）》

注：客服在接收客戶的問題和建議后，如果是影響交易的，

可以直接向技術(shù)部經(jīng)理反饋，否則把問題反饋給運(yùn)營負(fù)責(zé)

人，由運(yùn)營負(fù)責(zé)人按正常流程處理。

市場策劃部需求

提出人：策劃部主管提出原因：

總結(jié)、提煉客戶原始需求，推出升級版本、根據(jù)市場需要推

出新產(chǎn)品、活動(dòng)促銷等。根據(jù)工作量的大和小轉(zhuǎn)項(xiàng)目管理或

任務(wù)管理。一般工作量比較大，轉(zhuǎn)項(xiàng)目管理。提交文檔：

如果是任務(wù)，填寫《需求申請單（策劃部）》；如果是項(xiàng)

目，編寫《需求說明書》和給出《項(xiàng)目計(jì)劃（初步）》

其它

上述只列出了三個(gè)部門的需求來源，但公司歡迎任何人向我

們公司網(wǎng)站和產(chǎn)品等提出問題和建議?？梢酝ㄟ^口頭或書面

的形式向運(yùn)營主管或策劃主管先提，運(yù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)時(shí)間：接收需求后，必須在半天以內(nèi)向需求申請人

反饋對需求的處理結(jié)果。包括處理意見，處理人，計(jì)劃完成

時(shí)間等信息。

需求管理負(fù)責(zé)人職責(zé):

專門分類匯總、整理提交的需求。初步劃分是任務(wù)還是項(xiàng)

目。？整理后交給技術(shù)部經(jīng)理進(jìn)行劃分

整理后如果是項(xiàng)目交給審批小組進(jìn)行評估和審批。

審批小組組成：根據(jù)需求的內(nèi)容臨時(shí)組建審批小組。成員一

般包括與該需求有關(guān)的各部門主管、業(yè)務(wù)專家、技術(shù)主干

等。

審批小組職責(zé)：

批準(zhǔn)立項(xiàng)是否成立

根據(jù)《需求優(yōu)先級規(guī)則表》劃分需求的優(yōu)先級？確定是項(xiàng)目

還是任務(wù)？指定解決的部門或個(gè)人。？安排解決的時(shí)間。

3.3需求申請流程

需求的申請流程分為任務(wù)需求申請和項(xiàng)目需求申請。任務(wù)需

求申請

任務(wù)需求申請流程說明：

1.需求申請人填寫《需求申請跟蹤單》，并確定緊急程度；

2.申請部門的主管或經(jīng)理審批需求，通過后將需求轉(zhuǎn)給技術(shù)

中心需求管理負(fù)責(zé)人，不通過則繼續(xù)修改或取消；

3.1需求管理負(fù)責(zé)人接收需求后，再次初步劃分是任務(wù)還是項(xiàng)

目和優(yōu)先級等，然后轉(zhuǎn)給技術(shù)部經(jīng)理進(jìn)行具體的排期、評估

工作量、分配處理人等

3.2根據(jù)情況，如果技術(shù)部經(jīng)理不確定，則轉(zhuǎn)審批小組進(jìn)行審

批和安排

4.按照任務(wù)管理或項(xiàng)目管理進(jìn)行處理。需求管理人跟蹤進(jìn)

度；是任務(wù)，需求申請人跟蹤進(jìn)度；是項(xiàng)目，則項(xiàng)目經(jīng)理跟

蹤進(jìn)度。

項(xiàng)目需求申請

項(xiàng)目需求申請流程說明：

項(xiàng)目需求的提出人一般是需求部門主管和經(jīng)理根據(jù)重要性直

接要求，然后安排執(zhí)行人。

1.需求執(zhí)行人編寫《需求說明書》和《項(xiàng)目計(jì)劃》（如果能

給《項(xiàng)目建議書》更好），寫完后提交給技術(shù)中心需求管理

負(fù)責(zé)人

2.技術(shù)中心需求管理負(fù)責(zé)人接收項(xiàng)目后，組織審批小組進(jìn)行

審批和安排3.按照項(xiàng)目管理進(jìn)行執(zhí)行。需求管理人跟蹤進(jìn)

度，項(xiàng)目經(jīng)理跟蹤進(jìn)度。

3.4需求響應(yīng)優(yōu)先級表

4項(xiàng)目管理

4.1立項(xiàng)管理

立項(xiàng)管理（ProjectInitializationManagement,PIM）的

目的是：（1）采納符合機(jī)構(gòu)最大利益的立項(xiàng)建議，通過立項(xiàng)

管理使該建議成為正式的項(xiàng)目（即合法化）。（2）杜絕不符

合機(jī)構(gòu)最大利益的立項(xiàng)建議被采納，避免浪費(fèi)機(jī)構(gòu)的人力資

源、資金、時(shí)間等。

立項(xiàng)管理是決策行為，其目標(biāo)是“做正確的事情”（do

rightthings）。而立項(xiàng)之后的研發(fā)活動(dòng)和管理活動(dòng)的目標(biāo)

是“正確地做事情”（dothingsright）o只有“正確的決

策”加上“正確地執(zhí)行“才可能產(chǎn)生優(yōu)秀的產(chǎn)品。

立項(xiàng)評審

機(jī)構(gòu)領(lǐng)導(dǎo)組織一個(gè)評審委員會進(jìn)行立項(xiàng)評審。評審委員會根

據(jù)《立項(xiàng)建議書》、《立項(xiàng)調(diào)查報(bào)告》、《立項(xiàng)可行性分析

報(bào)告》以及立項(xiàng)建議小組的答辯，投票決定是否同意立項(xiàng)

（按少數(shù)服從多數(shù)原則）。評審委員會應(yīng)根據(jù)機(jī)構(gòu)的實(shí)際情

況（發(fā)展戰(zhàn)略、資金、人力資源等），對《立項(xiàng)建議書》提

出改進(jìn)意見。

機(jī)構(gòu)領(lǐng)導(dǎo)對立項(xiàng)具有最終審批權(quán)。如果機(jī)構(gòu)領(lǐng)導(dǎo)贊同評審委

員會的決策，那么他們將共同分擔(dān)決策責(zé)任。如果機(jī)構(gòu)領(lǐng)導(dǎo)

行使“一票否決權(quán)”,那么他將對該決策負(fù)全部責(zé)任。

項(xiàng)目啟動(dòng)

正式成立項(xiàng)目組時(shí)，必須要有項(xiàng)目啟動(dòng)會議，高管也參與會

議，作任命項(xiàng)目經(jīng)理的說明，并簡要介紹項(xiàng)目的內(nèi)容和目標(biāo)

簡要說明。然后項(xiàng)目經(jīng)理介紹項(xiàng)目計(jì)劃，包括項(xiàng)目目標(biāo)，內(nèi)

容，時(shí)間進(jìn)度，組員分工安排等。

項(xiàng)目經(jīng)理被任命之后，機(jī)構(gòu)領(lǐng)導(dǎo)協(xié)助項(xiàng)目經(jīng)理獲取項(xiàng)目經(jīng)

費(fèi)、人力資源、軟硬件資源等。要注意的是，如果項(xiàng)目所需

的資金和資源難以按時(shí)到位，此時(shí)項(xiàng)目經(jīng)理不可老在等待或

只是抱怨，應(yīng)當(dāng)主動(dòng)設(shè)法克服困難，盡早行動(dòng)起來。很多時(shí)

候，資金和資源是爭取來的，而不是等來的。

如果必要的資金和資源已經(jīng)到位，項(xiàng)目經(jīng)理和項(xiàng)目核心成員

根據(jù)實(shí)際情況撰寫《項(xiàng)目計(jì)劃》，執(zhí)行項(xiàng)目研發(fā)和管理工

作。

4.2項(xiàng)目開發(fā)流程

不強(qiáng)調(diào)太復(fù)雜的流程和多數(shù)量的文檔。主要以項(xiàng)目管理的方

式來進(jìn)行管理。

總體的流程思路按照需求?設(shè)計(jì)?開發(fā)?測試?上線

開發(fā)流程說明

1.市場的策劃人員收集用戶需求，整理成《用戶需求說明

書》調(diào)查、分析用戶的需求

2.1技術(shù)部的系統(tǒng)分析人員，將用戶的原始需求從技術(shù)的角度

翻譯成可實(shí)現(xiàn)的《產(chǎn)品需求規(guī)格說明書》

2.2市場的策劃人員根據(jù)《用戶需求說明書》，與技術(shù)部的相

關(guān)人員進(jìn)行協(xié)商，設(shè)計(jì)界面原型。

3.1技術(shù)部的系統(tǒng)設(shè)計(jì)人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開

展系統(tǒng)設(shè)計(jì)工作。形成《系統(tǒng)概要設(shè)計(jì)說明》，包括網(wǎng)站的

架構(gòu)，數(shù)據(jù)庫，后臺，核心流程，模塊劃分等。

3.2運(yùn)營部的策劃人員細(xì)化界面

4.1技術(shù)部的開發(fā)人員依據(jù)《系統(tǒng)概要設(shè)計(jì)說明》一邊做詳細(xì)

設(shè)計(jì)一邊開始編碼。時(shí)間允許的情況下寫《詳細(xì)設(shè)計(jì)說明

書》，不允許的情況下直接編碼4.2美工人員做圖片，flash

等

4.3測試人員根據(jù)需求規(guī)格說明書和詳細(xì)設(shè)計(jì)說明書以及設(shè)計(jì)

界面寫測試方案和測試用例

5.測試和問題修改。

6.上線

注：本文檔只是簡要列明項(xiàng)目的開發(fā)過程，具體的實(shí)踐操作

請參見《技術(shù)中心項(xiàng)目開發(fā)過程規(guī)范》。

4.3開發(fā)方法

界面原型法。需求除了用文字描述之外，直接畫成圖形界面

來表達(dá)功能。界面直接反映了該網(wǎng)站所具有的功能情況。不

足點(diǎn)能立即發(fā)現(xiàn)和修改，避免項(xiàng)目的后期返工。

4.4質(zhì)量保證辦法

建立評審制度，對開發(fā)各階段的工件進(jìn)行評審，如：需求階

段的用戶需求說明書和界面原型等進(jìn)行討論。

評審辦法：評審前，文檔編寫人員先提前半天，一天甚至兩

天將自己的工作成果文檔等發(fā)送給所有將需要參與評審的人

員進(jìn)行查看，以便有個(gè)初步了解。需要確定評審的主題。

需要一個(gè)評審主持人，控制討論不要偏題和討論的進(jìn)度。否

則討論沒完沒了。需求編寫人員分享自己的思路其他人員

發(fā)表意見。

文檔編寫人員及時(shí)記錄需要修改的意見。

4.5項(xiàng)目進(jìn)度監(jiān)控和管理

項(xiàng)目經(jīng)理對整個(gè)項(xiàng)目負(fù)責(zé)。進(jìn)行監(jiān)督成本、進(jìn)度和質(zhì)量。目

前的成本主要是人員的薪水，包含在進(jìn)度中。即項(xiàng)目經(jīng)理對

整個(gè)項(xiàng)目進(jìn)行管理，監(jiān)控進(jìn)度和質(zhì)量。

QA輔助項(xiàng)目經(jīng)理對項(xiàng)目進(jìn)度進(jìn)行跟蹤。在開發(fā)流程和管理給

予支持，幫助項(xiàng)目經(jīng)理爭取資源等。

白板展示管理法

將項(xiàng)目的階段、執(zhí)行人、時(shí)間、進(jìn)行狀態(tài)展示在公司的公告

欄上。項(xiàng)目進(jìn)度更新為每周五下午進(jìn)行一次更新。如果完成

一個(gè)大的里程牌，也可當(dāng)即更新。

周五更新后，項(xiàng)目成員在周一時(shí)繼續(xù)按照項(xiàng)目進(jìn)度計(jì)劃來處

理安排給自己的工作。

4.6項(xiàng)目結(jié)項(xiàng)管理

立項(xiàng)管理與結(jié)項(xiàng)管理是前后呼應(yīng)的兩個(gè)過程域，使得項(xiàng)目管

理過程“有始有終”。

項(xiàng)目結(jié)束有兩種狀況：一是正常結(jié)束，二是異常結(jié)束。前者

是指項(xiàng)目按預(yù)定計(jì)劃結(jié)束。后者原因有多種，歸根結(jié)底都是

由于該項(xiàng)目不再符合機(jī)構(gòu)的最大利益。例如有些項(xiàng)目因不適

應(yīng)市場而被中途淘汰，有些項(xiàng)目在執(zhí)行過程中大大因偏離計(jì)

劃（如進(jìn)度延誤、費(fèi)用超支）而被取消。

不論項(xiàng)目屬于正常結(jié)束還是異常結(jié)束，都要按照結(jié)項(xiàng)管理規(guī)

范處理。有價(jià)值的結(jié)項(xiàng)管理至少包括三項(xiàng)內(nèi)容：

對項(xiàng)目的有形資產(chǎn)和無形資產(chǎn)進(jìn)行清算，既要防止資產(chǎn)流

失，又要及時(shí)

地利用這些資產(chǎn)。

對項(xiàng)目進(jìn)行綜合評估。例如評估項(xiàng)目完成情況、項(xiàng)目質(zhì)量、

投入產(chǎn)出分

析、項(xiàng)目的市場價(jià)值、項(xiàng)目對企業(yè)的貢獻(xiàn)等等。該評估報(bào)告

可以作為考核項(xiàng)目人員業(yè)績的重要依據(jù)。

總結(jié)經(jīng)驗(yàn)教訓(xùn)，使整個(gè)機(jī)構(gòu)受益。

項(xiàng)目結(jié)項(xiàng)標(biāo)準(zhǔn)

測試后，嚴(yán)重問題0個(gè)，一般嚴(yán)重問題「3個(gè)。可以上線。

試運(yùn)行

上線后，網(wǎng)站運(yùn)營交給運(yùn)營部。上線后的前兩個(gè)星期為試運(yùn)

行階段，在該階段技術(shù)部和運(yùn)營部都參與，一旦發(fā)現(xiàn)問題，

技術(shù)需立即響應(yīng)進(jìn)行修改和測試，運(yùn)營可以提出問題和建議

給技術(shù)。提出方式還是以問題的方式，在TD中填寫B(tài)UG,開

發(fā)人員修改自己名單下的BUGo

正式運(yùn)行

兩星期后，一般視情況，問題的多和少來決定試運(yùn)行的時(shí)

間。在試運(yùn)行沒有什么大問題后，進(jìn)入正式運(yùn)行階段。全權(quán)

交與運(yùn)營部接管。正式運(yùn)行后，如果有什么問題或建議，則

由運(yùn)營部填寫《需求變更申請跟蹤單》，按照任務(wù)處理流程

進(jìn)行處理。

5任務(wù)管理

5.1任務(wù)開發(fā)流程

任務(wù)開發(fā)流程圖

任務(wù)開發(fā)流程說明

注：接收的需求不包含頁面、圖片的調(diào)整。如有頁面、圖片

的調(diào)整直接轉(zhuǎn)網(wǎng)站設(shè)計(jì)部。

1.接收客服、運(yùn)營、市場策劃或技術(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ā)時(shí)間進(jìn)度。

需求內(nèi)容：如果有需要?jiǎng)t由相關(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)先級表

5.3任務(wù)進(jìn)度監(jiān)控和管理

任務(wù)會有許多個(gè)，并且是并發(fā)進(jìn)行的。每一個(gè)任務(wù)不可能指

定一個(gè)任務(wù)管理人。需要一個(gè)專人對任務(wù)進(jìn)行跟蹤和監(jiān)督，

并在任務(wù)出現(xiàn)異常時(shí)隨時(shí)向領(lǐng)導(dǎo)匯報(bào)。

白板展示管理法

將這個(gè)月的任務(wù)、優(yōu)先級、執(zhí)行人、時(shí)間、進(jìn)行狀態(tài)展示在

公司的公告欄上。任務(wù)進(jìn)度更新為每周五下午進(jìn)行一次更

新。如果該任務(wù)完成，也可當(dāng)即更新。周五更新后，任務(wù)執(zhí)

行人在周一時(shí)繼續(xù)按照任務(wù)進(jìn)度計(jì)劃來處理安排給自己的工

作。

5.4任務(wù)結(jié)束管理

任務(wù)結(jié)束標(biāo)準(zhǔn)

測試后，嚴(yán)重問題0個(gè)，一般嚴(yán)重問題「3個(gè)。

測試通過上線后，由運(yùn)營部接管。上線后先試運(yùn)行一段時(shí)

間，如果有問題，運(yùn)營直接反饋給技術(shù)部的相關(guān)人員進(jìn)行修

改。試運(yùn)行沒問題后轉(zhuǎn)入正式運(yùn)行。

附錄

相關(guān)文檔模板：需求申請跟蹤單項(xiàng)目建議書項(xiàng)目計(jì)劃

用戶需求說明書需求規(guī)格說明書

客服問題記錄跟蹤單

項(xiàng)目團(tuán)隊(duì)組建的基本原則

①根據(jù)項(xiàng)目范圍和預(yù)算確定團(tuán)隊(duì)的人數(shù)

項(xiàng)目初始階段，項(xiàng)目經(jīng)理也許只了解到一些有關(guān)項(xiàng)目范圍、

交貨期限方面的信息以及客戶對一些功能需求的簡單描述。

為了對項(xiàng)目人力進(jìn)行估計(jì)，有必要進(jìn)一步細(xì)化項(xiàng)目范圍。

?首先在企業(yè)內(nèi)部爭取到一個(gè)比較得力的助手，他可能是項(xiàng)

目未來的開發(fā)經(jīng)理、系統(tǒng)分析員或高級程序員。這一點(diǎn)很重

要，既然你的項(xiàng)目組一定會有其他人的參與，與其到外面去

招，不如在內(nèi)部找你熟悉和信賴的同事加盟。因?yàn)槟悴粌H了

解他們的能力，而且作為老員工，他們的穩(wěn)定性也相對有保

障，更重要的是，項(xiàng)目一開始你就不再是孤軍奮戰(zhàn)，至少有

一個(gè)得力的助手和你一起討論，分擔(dān)你的工作壓力。經(jīng)驗(yàn)表

明，在有人一起討論的情況下，工作的積極性、決策的準(zhǔn)確

度等通常都會提高。

?下一步就是和他一起花一些時(shí)間與客戶溝通，把手頭上的

項(xiàng)目范圍和功能需求描述盡可能再細(xì)化一些，包括每個(gè)功能

需求都有哪些子需求，這些需求是如何配合形成一個(gè)業(yè)務(wù)鏈

的。有哪些系統(tǒng)數(shù)據(jù)需要維護(hù)，有多少張報(bào)表要出，哪些需

求是要優(yōu)先完成的，系統(tǒng)需要實(shí)現(xiàn)的業(yè)務(wù)有多復(fù)雜，哪些外

圍系統(tǒng)和當(dāng)前系統(tǒng)有關(guān)系，是否有數(shù)據(jù)接口和數(shù)據(jù)轉(zhuǎn)換方面

的需求等等。

?把細(xì)化后的項(xiàng)目范圍錄入項(xiàng)目管理系統(tǒng)（推薦使用MS

Project）,根據(jù)客戶要求的優(yōu)先級把項(xiàng)目劃分成若干階段，

每個(gè)階段提交一部分功能并預(yù)留一些風(fēng)險(xiǎn)準(zhǔn)備時(shí)間，根據(jù)需

要加上需求分析、系統(tǒng)設(shè)計(jì)、編碼、測試以及項(xiàng)目管理等方

面的活動(dòng)。

?對其中的任務(wù)，找實(shí)現(xiàn)技術(shù)相近的已完成的項(xiàng)目進(jìn)行對

照，估算出每個(gè)任務(wù)大致需要的man-day數(shù)，然后參考以下

方法粗略估計(jì)出項(xiàng)目需要的人數(shù)。

人數(shù)=man-day總數(shù)/（距交貨期限的工作日數(shù)X工作效率）

其中工作效率指的是日有效工作時(shí)間與日總工作時(shí)間的比

值。

例如：企業(yè)采取8小時(shí)工作制，組員可能只有6?7小時(shí)真正

投入到工作中，有1?2個(gè)小時(shí)可能會心不在焉，四處走動(dòng)或

處理一些私事，那么工作效率就介于6/8=0.75和7/8=0.875

之間，根據(jù)經(jīng)驗(yàn)一般取0.8比較合理。

Y提示

★估算某一任務(wù)的man-day數(shù)時(shí)，最好兩個(gè)人獨(dú)立估算，然

后再進(jìn)行比對，差距較大時(shí)，聽一聽對方的考慮，再得出結(jié)

論。

★估算某一任務(wù)的man-day數(shù)時(shí)，估算人應(yīng)該依據(jù)目標(biāo)角色

的平均水準(zhǔn)而不是他自己的能力標(biāo)準(zhǔn)來進(jìn)行估算（除非該項(xiàng)

任務(wù)就是由他本人負(fù)責(zé)的）。

★成熟的IT企業(yè)一般建有項(xiàng)目資源庫，也會提供一些標(biāo)準(zhǔn)

的經(jīng)驗(yàn)統(tǒng)計(jì)值，這些都是很好的參考，但還是建議和對照項(xiàng)

目的負(fù)責(zé)