【正文】 、可擴(kuò)展性角度考察代碼的質(zhì)量，提出修改建議。盡量降低變更帶來的風(fēng)險(xiǎn)。相關(guān)人員接收到確認(rèn)的需求變更后，做以下事情。范圍蔓延以及需求變更在有了明確的目標(biāo)和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務(wù)部門在看到具體系統(tǒng)的真實(shí)雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對(duì)此加以控制，新的需求的加入通常會(huì)影響已實(shí)現(xiàn)的需求，并且對(duì)項(xiàng)目進(jìn)度和成本產(chǎn)生很大的影響。要建立一套大家認(rèn)可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，code review時(shí)嚴(yán)格考核。這是一個(gè)團(tuán)隊(duì)的軟實(shí)力，團(tuán)隊(duì)之間的協(xié)作好壞也將是個(gè)潛在的風(fēng)險(xiǎn)問題，在項(xiàng)目啟動(dòng)和團(tuán)隊(duì)組建的時(shí)候就應(yīng)該加以規(guī)避這樣的風(fēng)險(xiǎn)出現(xiàn)。首先看看不成功的會(huì)議常常表現(xiàn)為哪些形式：會(huì)議氛圍不好，參與者發(fā)言不踴躍；會(huì)議討論常常偏離主題；會(huì)議沒有取得預(yù)期的結(jié)果；會(huì)議時(shí)間常常一拖再拖。通常我建議有幾點(diǎn)要在開場(chǎng)時(shí)說： A、再一次強(qiáng)調(diào)會(huì)議的目標(biāo)，我們來做什么。很多會(huì)議往往都不注意這一點(diǎn)。會(huì)議后別忘發(fā)會(huì)議紀(jì)要，以及一些Action，什么人什么時(shí)候做什么。在確保必要人物都在的情況下一次會(huì)議參與者越少效果越好。營(yíng)造良好的工作環(huán)境和氛圍。這樣的風(fēng)險(xiǎn)應(yīng)該在項(xiàng)目的前期階段就應(yīng)該解決在萌芽狀態(tài)來避免這樣的風(fēng)險(xiǎn)在后期或中期出現(xiàn)。如何提高開發(fā)人員開發(fā)的質(zhì)量？在制定項(xiàng)目計(jì)劃時(shí)，對(duì)開發(fā)時(shí)間的評(píng)估要盡可能的合適。風(fēng)險(xiǎn)引起的負(fù)面后果集中體現(xiàn)在進(jìn)度延后、成本超支、質(zhì)量不達(dá)標(biāo)等方面，導(dǎo)致這些問題的因素主要包括目標(biāo)以及需求不明確、范圍蔓延以及需求變更、代碼質(zhì)量或返工風(fēng)險(xiǎn)、人員技能和資源的不足、缺乏良好的團(tuán)隊(duì)協(xié)作等。其中以下人員對(duì)需求的變更是緊密相關(guān)的，他們必須知曉并認(rèn)可此需求變更。需求變更要必須被管理。出現(xiàn)這樣的薄弱環(huán)節(jié)，造成這樣的原因，我想也是有很多因素造成的；比如開發(fā)人員對(duì)需求不是很明確，以自己比較主觀的因素去完成任務(wù)的；還有對(duì)整個(gè)系統(tǒng)業(yè)務(wù)邏輯沒有正確的清晰的認(rèn)識(shí)的原因，以及對(duì)項(xiàng)目組成員培訓(xùn)不到位的原因等眾多因素糾集在一起才產(chǎn)生的。模塊分配和開發(fā)時(shí)間估算的步驟：在劃分好模塊后，首先自己先估算一下每個(gè)模塊所需要的開發(fā)時(shí)間。該階段完成后的成果：A、User Case(系統(tǒng)用例)；B、DEMO(系統(tǒng)原型)；C、系統(tǒng)設(shè)計(jì)文檔(概要設(shè)計(jì)和詳細(xì)設(shè)計(jì))；D、數(shù)據(jù)庫(kù)設(shè)計(jì)文檔。第一：目標(biāo)作為一個(gè)項(xiàng)目的管理者，必須要明確的知道自己的工作目標(biāo)；我個(gè)人認(rèn)為項(xiàng)目管理者的目標(biāo)無非就是以下兩點(diǎn)：就是清晰明確地了解項(xiàng)目利害關(guān)系者的需求和期望，努力做到滿足項(xiàng)目利害關(guān)系者的不同需求；項(xiàng)目利害關(guān)系者包括：項(xiàng)目團(tuán)隊(duì)成員和項(xiàng)目團(tuán)隊(duì)外成員(比如各部門的部門負(fù)責(zé)人和市場(chǎng)人員，客戶等)。項(xiàng)目啟動(dòng)會(huì)議，相關(guān)的利害關(guān)系人員都必須參加。開發(fā)人員的技術(shù)水平和對(duì)項(xiàng)目所在應(yīng)用的熟悉程度(包括對(duì)框架和應(yīng)用的熟悉程度)。對(duì)于那些差異比較大的，將與技術(shù)人員探討其中的緣由。如果通過以上步驟，還因?yàn)槭谴a編寫者的原因而出現(xiàn)嚴(yán)重的缺陷問題，將通過績(jī)效考核來加深代碼編寫者的印象，并在周報(bào)會(huì)議上做通報(bào)批評(píng)。項(xiàng)目管理者作為項(xiàng)目的負(fù)責(zé)人，對(duì)項(xiàng)目的成功與否負(fù)有主要的責(zé)任。在項(xiàng)目的實(shí)施過程中需要不斷地識(shí)別和應(yīng)對(duì)風(fēng)險(xiǎn)，并加以有效的控制，風(fēng)險(xiǎn)管理的好與壞直接影響項(xiàng)目的實(shí)施效果，從某種意義上講，項(xiàng)目實(shí)施對(duì)于項(xiàng)目管理者就是識(shí)別、分析、應(yīng)對(duì)、控制風(fēng)險(xiǎn)的過程，使項(xiàng)目的約束性目標(biāo)和質(zhì)量目標(biāo)朝有利的方向發(fā)展。在發(fā)生需求變更時(shí)，嚴(yán)格按照需求變更流程執(zhí)行。開發(fā)過程中遇到技術(shù)難題，導(dǎo)致開發(fā)時(shí)間延遲或者需求不得不發(fā)生變更。世界上只有完美的團(tuán)隊(duì)，沒有完美的個(gè)人。有時(shí)候兩三個(gè)人單獨(dú)小范圍溝通會(huì)更加有效。會(huì)議要有結(jié)論。需要做好版本的管理和控制。C、說明一下會(huì)議的規(guī)則。在列出最佳實(shí)踐之前有三點(diǎn)我們必須要清楚：會(huì)議是否會(huì)取得成功很大程度上取決于會(huì)議的組織者。 對(duì)不可預(yù)期的風(fēng)險(xiǎn)，項(xiàng)目管理者要有潛在的風(fēng)險(xiǎn)意識(shí)評(píng)估，做好一些可操作性的預(yù)案準(zhǔn)備。需求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質(zhì)量沒有達(dá)到用戶要求。需求變更風(fēng)險(xiǎn)：需求已經(jīng)打上了基線，但此后仍然有變更發(fā)生，對(duì)項(xiàng)目造成影響。開發(fā)人員修改代碼中的相關(guān)部分。將以User Case作為需求基準(zhǔn)線，在User Case確認(rèn)之后的任何需求改變，都需要走需求變更流程，這一環(huán)節(jié)我們基本沒有，期間有時(shí)候使的工作很混亂