&

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

產(chǎn)品經(jīng)理如何管理項目進展的9個建議（產(chǎn)品經(jīng)理如何管理項目進展的9個建議和意見）

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

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

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

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

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

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

一、項目成員權責清晰

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

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

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

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

1. 重新界定各側權責

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

六、盡可能的預留buffer

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

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

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

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

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

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

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

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