項目管理，這是一個很專業(yè)的領域，涉及的內(nèi)容非常廣泛，并且實踐操作過程是“多變”的，第一次接觸這個工作是在之前公司做廣東省電信IPTV-EPG項目 的時候，這也是第一次幫帶團隊，這也是偏技術方面的，涉及的內(nèi)容很少；主要是團隊召集、帶領團隊解決局方問題并且為團隊提供幫助以及和局方協(xié)調(diào)資源和工作 安排。結束這個項目后又轉到技術上了。不過中間也接觸了不少崗位（測試，文檔開發(fā)，美工，Java開發(fā)，Oracle等等），不過中間的一些隨著工作變化 也忘的差不多了。

在做了幾年的開發(fā)后，出了一個轉折點，又折騰到了項目管理這個崗位上。從開發(fā)到項目管理的轉換說起來相對會簡單，項目管理也需要邏輯思維能力。唯有 邏輯思維是不夠的，項目管理更需要的你對事務的全局思考以及掌控的能力；到現(xiàn)在我這邊還是一個偏技術型的項目管理者。OK，下面說一下轉型中的一些經(jīng)驗。

對事的轉變

這個也是心態(tài)的一個轉變，在之前做技術時，會更多的鉆到某一個點里去，反復的折騰你的代碼。這是一個習慣，我會經(jīng)?；乜匆幌轮暗拇a，看完之后就 想動手了。這個在項目管理過程要開始慢慢去改變，不能太過于糾結某一個點上。你要考慮的是整個環(huán)節(jié)以前項目情勢。在中間會有不少的取舍。剛開始的時候也會 很糾結在項目中某一實現(xiàn)，會爭論這個是合理還是不合理。當然“舍”掉一些后，也許會給開發(fā)同學的積極性會帶來一些打擊，但是必須要從長遠來看，特別是在一 些強制（時間點定死）項目中，那么更要“舍”得了。唯有犧牲一下，才能看到后面的成功與喜悅。這也許就是看“淡”的感覺吧。

在這里你想的不再是代碼的優(yōu)美、這個功能是放前端還是后端合理，更重要的是從時間上來說如何保障你的項目按照預定的軌道健康發(fā)展。

不拘“小節(jié)”

其實這里也不能說是“小節(jié)”吧，用“不以事小而不為”會更合適一點。做項目管理之后，頓時會發(fā)現(xiàn)一大波鎖碎的事情要跟進了，而且會時不時給你來一個 難題。其實不管什么事務上面，最容易忽視的就是一些小事情。舉個例子：就拿流程規(guī)范來說，不管是你制定了如何近乎完善的流程制度，不管你是同步周知了N次 的規(guī)范，這些都會過程中得不得最終的保障和效益。那么要讓你的收益最大化，其實也不要做太多了，要的只是你在溝通大群里一些關鍵時間做一下小小的溫馨提 示。你可以把這個句提示的話復制下來。在今后的時間做些機械的動作，你會發(fā)現(xiàn)效果會得到很大的改善。當然要達到100%，這個不大可能，因為你面對不是一 條代碼，一個算法。

在過程中多做一些周邊的小事，也給自己養(yǎng)成習慣并提醒著自己我現(xiàn)在或接下來要準備做什么了。

提前預估

這點對于從技術專崗轉到項目管理來說會很輕松，這個在你參加一個項目會議的時候先做到以下幾點，對于你的項目來說會降低不少風險。

1、? 通過項目需求的講解，對技術層面需要的工作量做一個基礎的估算；

2、? 提前設想一下項目的實現(xiàn)方式以及技術的選型，這部分大概需要多少工作量；

3、? 在需求講解時，針對需求預估出技術難點，提前準備；

4、? 提前評估項目中的依賴關系；

5、? 設想一下項目可能存在的的環(huán)境和是否有近似的項目；

6、? 更多……

多聆聽

聽這個在項目過程中個人覺得是個不錯的方式，不管是項目會議和過程中都很重要，在項目會議中主要是多聽一下其他階段（團隊）對問的分析和評估結果，從中了解對你當前負責領域的影響和幫助是什么，針對這些做適當?shù)恼{(diào)整和轉換。

最后，結束……

原文來自：財付通TLD