大部分互聯(lián)網(wǎng)公司都沒有一個定崗的項目經(jīng)理來專門負責(zé)項目進度，這項職責(zé)逐漸被產(chǎn)品經(jīng)理攬下；那么在管理過程中，有哪些“坑”是需要避免的呢？看本文給的9個建議吧~

大部分互聯(lián)網(wǎng)公司好像都沒有一個定崗的項目經(jīng)理來專門負責(zé)項目進度。

更多時候，管理項目進展的職責(zé)落在了產(chǎn)品經(jīng)理身上。久而久之，好像很多產(chǎn)品經(jīng)理都會自發(fā)積極跟進項目進度，盡自己最大努力保證項目順利上線（起碼我認識的和我身邊的好像都這樣）。

遇到成熟的公司還好，版本和特性都規(guī)劃得比較好，項目成員也有足夠的時間完成各自的模塊，人人都留有余地。不過這樣的理想情況實在是少之又少，回首做過的項目，大多都是趕時間趕進度，項目成員疲憊不堪。

特別是現(xiàn)在的項目組，每一個項目進行的時候，都會下意識認為：熬過這次，下次就好了。

但事實上，好像這種節(jié)奏一直都沒有多大變化。

今晚再一次面臨回歸跑不通的窘境，導(dǎo)致項目成員的心態(tài)都有點炸裂，時間越來越晚，我自己也變得有點急躁。雖然最后發(fā)版成功，下班路上想了一下，其實是有不少問題可以避免的，記錄一下。

一、項目成員權(quán)責(zé)清晰

負責(zé)的業(yè)務(wù)和業(yè)務(wù)結(jié)合得比較緊密，帶領(lǐng)的項目組會收到各個業(yè)務(wù)方的需求。

在那之前，各側(cè)業(yè)務(wù)流程不夠清晰，也沒有明確的規(guī)范和邊界，業(yè)務(wù)方會經(jīng)常直接給研發(fā)同事提需求，研發(fā)同事有不清楚的地方，也有時候會直接找到業(yè)務(wù)方，某些需求沒有經(jīng)過產(chǎn)品經(jīng)理梳理和確認，導(dǎo)致進行中的項目有的特性和別的特性沖突或是遺漏，這些風(fēng)險又往往只能在發(fā)版前產(chǎn)品經(jīng)理最后驗收的時候才會冒煙。

每每遇到這樣的問題，不能按時發(fā)版不說，還會導(dǎo)致項目成員互相之間有怨念。

在這樣的事情發(fā)生幾次之后，實在是有點忍受無能，針對幾個出現(xiàn)問題比較大的項目，在發(fā)版之后進行了長時間的詳盡復(fù)盤（過程各種糾結(jié)不表），最終和各側(cè)負責(zé)人一起確定了幾條規(guī)則：

1. 重新界定各側(cè)權(quán)責(zé)

比如業(yè)務(wù)方只需要提出業(yè)務(wù)需求，至于產(chǎn)品方案怎么設(shè)計是產(chǎn)品同事的事情，業(yè)務(wù)方可以提供建議，但是嚴禁過多干涉產(chǎn)品方案細節(jié)。

為了確保產(chǎn)品方案能夠滿足業(yè)務(wù)方需求，會在需求評審之前和業(yè)務(wù)方溝通確認。另外，需求評審也會邀請業(yè)務(wù)方一起參與。同時，也會在各個驗收環(huán)節(jié)邀請業(yè)務(wù)方參與驗收。

2. 單點串聯(lián)單點負責(zé)

如上文所述：項目進行過程中，多方?jīng)Q策多方意見容易造成信息不同步以及遺漏的問題，后來就限定項目參與方單點負責(zé)，涵蓋了設(shè)計、研發(fā)、測試全過程。

一旦完成需求評審并完善方案最終交付進入設(shè)計研發(fā)之后，除了設(shè)計師征求設(shè)計風(fēng)格之外，業(yè)務(wù)方基本不再參與項目細節(jié)。

設(shè)計、研發(fā)、測試過程中，有不確定的點相關(guān)執(zhí)行人員都會找產(chǎn)品同事確定。設(shè)計驗收、發(fā)版驗收等環(huán)節(jié)，產(chǎn)品經(jīng)理會在驗收確認直到?jīng)]有什么問題之后，邀請業(yè)務(wù)方參與驗收。我們通常采用郵件通知驗收，預(yù)留驗收時間，文檔收集修改建議的方式進行。

經(jīng)過一段時間的執(zhí)行和不斷強調(diào)之后，大家都形成了比較好的責(zé)任意識和邊界概念，知道什么事該找什么人，各行其是，起碼協(xié)作效率提高不少。

二、產(chǎn)品經(jīng)理要有用于說不的勇氣和氣魄

可能是因為我們業(yè)務(wù)變化比較多的原因（部分也是因為業(yè)務(wù)方新人較多，需求不清晰，淚目），產(chǎn)品側(cè)會時常接到一些比較匪夷所思的需求，而且業(yè)務(wù)方在前期提需的時候還容易出現(xiàn)表述不清的情況，所以會發(fā)現(xiàn)產(chǎn)品同事在耗費大量時間需求預(yù)研，方案設(shè)計，最終完成需求評審之后，還常常接到業(yè)務(wù)方一些靈機一動的小腦洞。

看起來，這些小腦洞確實能夠帶來一些體驗上的小提升。但是對于整個項目規(guī)劃來講，真的就很容易是災(zāi)難了。

部門新入職的產(chǎn)品小哥哥剛開始還比較心軟，認為好好和下游同事求個情臨時加上一點點需求也蠻好的，所以妥協(xié)好幾次，直到發(fā)現(xiàn)現(xiàn)象越演越烈，終于不堪其擾義開始正嚴辭拒絕。

作為業(yè)務(wù)方，當(dāng)然是希望體驗越好越棒，但是當(dāng)產(chǎn)品同事接收到一些臨時需求之后要學(xué)會評估和判斷。有些看起來很小的特性，給體驗帶來的提升非常有限，但給整個項目組帶來的麻煩是沒有窮盡的。

業(yè)務(wù)方和產(chǎn)品同事，看起來很小的東西，可能需要研發(fā)同事變更整體設(shè)計思路。不斷新增或變更需求，光是擾亂規(guī)劃影響研發(fā)寶寶們的心情，就夠被打死的了。所以，下次再在項目研發(fā)進程中，有臨時需求加進來，快速判斷及時say no吧。

三、讓所有同事養(yǎng)成有問題及時反饋的意識

過往項目中，見過挺多，尤其是研發(fā)同事，是真的不喜歡把問題“捅”出來。

上個月的某個項目，研發(fā)同事遇到其他項目組的數(shù)據(jù)問題，導(dǎo)致他自己的研發(fā)進度一直走不下去，憋了快兩天，直到早會上問起才暴露出來。

好像挺多職場小伙伴并不太會借力，運用自己身邊的資源，遇到問題習(xí)慣性的自己憋著，直到別人問起。

在那之后也會多次強調(diào)大家遇到問題一定要及時反饋，需要產(chǎn)品同事們協(xié)助解決的，直接提要求給相應(yīng)的產(chǎn)品同事即可。有時候，遇到不能解決的問題，還是要學(xué)會上升，也許在自己層面不能解決的問題，上升一下，其他人一兩句話就能cover掉。

四、更好的特性分類和關(guān)聯(lián)規(guī)劃

這個很重要，但因為我確實不懂技術(shù)，有興趣的可以和自己的研發(fā)同事討論一下，當(dāng)一個特性因為關(guān)聯(lián)特性有問題不能發(fā)版的那種等待，也是很折磨人的。

五、約定好確定的發(fā)版窗口

原本，我司有規(guī)定每周二和每周四是確定的發(fā)版窗口。但是項目多的時候，大家好像趕著趕著就會忘記一些規(guī)定，導(dǎo)致業(yè)務(wù)方也好、項目成員自己也好，并沒有相對嚴格的時間線，在項目進行過程中，沒有那么強的“儀式感”和進度感。

當(dāng)天沒有完成任務(wù)之后不自覺抱一種無所謂的心態(tài)，今天不能發(fā)版，那就明天發(fā)版好了，久而久之，就容易出現(xiàn)比較隨意的工作狀態(tài)，缺少一些敬畏心。業(yè)務(wù)方不在意發(fā)版窗口之后，在業(yè)務(wù)節(jié)奏安排上就沒那么嚴格，項目成員面對項目延期，也變得無所謂，這是很不好的。

六、盡可能的預(yù)留buffer

雖然，每個人都希望項目能夠順利進行，嚴格按照規(guī)劃好的時間向前走。但是事實上，久經(jīng)風(fēng)霜的人會告訴你，那基本是不太可能的。

看起來多么順利的項目，也都會在最后出現(xiàn)一些詭異的關(guān)卡。

不管是多趕的項目，也要習(xí)慣性預(yù)留20%-30%的buffer。項目能夠提前完成當(dāng)然是好事，但是相信我，基本上這里那里總會出現(xiàn)一些讓人崩潰的bug。預(yù)留buffer，給自己預(yù)留一些余地，總是沒錯的，畢竟，誰還沒有個想要摸個魚的時候呢（buffer絕對不是用來摸魚的：））。

七、保證良好的測試環(huán)境

業(yè)務(wù)復(fù)雜的時候，稍微大一點的特性都有可能需要跑通整個流程，絕對不會是說只需要針對當(dāng)前特性“象征性”的測試一下即可。

比如要驗證購買結(jié)果之后的某一運營位，就必須要驗證整個購買流程。

我司共有六個測試環(huán)境，但凡設(shè)計到整個業(yè)務(wù)流程的時候，經(jīng)常（非常經(jīng)常）出現(xiàn)其他流程跑不通阻礙整體測試的情況。比如今天晚上那個特性，我們自己側(cè)的業(yè)務(wù)和代碼都沒有什么問題，但就是在回歸的時候，其他部分流程跑不通，不能完整測試，其他側(cè)同事因為忙于自己的事情，又是周五，整整延誤了三四個小時，才最終跑通整個流程。

如果是重要特性需要測試，保證良好的測試環(huán)節(jié)，是一件非常提升效率的事情（在此，表白一下我司測試小妹妹，溫柔漂亮專業(yè)又性格好）。

八、有變更及時郵件通知、jira記錄

需求評審雖然已經(jīng)足夠細致，大家也通常會在會上提出不少問題，但是設(shè)想和真正實施中間的差距還是不少的。

所以有一些問題一定會是在研發(fā)過程中才會真正出現(xiàn)，比如少了的某個交互，遺漏的某個邏輯。

遇到這種時候，一定不要過分相信口頭溝通，大家事情多的時候，往往上午才說的事情，下午都不記得了。發(fā)生的關(guān)于需求所有變更，及時、準確備注在jira，并在群里@相關(guān)人注意，不僅僅是為了顯示正式和專業(yè)那么簡單。前期溝通時候保證準確性和有文字記錄，能減少很多驗收過程中的不確定和撕。

九、不要周五發(fā)版

最后，最重要的也是最需要銘記的：不要周五發(fā)版！不要周五發(fā)版！不要周五發(fā)版！

一是雙休的公司，周五發(fā)版，一旦出現(xiàn)線上問題，整個team的人周末就完了，這件事不少人應(yīng)該都體會過。二是，周五發(fā)版，真的，太考驗人心了，想想，所有同事都提前下班歡度周末去了，你還要留在辦公室百無聊賴的等待發(fā)版，項目成員想砍你，也是很容易理解了。

每一個項目都有很多坑，雖然踩過越多坑才越有底氣，但還是希望每個踩過的坑都是有意義的，也希望每個產(chǎn)品經(jīng)理負責(zé)的任務(wù)都能夠發(fā)版順心、順意、順利。

例行申明：發(fā)版這件事，說來，每個人都有很多自己的經(jīng)驗，這些討論更多是我個人的一些復(fù)盤總結(jié)，不代表別人或我司觀點，有不同意見，歡迎探討，但是不接受杠精寶寶哦。

本文由 @麥醬 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。