???半年沒有更新這個博客了，心里有些慚愧，不過我去看了朋友的博客，有的甚至一年沒有更新了。我不禁想，更新博客也是需要毅力的，很多時候我們因?yàn)檫@樣的那樣的事情來回奔波、疲于奔命，漸漸冷落了曾經(jīng)熱戀的東西。就在此刻，又想起了那句話“很多人是被現(xiàn)實(shí)的擔(dān)子壓下來的”。

???廢話不是不能說，而是不能多說，進(jìn)入正題吧。從近期的項(xiàng)目管理過程中，總結(jié)了一些粗淺的經(jīng)驗(yàn)，在這里羅列一下：

?? 1）?項(xiàng)目周期估算
???項(xiàng)目周期估算的時候必須考慮幾個因素：項(xiàng)目成員的技術(shù)水平、職業(yè)的素養(yǎng)、被激勵的程度。如果沒有把握的話，應(yīng)該盡量悲觀的估計(jì)，方法是先估計(jì)正常的周期，然后乘一個系數(shù)。

?? 2）盡早QC（質(zhì)量檢查）
????很多時候，團(tuán)隊(duì)成員的技能水平往往達(dá)不到要求的目標(biāo)，那么，如果等到方案階段快要結(jié)束的時候再次檢查方案的質(zhì)量就太遲了，要么得到低劣粗糙基本不能用的概要設(shè)計(jì)，要不然準(zhǔn)備宣布方案階段延期。所以，在方案設(shè)計(jì)取得階段性成果的時候就應(yīng)該啟動QC，并且不斷QC，每一個關(guān)鍵的交付都應(yīng)該QC（通常需求分析報(bào)告、需求規(guī)格說明書、概要設(shè)計(jì)、代碼、測試案例、切換方案都需要QC）。

?? 3）輸出
???開發(fā)階段的輸出不僅僅是代碼，還有可能有性能優(yōu)化報(bào)告（針對性能需求）、配置說明（配置模塊），這些應(yīng)該明確的安排到WBS（工作分解結(jié)構(gòu)）中進(jìn)行跟蹤。

???4）模糊任務(wù)的跟蹤
???在接近階段切換的時候，有很多模糊的任務(wù)需要用CheckList跟蹤，比如切換到SIT（系統(tǒng)集成測試）階段時，就需要跟蹤設(shè)計(jì)評審意見的落實(shí)、代碼評審意見的落實(shí)情況，并且這個跟蹤應(yīng)該盡早，并提醒成員盡早反饋。

???5）明確的任務(wù)
???不要給項(xiàng)目成員分配模糊的任務(wù)，任何任務(wù)都要有明確的輸出，同樣的道理，文檔編寫任務(wù)應(yīng)該指定明確的模板。

???6）不可控時間的預(yù)留
???有很多進(jìn)度不能由PM把握，比如提交官方的TR（評審），就應(yīng)該預(yù)留充足的時間，以免對項(xiàng)目總體進(jìn)度產(chǎn)生惡劣影響。

???7）測試
???系統(tǒng)的測試計(jì)劃是必須的，測試一樣要用矩陣來進(jìn)行跟蹤，每個功能點(diǎn)、每個意外情況都要跟蹤起來。盲目的測試往往也可以發(fā)現(xiàn)問題，但更可能的遺漏掉更加重要的問題。

???8）工作日志
???不管項(xiàng)目成員做了什么，都應(yīng)該要求他們用工作日志記錄下來。這樣可以防止偷懶 :)

總結(jié)

以上是生活随笔為你收集整理的我的一些项目管理经验的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。