項(xiàng)目管理技法
作者: 來源: 文字大小:[大][中][小]
軟件開發(fā)項(xiàng)目管理智囊機(jī)構(gòu)：項(xiàng)目管理室
軟件開發(fā)項(xiàng)目管理是軟件開發(fā)領(lǐng)域的專業(yè)性項(xiàng)目管理活動(dòng)，其成敗關(guān)系到整個(gè)項(xiàng)目的成敗，并影響到企業(yè)整體的商譽(yù)、市場(chǎng)和盈利能力。所以，軟件企業(yè)需要關(guān)注項(xiàng)目管理能力的提升。而實(shí)現(xiàn)這一目的的重要途徑之一就是設(shè)立項(xiàng)目管理智囊機(jī)構(gòu)，通過積聚整個(gè)企業(yè)的項(xiàng)目管理專業(yè)知識(shí)、專業(yè)經(jīng)驗(yàn)和專業(yè)人才來確保項(xiàng)目管理的成功。如果軟件企業(yè)出現(xiàn)如下項(xiàng)目管理癥狀，就可以考慮采用項(xiàng)目管理智囊機(jī)構(gòu)。
目管理中總是重復(fù)相同的失敗事件，項(xiàng)目管理專業(yè)技能沒有得到積累；
項(xiàng)目管理的績(jī)效因?yàn)轫?xiàng)目管理者個(gè)人的改變而出現(xiàn)很大的差異；
針對(duì)項(xiàng)目的質(zhì)量、進(jìn)度和成本等事項(xiàng)的估算沒有適當(dāng)?shù)呐袛鄻?biāo)準(zhǔn)；
企業(yè)內(nèi)各個(gè)項(xiàng)目的管理方法各自不同，沒有統(tǒng)一的標(biāo)準(zhǔn)和體系；
每個(gè)項(xiàng)目正式啟動(dòng)之前，都不得不進(jìn)行進(jìn)行相同的說明和培訓(xùn)；
項(xiàng)目管理者之間的項(xiàng)目管理相關(guān)知識(shí)沒有得到有效溝通和共享……
項(xiàng)目管理智囊機(jī)構(gòu)主要是指項(xiàng)目管理室(project management office)，這是企業(yè)項(xiàng)目管理的智囊機(jī)構(gòu)，與項(xiàng)目組(project team)不同：項(xiàng)目管理室對(duì)企業(yè)內(nèi)項(xiàng)目的一般管理手法負(fù)責(zé)，但是只對(duì)各項(xiàng)目提供管理支援；而項(xiàng)目組需要對(duì)項(xiàng)目的運(yùn)營和損益負(fù)責(zé)。具體而言，項(xiàng)目管理室的主要職責(zé)在于：其一，項(xiàng)目管理標(biāo)準(zhǔn)統(tǒng)合，主要包括項(xiàng)目作業(yè)流程、項(xiàng)目作業(yè)進(jìn)度、項(xiàng)目作業(yè)質(zhì)量、項(xiàng)目作業(yè)成本、項(xiàng)目作業(yè)效率等事項(xiàng)的標(biāo)準(zhǔn)統(tǒng)一；其二，項(xiàng)目管理咨詢支援，項(xiàng)目管理室成員通過其豐富的項(xiàng)目管理經(jīng)驗(yàn)和項(xiàng)目管理資料為項(xiàng)目管理提供問題解決方案、問題預(yù)防方法以及各種項(xiàng)目管理技能；其三，項(xiàng)目管理控制支援，主要包括：作為項(xiàng)目之間的協(xié)調(diào)者，促進(jìn)項(xiàng)目資源的合理分配；作為項(xiàng)目管理的監(jiān)督者，預(yù)測(cè)并監(jiān)控各項(xiàng)目存在的各種風(fēng)險(xiǎn)并加以解決；其四，項(xiàng)目管理人才培訓(xùn)，通過有計(jì)劃的持續(xù)的系統(tǒng)的項(xiàng)目管理培訓(xùn)體系為企業(yè)的發(fā)展提供項(xiàng)目管理培訓(xùn)服務(wù)，并從企業(yè)內(nèi)外尋找優(yōu)秀的項(xiàng)目管理者，確保企業(yè)擁有足夠的項(xiàng)目管理人力資源。
NTT數(shù)據(jù)株式會(huì)社在PMO的實(shí)施方面就是一個(gè)典型。NTT數(shù)據(jù)為了確保企業(yè)項(xiàng)目管理者的質(zhì)量和數(shù)量，在品質(zhì)保證部?jī)?nèi)設(shè)立“項(xiàng)目管理推進(jìn)室”作為項(xiàng)目管理的推進(jìn)組織，重點(diǎn)從3個(gè)方面來解決項(xiàng)目管理問題：其一，導(dǎo)入“PM企業(yè)內(nèi)資格認(rèn)證制度”，就是根據(jù)綜合了PMBOK、IT技能標(biāo)準(zhǔn)(IT skill standard)以及NTT數(shù)據(jù)自身擁有的PM專業(yè)知識(shí)等內(nèi)容的《PM能力基準(zhǔn)》，以企業(yè)內(nèi)資格的形式確認(rèn)擁有項(xiàng)目管理技能的人才的價(jià)值，提高PM的存在感和價(jià)值感；其二，PM職位的明確化，PM職位不僅包括最高層次的項(xiàng)目經(jīng)理，還包括小組長(zhǎng)以及小隊(duì)長(zhǎng)，形成階段性的職務(wù)進(jìn)階機(jī)制；其三，PM培訓(xùn)體制的完善，就是確立共享和繼承NTT數(shù)據(jù)所擁有的PM專業(yè)知識(shí)的機(jī)制，以及完善促進(jìn)研究學(xué)習(xí)的培訓(xùn)措施。NTT數(shù)據(jù)為了進(jìn)一步展開“強(qiáng)化SI業(yè)務(wù)競(jìng)爭(zhēng)力”這一重點(diǎn)經(jīng)營方針，以及改善開發(fā)過程和提高項(xiàng)目管理能力，于2003年11月設(shè)立“SI競(jìng)爭(zhēng)力本部”，并在“SI競(jìng)爭(zhēng)力本部”內(nèi)設(shè)立項(xiàng)目管理室PMO，以期為項(xiàng)目管理者提供實(shí)務(wù)性支援，強(qiáng)化組織性的項(xiàng)目管理能力，以此開展整個(gè)企業(yè)的過程改善活動(dòng)和項(xiàng)目管理活動(dòng)。NTT數(shù)據(jù)還于2004年1月成立全資子公司NTT數(shù)據(jù)PMO株式會(huì)社(NTT DATA PMO CORPORATION)，這是集中了NTT數(shù)據(jù)項(xiàng)目管理專業(yè)知識(shí)的專家集團(tuán)，由NTT數(shù)據(jù)中擁有豐富的系統(tǒng)開發(fā)經(jīng)驗(yàn)和很強(qiáng)的項(xiàng)目管理能力的專業(yè)人員組成，專門為項(xiàng)目管理知識(shí)不足的項(xiàng)目提供管理專業(yè)知識(shí)、調(diào)查、研究、教育培訓(xùn)和咨詢服務(wù)。最初以NTT數(shù)據(jù)本身的開發(fā)項(xiàng)目為目標(biāo)開展活動(dòng)，此后將逐漸擴(kuò)大到NTT數(shù)據(jù)集團(tuán)的所有企業(yè)。軟件開發(fā)項(xiàng)目管理常用技術(shù)：效能推動(dòng)器
一般項(xiàng)目管理的常用技術(shù)在軟件開發(fā)項(xiàng)目管理中同樣具有價(jià)值，是項(xiàng)目管理的效能推動(dòng)器。這些技術(shù)主要包括工作分解結(jié)構(gòu)、里程碑、關(guān)鍵路徑法、計(jì)劃評(píng)審技術(shù)、S曲線、掙值管理、目標(biāo)管理、責(zé)任矩陣、資源需求直方圖、圖表化、頭腦風(fēng)暴法、KJ法、蒙托卡羅模擬法、檢查清單/模板、基礎(chǔ)統(tǒng)計(jì)技術(shù)等。
工作分解結(jié)構(gòu)
工作結(jié)構(gòu)分解(WBS：work breakdown structure)是將項(xiàng)目完成之前的所有必要作業(yè)項(xiàng)目從上到下層次性羅列出來。WBS是項(xiàng)目管理的起點(diǎn)，WBS的設(shè)計(jì)可以說是項(xiàng)目管理的最重要工具。項(xiàng)目管理的第一步是項(xiàng)目范圍定義，明確項(xiàng)目的交付物，進(jìn)而定義項(xiàng)目需要進(jìn)行的活動(dòng)、角色、責(zé)任以及項(xiàng)目組的結(jié)構(gòu)。項(xiàng)目范圍定義可以使用WBS，將項(xiàng)目的“交付物”自上而下逐層分解成易于管理的若干元素，組成一個(gè)樹狀圖。WBS每細(xì)分一層都是對(duì)項(xiàng)目元素更細(xì)致的描述，細(xì)分的元素稱為工作細(xì)目，其中最低層的工作細(xì)目即樹狀圖的葉節(jié)點(diǎn)叫作工作包，工作包定義了需要達(dá)成的性能、質(zhì)量、日程和成本。為了便于分層統(tǒng)計(jì)和識(shí)別，WBS中的每個(gè)元素都被指定一個(gè)惟一的標(biāo)識(shí)符，并分層表示。制作WBS的注意點(diǎn)是：不是以現(xiàn)存組織為基準(zhǔn)進(jìn)行作業(yè)分解，而是以“做什么”為基礎(chǔ)，從零開始進(jìn)行作業(yè)分解；不是項(xiàng)目管理者一個(gè)人單獨(dú)制作，而是項(xiàng)目組成員共同制作；WBS的任意層次的要素都需要具有(1)工作范圍明確、(2)日程確定、(3)具有成本計(jì)劃(預(yù)算)、(4)資源已經(jīng)分配、(5)具有業(yè)績(jī)測(cè)評(píng)尺度、(6)組織責(zé)任明確等特征。
計(jì)劃評(píng)審技術(shù)
計(jì)劃評(píng)審技術(shù)(PERT：program evaluation review technique)是用網(wǎng)絡(luò)圖來表達(dá)項(xiàng)目中各項(xiàng)活動(dòng)的進(jìn)度和他們之間的相互關(guān)系，并在此基礎(chǔ)上進(jìn)行網(wǎng)絡(luò)分析，確定關(guān)鍵活動(dòng)與丶?/span>路線，利用時(shí)差不斷地調(diào)整與優(yōu)化網(wǎng)絡(luò)，以求得最短周期。然后，還可將成本與資源問題考慮進(jìn)去，以求得綜合優(yōu)化的項(xiàng)目計(jì)劃方案。PERT可以表現(xiàn)出工作包或者活動(dòng)、擔(dān)當(dāng)者、交期、日程以及各活動(dòng)之間的依存關(guān)系等等。PERT與WBS相互關(guān)聯(lián)和支援，使用PERT有賴于WBS的完成，但是PERT的制作又可以發(fā)現(xiàn)WBS的遺漏。PERT著眼于項(xiàng)目管理者應(yīng)該考量的“質(zhì)量、成本、交期(QCD)”，是質(zhì)量最佳化、成本最小化、交期最短化的分析工具。PERT不拘泥于細(xì)枝末節(jié)，而是著眼于發(fā)現(xiàn)將來要直面的重要課題和問題點(diǎn)，從能否實(shí)現(xiàn)項(xiàng)目目標(biāo)而不是各工作包的角度進(jìn)行分析。首先從微觀角度制作PERT，在考量各工作包的重要性以及相關(guān)性的基礎(chǔ)上著眼于QCD相關(guān)內(nèi)容：里程碑的設(shè)定；項(xiàng)目風(fēng)險(xiǎn)的挖掘；項(xiàng)目瓶頸的抽出；人、財(cái)、物、信息、時(shí)間等項(xiàng)目資源的最佳分配；項(xiàng)目成員的最佳配置；工作包與活動(dòng)的統(tǒng)合；工作包與活動(dòng)的分解；現(xiàn)有資源的靈活運(yùn)用；工作包之間、團(tuán)隊(duì)成員之間的整體效果的分析；最短路線、重要路線等關(guān)鍵路線的確定；活動(dòng)順序的妥當(dāng)性。
掙值管理
掙值管理(EVM：earned value management)是綜合項(xiàng)目范圍、進(jìn)度計(jì)劃和項(xiàng)目資源，測(cè)量項(xiàng)目績(jī)效的一種方法。掙值管理通過比較計(jì)劃工作量、實(shí)際掙得多少與實(shí)際花費(fèi)成本，決定成本和績(jī)效是否符合原定計(jì)劃。掙值管理將計(jì)劃與掙值換算為成本，并通過與達(dá)成實(shí)績(jī)所用實(shí)際成本的比較來對(duì)項(xiàng)目的實(shí)績(jī)進(jìn)行度量和分析，可以說是成本與進(jìn)度的統(tǒng)合控制管理工具。掙值管理也離不開偏差管理。
在項(xiàng)目過程中，通過監(jiān)視成本差異和進(jìn)度差異以及成本效率指數(shù)、進(jìn)度效率指數(shù)的變動(dòng)，預(yù)測(cè)超過成本和進(jìn)度滯后的情況后采取對(duì)策。在分析計(jì)劃與實(shí)績(jī)差異的原因及對(duì)策時(shí)，可以使用圖表化、頭腦風(fēng)暴法+KJ法。如果計(jì)劃與實(shí)績(jī)差異過大，就應(yīng)該考慮縮小項(xiàng)目范圍等對(duì)策。
頭腦風(fēng)暴＋KJ法
頭腦風(fēng)暴(brain storming)和KJ法都是發(fā)現(xiàn)問題和解決問題行動(dòng)中實(shí)施創(chuàng)造性開發(fā)的方式。
頭腦風(fēng)暴法又叫作集思廣益法，它通過創(chuàng)造一個(gè)無批評(píng)的自由的會(huì)議環(huán)境，使與會(huì)者暢所欲言、充分交流、互相啟迪，產(chǎn)生大量創(chuàng)造性的意見，其目的是利用組合腦力刺激創(chuàng)造性，想出更多更好的主意。其作用在于：打破思維定勢(shì)，鼓勵(lì)開放性的思考；發(fā)揮集體智慧，在他人的看法上建立自己的意見；打破溝通障礙，形成團(tuán)隊(duì)精神；防止少數(shù)人控制會(huì)議。其實(shí)施步驟如下：(1)將頭腦風(fēng)暴的中心議題寫在白板、膠片或掛圖上，確保每個(gè)人都充分理解中心議題的含義。(2)項(xiàng)目組成員輪流發(fā)言，任何意見都會(huì)得到肯定。輪流的過程鼓勵(lì)大家參與，但任何人如果沒想好則發(fā)言可以隨時(shí)跳過。(3)將每一條意見用大號(hào)字寫在膠片或掛圖上。用原話記錄每條意見，不作任何解釋。(4)繼續(xù)輪流發(fā)言，直到每個(gè)人都沒有意見為止。(5)復(fù)查意見記錄，去除完全重復(fù)的條目。小心識(shí)別并保留在用詞上有極細(xì)微差別的意見。頭腦風(fēng)暴法對(duì)于認(rèn)識(shí)現(xiàn)狀、整理問題、討論問題過程中挖掘參與人員的意見非常有效。在PMBOK所謂范圍、成本、質(zhì)量、溝通、風(fēng)險(xiǎn)等知識(shí)領(lǐng)域的管理中比較有效。
在問題并不明朗的情況下通過KJ法可以使問題逐漸清晰起來。所以，在軟件開發(fā)過程中，多用于需求分析、業(yè)務(wù)分析等。在項(xiàng)目計(jì)劃階段，對(duì)于PMBOK所謂風(fēng)險(xiǎn)管理知識(shí)領(lǐng)域中的風(fēng)險(xiǎn)識(shí)別、對(duì)策立案等方面比較有效。但是，如果理解KJ法的成員比較少，其使用會(huì)比較困難。特地集中起來的創(chuàng)意和意見如果僅僅簡(jiǎn)單加以分類，就難以引出問題點(diǎn)和創(chuàng)意點(diǎn)。
檢查清單/模板
在項(xiàng)目執(zhí)行期間，可以由項(xiàng)目管理團(tuán)隊(duì)作成檢查清單或者模板(checklist/template)，也可以由項(xiàng)目管理室那樣的支持項(xiàng)目管理的組織在項(xiàng)目審查和監(jiān)督的成功案例和失敗案例的基礎(chǔ)上作成。檢查清單或者模板是組織的最佳實(shí)踐，通過這些經(jīng)驗(yàn)的積累可以提高項(xiàng)目管理的效率，有助于防止失敗。檢查清單用于確認(rèn)作業(yè)或工程是否存在遺漏。模板作為產(chǎn)出物的雛形式樣，具有WBS、網(wǎng)絡(luò)圖、需求變更書、進(jìn)展報(bào)告書、合同標(biāo)準(zhǔn)文件等形式。通過雛形的靈活運(yùn)用，經(jīng)驗(yàn)較淺的項(xiàng)目管理者可以明白必須做些什么，并能在其他項(xiàng)目中重復(fù)利用。
軟件開發(fā)項(xiàng)目管理檢查清單：天氣晴雨表
檢查清單用于確認(rèn)作業(yè)或工程是否存在遺漏，是反映項(xiàng)目管理是否存在問題的“天氣晴雨表”。下面是軟件開發(fā)項(xiàng)目管理的一個(gè)檢查清單，比本章中所言“軟件開發(fā)項(xiàng)目管理過程中的禍根及其后果”更加詳細(xì)。通過這個(gè)清單，可以發(fā)現(xiàn)項(xiàng)目管理存在的問題，并采取措施加以改善。
需求式樣晴雨表
是否存在穩(wěn)定的、完整的、書面的需求式樣？
是否已經(jīng)就需求事項(xiàng)煞費(fèi)苦心地與顧客進(jìn)行了溝通和確認(rèn)？
是否存在需求式樣尚未確定就以“暫定式樣”開始作業(yè)而事后返工的情況？
是否為了確認(rèn)顧客的需求而對(duì)“需求式樣書”進(jìn)行了審查？
是否根據(jù)顧客提供的產(chǎn)品式樣書而直接進(jìn)入了設(shè)計(jì)作業(yè)？
是否在作業(yè)途中不斷變更或追加需求式樣？
是否按照項(xiàng)目編號(hào)規(guī)則對(duì)每項(xiàng)需求賦予了惟一的編號(hào)？
是否已經(jīng)明確顧客方的項(xiàng)目推進(jìn)體制以及最終決策者？
是否攝于顧客的特權(quán)優(yōu)位性而不經(jīng)討論地接受顧客的需求變更？
是否在遠(yuǎn)遠(yuǎn)超越自身能力而根本無法完成的情況下不能清楚地說“不”？
是否在作業(yè)已經(jīng)進(jìn)入測(cè)試階段后還發(fā)現(xiàn)需求式樣理解有誤？
是否以單一窗口接收顧客的需求，確保一窗口輸入？
項(xiàng)目組成員的作業(yè)是否基于最新需求信息，而不是已經(jīng)失效的歷史信息？
項(xiàng)目計(jì)劃晴雨表
是否將估算視為一種特殊的技能，并將估算當(dāng)作一個(gè)小項(xiàng)目？
是否定期對(duì)項(xiàng)目計(jì)劃實(shí)施重新估算并根據(jù)實(shí)際情況加以調(diào)整？
是否對(duì)作業(yè)文檔等成果物的“量”進(jìn)行了估計(jì)？
是否以適當(dāng)?shù)膯挝贿M(jìn)行了作業(yè)量的估計(jì)？
項(xiàng)目作業(yè)是否具有詳細(xì)的日程表？
日程表確定之后，如果和實(shí)際情況出入較大，是否進(jìn)行了調(diào)整？
是否接受了不切實(shí)際的開發(fā)日程，而其結(jié)果是，日程表僅僅成為一種形式？
“工作量”和“難易度”是否會(huì)因?yàn)閾?dān)當(dāng)者的不同而出現(xiàn)巨大變動(dòng)？
是否因?yàn)閷?shí)際進(jìn)展超前于計(jì)劃而沒有思考項(xiàng)目計(jì)劃本身存在的精度問題？
團(tuán)隊(duì)管理晴雨表
是否存在明確的軟件開發(fā)行動(dòng)單位：團(tuán)隊(duì)？
是否雖然叫作團(tuán)隊(duì)，但是并沒有認(rèn)識(shí)到協(xié)作而是專注于工作任務(wù)的分擔(dān)？
管理者是否仍然承擔(dān)以前作為技術(shù)者所承擔(dān)的具體開發(fā)作業(yè)任務(wù)？
項(xiàng)目管理者是否僅僅根據(jù)自己的經(jīng)驗(yàn)而將需求式樣直接分派給“個(gè)人”？
項(xiàng)目管理者是否總是認(rèn)為項(xiàng)目沒有什么值得注意的問題？
團(tuán)隊(duì)成員是否知道項(xiàng)目作業(yè)內(nèi)容的相互關(guān)系及其優(yōu)先級(jí)？
是否在項(xiàng)目啟動(dòng)之后仍然還有項(xiàng)目組成員感到無所事事？
是否經(jīng)常有特定的項(xiàng)目組成員總是加班到深夜？
團(tuán)隊(duì)成員是否知道并遵守統(tǒng)一的作業(yè)規(guī)范？
是否從作業(yè)流程上、從團(tuán)隊(duì)協(xié)作上追究過程序缺陷的真正原因？
團(tuán)隊(duì)成員是否在相互察看成果物后產(chǎn)生提高自己的作業(yè)水平的意識(shí)？
當(dāng)問題難點(diǎn)解決之后，是否向項(xiàng)目組成員介紹解決該問題的思維和方法？
項(xiàng)目組成員的出勤時(shí)間是否經(jīng)常相差很大而不尋找原因？
項(xiàng)目組成員在遇到技術(shù)難題時(shí)是否與項(xiàng)目組其他成員溝通并尋求支援？
項(xiàng)目組成員在討論問題時(shí)是否出現(xiàn)無條理的、非建設(shè)性的討論？
作業(yè)流程晴雨表
是否存在專注于組織整體的開發(fā)作業(yè)和項(xiàng)目流程的人或者小組？
是否存在項(xiàng)目開發(fā)作業(yè)的標(biāo)準(zhǔn)作業(yè)流程？
是否存在記述顧客需求式樣的文檔標(biāo)準(zhǔn)？
是否存在設(shè)計(jì)書的文檔標(biāo)準(zhǔn)？
是否不經(jīng)過設(shè)計(jì)階段而直接進(jìn)入編碼階段？
設(shè)計(jì)階段是否實(shí)施了以設(shè)計(jì)為對(duì)象的審查？
編碼階段是否實(shí)施了以代碼為對(duì)象的審查？
中途式樣變更后，是否未經(jīng)其影響范圍的分析就直接分配給擔(dān)當(dāng)者？
是否未經(jīng)單體測(cè)試就直接開始綜合測(cè)試？
是否時(shí)至最后才發(fā)現(xiàn)此前隱藏的諸多問題？
是否無視已經(jīng)發(fā)現(xiàn)的問題而繼續(xù)推進(jìn)作業(yè)？
是否多次重復(fù)出現(xiàn)以前相同的錯(cuò)誤而沒有吸取教訓(xùn)？
是否沒有專門的測(cè)試人員而在交付之前還是由開發(fā)者自己實(shí)施測(cè)試？
對(duì)式樣需求是否確立了適當(dāng)?shù)臏y(cè)試項(xiàng)目？
測(cè)試是否幾乎沒有自動(dòng)化手段？
過程改善方面是否存在可以商量和咨詢的人員？
是否鼓勵(lì)各開發(fā)小組寫作事后分析報(bào)告，至少能就項(xiàng)目進(jìn)程開會(huì)討論？
是否組織正式的活動(dòng)，就軟件開發(fā)與質(zhì)量控制流程的相關(guān)問題相互切磋？
項(xiàng)目配置晴雨表
是否在發(fā)現(xiàn)潛在的缺陷時(shí)難以確定其對(duì)現(xiàn)有模型的影響范圍？
是否只有擔(dān)當(dāng)者知道而沒有向所有成員公布缺陷的修正范圍和修正方法？
是否因?yàn)樾薷囊粋€(gè)程序缺陷而引發(fā)多個(gè)新的缺陷？
擔(dān)當(dāng)者是否能在任何時(shí)間對(duì)源程序做自由的變更？
開發(fā)期間是否定期對(duì)制作過程中的文件和程序進(jìn)行備份？
是否確立了資源備份在非常時(shí)期的因應(yīng)方式？
需求式樣書和設(shè)計(jì)書等正式文件是否存在“確認(rèn)”手續(xù)？
項(xiàng)目文檔是否一直保持最初的狀態(tài)，即使在式樣變更后仍然沒有變化？
是否在項(xiàng)目后期難以想起中途式樣變更的“理由”？
對(duì)于程序缺陷和式樣變更，是否能追蹤其修改點(diǎn)？
對(duì)于開發(fā)環(huán)境目錄中的舊代碼是否難以判斷其能否刪除？
開發(fā)文檔是否會(huì)出現(xiàn)鏈接到舊版本的情況？
教育培訓(xùn)晴雨表
是否描繪出現(xiàn)在的開發(fā)組織多年后的“風(fēng)姿”？
在組織上，是否對(duì)現(xiàn)在的人員實(shí)施技術(shù)性教育和培訓(xùn)？
是否確立了員工教育培訓(xùn)的計(jì)劃和目標(biāo)？
是否將技術(shù)學(xué)習(xí)視為個(gè)人任務(wù)而沒有組織上的“方向”？
項(xiàng)目開發(fā)人員所持有的軟件開發(fā)文獻(xiàn)的平均數(shù)量是否在1冊(cè)以下？
項(xiàng)目作業(yè)休息時(shí)間是否毫不涉及嶄新技術(shù)方面的話題？
項(xiàng)目組成員是否不知道軟件工程的意思？
是否不了解“凝聚度”、“結(jié)合度”等詞匯的意思？
是否難以說出5個(gè)以上的軟件質(zhì)量特性及其副特性？
項(xiàng)目審查晴雨表
參與者是否了解審查的整體流程？
是否帶著目的而非盲目地實(shí)施審查作業(yè)？
是否僅僅局限于代碼審查而不顧及其他？
審查者是否只關(guān)注形式而非實(shí)質(zhì)？
是否明確審查對(duì)象物，針對(duì)“物”而非“人”？
是否記錄審查結(jié)果并追蹤缺陷修正結(jié)果？
是否將審查的反饋結(jié)果導(dǎo)入下一項(xiàng)目中？
審查會(huì)議是否演化成為問題解決會(huì)議？
其他
是否采取了數(shù)據(jù)備份以及病毒防范等措施？
對(duì)電子郵件的應(yīng)對(duì)是否總是滯后？
是否感到電子郵件的應(yīng)對(duì)很繁瑣？