項目經(jīng)理在項目計劃中的作用

剛開始從事項目管理工作那會兒，對于制定項目計劃常常有這種感受：都是開發(fā)和測試說了算。他們說需要三天，就三天，他們說什么時候上線就什么時候上線。這種執(zhí)念一直糾纏著我，有一段時間也曾非常的糾結于這一點，甚至一度覺得非常失落，開始懷疑自己的價值。但是隨著經(jīng)驗的增加，經(jīng)歷的項目增多，在這一點上漸漸有了些新的體會：在項目計劃上，項目經(jīng)理能做的還有很多。

項目經(jīng)理并不是在項目計劃上可有可無的角色，也不只是幫大家畫個時間線這樣的角色，只是項目經(jīng)理在這上面的作用不是那么顯性，但卻是不可缺少的。首先介紹一下，當前筆者所在團隊是如何做計劃的。需求確定之后，開發(fā)會根據(jù)需求分解任務，對于不同的任務，進行估算，并且確認提測時間。然后將安排發(fā)給測試，由測試補充各任務的測試時間以及回歸、兼容性等測試的安排，從而制定出初步的計劃(包含上線時間)。初一看，完美!團隊自己就把計劃制定出來了!有項目經(jīng)理什么事兒?!其實不然。下面跟大家分享一下，筆者認為的項目經(jīng)理能在這過程中起到的作用。

1、確認版本周期。計劃的時間點需要根據(jù)開發(fā)的工作量評估來確定，但是項目經(jīng)理需要確定這個版本大概的周期是多久，是一個兩周版本還是一個一月版本。在開發(fā)開始評估工作量和確認提測點之前，項目經(jīng)理就要將版本周期情況同步給團隊。影響項目經(jīng)理確定版本周期的因素往往有：上個版本的情況：如果上個版本剛剛經(jīng)過一個非常緊張的大版本，有不少小的優(yōu)化功能未能上線或者大版本上線后用戶反饋了一些比較影響體驗的問題。那么下一個版本項目經(jīng)理就有可能考慮發(fā)一個較小的版本，將這些優(yōu)化和問題盡快上線。運營推廣計劃：某些版本可能是配合運營推廣的計劃，那么在確定版本周期的時候就要考慮到這一點，確保移動端通過審核的時間能夠滿足推廣需求。與其他端的配合：某些版本需要多端協(xié)同的，那么確定周期時就需要考慮到其他端的發(fā)布安排。

2、完善和優(yōu)化團隊給出的初步計劃。開發(fā)和測試給出自己相關任務的時間點，但是對于一個項目來說，這些還不夠。這些往往會被團隊所忽略的，包括但不限于如下幾點：安排多提測點：剛開始的時候，開發(fā)會習慣給出一個最終提測的點，這對盡快交付并不是什么好消息。所以項目經(jīng)理需要去跟開發(fā)一起梳理，是否有一些功能點是可以提前交付的，這樣測試就能提前介入，從而縮短研發(fā)周期。

需求凍結時間點：幾乎在每一個團隊中，需求變更總是被開發(fā)和測試所詬病。對于需求變更，我們不能完全說不(一來是要應對市場的變化，二來我們也理解在策劃階段總是有一些未知的問題)，但是不是任何時間提出來的需求變更我們都接受的，我們認為在某個時間點之后再提出的需求就會影響版本的順利上線，那么我們就有可能拒絕。這個時間就是凍結時間點�？紤]到這個時間不能太早也不能太晚，太早不切實際，太晚又影響計劃。所以我們定義的需求凍結時間點是在最后一個提測點之后的一天。

數(shù)據(jù)埋點的安排：埋點一直以來都被開發(fā)認為是最不重要的工作，無所謂什么時候做，只要在上線前埋一下就行了。但是有一次埋點就埋出了問題。那次是在上線前一天，在最后的版本開發(fā)做了埋點的工作，最終導致了軟件出現(xiàn)崩潰的問題。自那次以后我們就約定埋點要盡快進行，不能等到最后一天。但是埋點工作也常常在計劃階段被遺忘，所以就需要在計劃制定過程中給開發(fā)預留一部分工作量用于埋點，同時明確埋點完成的時間節(jié)點以及埋點驗收完成的時間。

代碼凍結的時間點：所謂代碼凍結當然就是代碼不允許改動了，因為在最后時間的代碼改動都有可能引起bug導致無法按時上線。現(xiàn)在我們約定，上線前一天完成代碼凍結工作。其他時間點：如有管理后臺配合的功能，就要約定管理后臺上線的時間;API接口的上線的時間，因為我們移動端的bugbash 是在線上進行的，所以在bugbash之前確保API接口已上線;ios的版本需要考慮testflight上測試的安排，一般會放在測試最后回歸的階段等。

3、合理的統(tǒng)籌人員分配。工作量合理分配。各任務評估完成之后，需要將工作量做合理的分配。很多時候看到開發(fā)自己排定的計劃中工作量的分配會不均衡，有些人多有些人少。但是當被問及原因時也并沒有什么原因，可能只是沒有仔細考慮，所以項目經(jīng)理要幫助團隊更多的考慮這部分，將工作量能夠更合理的分配。人員在多項目間的分配。例如發(fā)現(xiàn)開發(fā)和測試排出來的計劃已經(jīng)不能滿足時間節(jié)點的需求的時候，一方面當然是要優(yōu)化當前的計劃，但發(fā)現(xiàn)已無優(yōu)化空間時，就要考慮調整人員的分配情況。因為項目經(jīng)理會比具體的成員更了解從全局上的優(yōu)先級，就可以考慮將低優(yōu)先級項目的人員臨時調到高優(yōu)先級的項目上來，當然這是在跟職能主管取得一致意見的情況下。

4、考慮假期影響。一個版本開始之前最好能夠收集大家既定的請假情況，在工作量安排上給予考慮。尤其是在一些法定節(jié)假日前后尤其需要考慮。另外一些特殊情況也會導致請假人員密集：例如公司每年六月份都會消除上一年遺留的年假，這也會導致大家在6月份密集請假。除了請假安排的考慮，項目經(jīng)理還必須考慮節(jié)假日帶來的“假期綜合癥”，如國慶或者春節(jié)這樣的長假前后，大家的工作效率都會降低，這也會成為項目延期的風險，所以需要在計劃階段給予考慮。

5、周知計劃。確保相關人士能夠get到這個版本的計劃。研發(fā)團隊常常會禁錮在自己的一畝三分地，所以一般情況下，很少有人會想到要周知其他角色，就算有意識去通知相關角色也會很容易遺漏。所以項目經(jīng)理就需要幫大家補足這部分。那么除了研發(fā)團隊還有哪些角色會關心呢?
需求人員(包含老大)會很關心計劃，包含具體的需求范圍(需求范圍可能會跟策劃原先提的有所出入，會根據(jù)工作量情況做微調)，以及具體的上線時間。

運營人員，運營同學需要該計劃來確認下一波上線的內(nèi)容，從而判斷是否需要針對某幾個功能或者活動安排運營推廣活動。市場同學，市場同學需要通過該計劃來提前準備提交應用市場審核的相關材料，如果有首發(fā)安排的話，還需要提交首發(fā)申請。如果是跟其他業(yè)務團隊合作的，那么還需要通知合作方。但是對于項目經(jīng)理而言，不是說做到本文提到的這些就能夠做出完美的計劃了：

一來，每個項目的背景不一樣，執(zhí)行的方式也會有所不同，所以制定計劃過程中需要注意的事項需要結合項目的情況進行裁剪；二來，萬事萬物都是不斷變化的，我們需要不斷總結經(jīng)驗，每發(fā)生一個問題，就要去反思這個問題是不是能夠在計劃階段通過更完善的計劃而避免的。如果是，那么就將這點記錄下來，在下一次計劃時注意。這樣項目計劃的checklist就會越來越豐富；三來，筆者的經(jīng)驗也是有限的，可能有失偏頗，所以我們還是要根據(jù)團隊以及項目的情況，審時度勢的去制定計劃，擁抱變化才是正道。

所以說，項目經(jīng)理并不是在項目計劃上可有可無的角色，也不只是幫大家畫個時間線這樣的角色，只是項目經(jīng)理在這上面的作用不是那么顯性，但卻是不可缺少的。打個比方，沒有項目經(jīng)理，項目計劃還是能定出來，只不過這個計劃會缺胳膊少腿，到最后還會發(fā)現(xiàn)按時上線會遇到各種風險和問題。