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