淺談在國內做項目的一些心得及問題建議

崗位：

在項目的研發過程中，作為PM是整個團隊的一面旗幟，應該無時無刻保持高昂的斗志，激勵整個團隊，讓大伙感覺到一個整體的存在，共同進退。

在項目研發過程中，作為PM要維系好團隊內部和外部的關系，有的時候，為了保證團隊能獲取更多更加有效的信息，PM應該出去“和”，與外部的商務、產品打成一片，了解更多更加有效的信息。

作為PM的角色，無時無刻對事不對人，針對問題要勇于提出問題，勇于指出團隊的不足，同時不能煩躁，不應該因為一些小事就發火，而應該在任何時候保持良好的心態。

關心整個團隊，特別是一些新人，讓他們感覺到溫暖，感覺到團隊都會給予他們幫助，有目標，能學習到東西，有奮斗目標。定期開展培訓，布道，宣揚個人能力，讓團隊成員能需要更多知識。

作為一個協調者，在任何時候都應該明確自己的職責，就是為了能將項目順利結束掉，盡管項目進行過程中有這樣或者那樣的問題，在任何時候作為領導者都要頂住壓力，跟團隊成員一個輕松的環境，在任何時候都應該保持微笑，微笑面對團隊，微笑面對項目，微笑面對各種困難。只有這樣，才能讓團隊感覺到在一個戰壕里面戰斗，共進退，讓團隊更加團隊，彼此信任，彼此了解對方。

心得：

哪怕一個項目在實施的初期看上去再美好，也應該抽出時間來評估其難易程度，有哪些細節會給將來埋下定時炸彈？

出現問題而指責別人是沒有用的。即使是別人的錯，如果沒有解決方案，依然于事無補。

和客戶的合作中，有的時候會出現一些問題相互埋怨，在這個時候曾經的口頭承諾，口頭的契約變得一文不值，需要書面的會議紀要形式的記錄，有關于對此問題及解決方式的詳細討論。一定要遇事保持冷靜，工作就是工作，不要摻入個人的情感，任何時候都不要在相互關系看上去比較融洽的時候給予任何承諾。個人感情只能成為項目的潤滑劑，不能產生任何實質性的改變。

和客戶在一起，永遠都是工作，不管是和客戶的誰在一起吃飯，那都是工作的一部分而已。

做項目的過程中真的不能前松后緊，這個是有非常大的風險的，作為一個好的PM，恰恰應該在大家不緊張的時候給大家加壓，在大家緊張的時候給大家釋放壓力。

做項目如果對外發布的里程碑已經確認，應該確保在一周之前完成對Bug的修改，全力應對現場反饋回來的問題，一般有以下幾個嚴重制約版本的按時發布：1.系統的技術問題；2.CQ里面的Bug；3.現場反饋的問題。

項目不應該僅僅只盯著公司內部，如果能守住里程碑，就應該想盡一切法子守住里程碑，從技術和商務的角度來守。如果已經預判了里程碑無法達到，就應該想對策，如果實在沒有對策，就應該想解釋的理由，告知需求已經完成了，對于一些新增的問題，需要后續花時間來完成，這不是一兩下能完成的，同時也應該清晰描述出做了哪些努力，完成了哪些工作，后續還需要完成哪些工作，從哪些方面來進行努力。

問題及建議：

問題：

在項目初期，有的時候我們會為了利益而滿口答應客戶的某些任務。這些任務在項目的初期也許是不明確的，甚至是無關緊要的，但是在項目的中后期，隨著雙方對項目認識的加深，這個時候對這些功能的描述就會越來越清晰明了，可能會對項目的進度產生致命的影響，非常影響項目開發進度。

建議：

1.項目前期對項目所使用的框架仔細分析，分析不僅僅是看這個框架是否跑的通，最好能叫上測試對所選擇的框架進行功能和性能方面的測試，不盲目下結論。

2.PM布局，不單單完成手頭上的工作，而應該思考下一兩步，兩三步，甚至四五步的棋會怎么樣走。有了這樣的思考，才有可能對開展的工作有針對性地思考。

問題：

對項目組而言，沒有把“需求”和“Bug”區分清楚，用解決Bug的思維來應對需求變更，任務缺乏優先級，加班難以避免。

建議：

1.培養團隊對問題的考慮深度，不單單盯在某一個問題上，而要放在全局，考慮到自己的工作對整個項目的影響，對其他人的影響。

2.加強對現場人員的培訓，收集需求不是傳聲筒，對客戶的需求，要有正式的記錄，時間緊，客戶說了馬上就要，不是理由。堅決通過Q_List的方式來溝通。

問題：

在系統全面鋪開后，臨時對應現場的問題，出現了更多的Bug,通過加班，花了巨大的人力在開發上應對，在這件事情上我們缺乏一套有效的應急機制。

建議：

如果我們在出現問題的時候，在第一時間，只要一個人或者少數人就能夠對現場的問題進行應對，能在完成之后進行自動化測試，有了這種機制能在出現緊急狀況的情況下，由少數的人就能完成大量的工作。

我只是描述了自己的一些感受，每個人的心中都有一個自己的哈姆雷特。

來自：http://blog.csdn.net/mhfcr/article/details/18701907