項目計劃技巧研究論文

導語：項目計劃技巧研究論文一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

做項目計劃，如同給一個待出生的嬰兒寫傳記那樣困難。如果允許項目結束后再寫計劃，那就輕松多了，并且可以100%地準確。

在做軟件的項目計劃時，應屏棄一切浮夸作風。只有“知已知彼”才能做出合理的項目計劃。這里“知彼”是指要了解項目的規模、難度與時間限制。“知已”是指要了解有多少可用資源，如可調用的程序員有幾個？他們的水平如何？軟硬件設施如何？

1知己知彼

首先要了解項目的規模、難度與時間限制，才可以確定應該投入多少人力、物力去做這個項目。在可行性分析階段就要考慮這個問題。但不幸的是，人們在陷入項目不能自撥之前總難以準確地估計項目的規模與難度。這里經驗起到了最重要的作用。

項目的時間限制有兩類。第一類，項目應該完成的日期寫在合同中，如果延期了，則開發方要作出相應的賠償。第二類是開發自己的軟件產品，雖然只確定了該產品大致的發行日期并允許有延誤，但如果拖延太久則會失去商機造成損失。

項目的資源分為三類：“人”、“可復用的軟構件”和“軟硬件環境”。

（1）人是最有價值的資源。項目計劃的制定者要確定開發人員的名單，要根據他們的專長進行分工。

（2）可復用的軟構件是次有價值的資源。復用軟構件可提高軟件的質量與生產率。軟構件并非一定要用自己的，可以向專業的軟件供應商購買。

（3）軟硬件環境雖然不是最重要的資源，卻是必需的資源。原則上軟硬件環境只要符合項目的開發要求即可。有些項目可能要用到特殊的設備，則要事先作好準備，以免用時找不到而擔擱了進程。

2進度安排

有一位程序員忙著編寫程序，經理問他還需要多久才能完成。

“明天就可以完成。”程序員立即回答。

“我想這是不切實際的，實話實說，到底還要多少時間？”經理說。

“我還想加進一些新的功能，這需要花兩個星期。”程序員想了一會兒說。

“即使這樣也期望過高了，只要你編完程序時告訴我一聲，我也就滿足了。”經理說。

幾年以后，經理要退休了。在他去退休午餐會時，發現那位程序員正趴在機器旁睡覺：可憐的家伙整個晚上都在忙于編寫那個程序。[James1999]

程序員也期望每天早晨能在7：00準時起床，可老是一覺醒來就到中午了。項目落后于進度表乃是家常便飯，不必大驚小怪。以下一些事件經常會導致項目被延誤：

（1）上級領導主管臆斷，制定了不現實的期限。項目經理與程序員們被迫按照不合理的進度表開展工作。

（2）客戶的需求發生了變化，但沒有對進度表作出相應的修改。

（3）低估了項目的規模與難度，導致投入的人力和物力不足。

（4）并未預見到存在難以克服的技術障礙。

（5）并未預見到開發人員會發生問題，如生病，辭職等等。

（6）開發人員之間不能很好的交流、協作，導致各階段任務難以如期完成。

所以寫進程表不能象小學生寫決心書那樣充滿幻想。以下是一些有益的建議：

（1）制定進度表的人最好就是項目負責人，他最了解項目和開發人員。進度表要經過開發小組的討論，在得到大部數人的支持后才能實施。避免出現一廂情愿的局面。

（2）進度安排并不見得一定要符合邏輯順序。應盡可能地先做技術難度高的事，后做難度低的事。也就是辛苦在前，輕松在后。

小時候我對一位老先生吃飯很感興趣：他總是先把一大盒的米飯吃光了，然后再幸福地品嘗一小盒菜。父母告訴我這是中國的傳統美德，叫“先苦后甜”。從此我銘記在心，按此道理去學習和工作。可如今在飯店里，人們總是先把菜吃完了，最后才吃點米飯。天哪，生活真是太復雜了，我究竟該“先吃飯”還是“先吃菜”？

（3）開發一個大的軟件項目，應該將進度表分為若干個里程碑。一個里程碑之內的多個任務可以同步進行。程序員極容易沉迷于技術，要么樂不思蜀，要么焦頭爛額。里程碑就象心靈的燈塔，使忙碌的人群不混亂，不迷失方向。

（4）進度表中必須留有緩沖時間，并將緩沖時間用到不確定的事情上。因為人們對即將要做的事情知之甚少，所以要留一些時間以防不測。Microsoft公司的一些開發小組甚至制定了“50%緩沖規則”[Cusumano1996].對許多項目經理而言，容忍進度表中存在緩沖時間，不啻為觀念上的一個飛躍。

（5）如果發現項目應交付的期限非常不合理，就要跟領導或跟客戶據理力爭，請求放寬期限、調整進度。當客戶的需求發生變化時，就要對進度表作出相應的修正。不要覺得修改進度表很困難很麻煩，不修改才會產生真真的麻煩。很多人認為戒煙很困難，但馬克。吐溫曾說：“戒煙很容易，我一年就戒幾十次。”