產品經理有什麼好的項目跟進方法？
作為PM，一項很重要的工作是跟進項目開發，大家談談經驗，如何保證項目按期完成，細節達標，不管是軟方法還是硬方法，暢所欲言吧
呵呵，個人不喜歡用KPI和所謂制度去壓技術，我比較喜歡在前期解決問題。這個方法其實也很簡單。
讓美工、技術更早的進入到項目里。
需求確認後，做原型之前，就把技術負責任拉進來一起討論清楚細節、介面傳遞方式、相關依賴項等等。
做原型之後，讓技術再確認，原型和之前討論的需求實現方式是否吻合，不吻合進行調整。這時就要提前告知美工需要製作的總頁面數，如果頁面很多，要求美工做一張確認一張切一張，和技術同步進行。
原型提交美工後，花一點時間和設計人員說清楚，你要的是什麼，哪些需要為技術保留，哪些請直接做成圖片，哪些地方是按鈕，哪些會進行動態調用別做死在頁面上。
和技術確認的排期，除非是非常非常確認的時間點，否則，請用動態管理方式，如：頁面獲取後，10個工作日內完成開發，預計聯調測試需要1天時間。留出充分的時間。比如，本來開發到測試完成是11天，多留1天作為機動，以備不時之需。
驗收測試的時候，請親自參與，並及時調整測試環境中發現的問題。
上線後2小時內，請首先作為用戶去體驗正式環境的各種情況。隨時進行調整。（一般上線後2小時內可以進行簡單的調整，若正式環境發現大BUG，那麼趕緊下線還來得及）調整完成後，宣傳就上吧，呵呵。
這麼好的問題，三年內居然只有這麼幾個回答。那我就來挖墳了。
樓上各種回答其實好幾個都很不錯，但是這裡有個關鍵的問題-----這些方法不具備極強的操作指導性和簡潔的可複製性。
目前知乎上的回答的趨勢是跨平台無縫連接，不管男女年齡段長相胸圍學歷什麼的都能拿來即用的，這個就是我回答的目的，當然不保證能夠實現，只是在我能力範圍內，盡量的去總結這麼一個拿來即用方法。
首先，題主的題目本身有一定的歧義，嚴格的來說，產品經理和項目跟進無需太多的指揮，因為跟進項目的事是項目經理做的。鑒於很多小公司項目經理和產品經理是同一個人，想來題主問的也是這種情況，那麼以下文字僅以此情況來回答。
通常來說，產品和項目二合一的經理會遇見如下四種問題：
1.工期問題-----下屬拖不動或者上面的不斷的縮短開發時限。
2.團隊內部矛盾----部門間的不配合甚至互噴。
3.產品和設計不對路----做出來的傢伙和設計風馬牛不相及。
4.技術性困難-----壓根就做不出來、BUG或者其他不可抗拒因素。
如果解決這四種問題了，項目跟進這種事基本上就沒什麼大問題了，也無需多麼牛逼的跟進方法了。
那麼就逐條分析了
首先是工期問題，這個份兩種，下屬拖時間或者坑爹的領導不斷要求縮短時間。
在下屬方面，個人經驗是你首先需要有有效的威脅下屬生存能力的權力。
開除什麼的權力太大，除非你是嫡系，一般沒這個權力，不過扣個工資獎金的你必須要有。這個是前提，如果什麼都沒有，員工罷工了你也沒辦法，那麼你這個經理肯定就做到頭了。當然無權的項目經理也能很牛逼，不過那個就要運用到權術，這個就說來話長，基本上可以新開好幾個問題了。不過話說回來項目經理多半是工科出身，權術那一套不一定學得來，這個扯遠了就不多說了。
第二，如果你沒有馭人之道上有一定的基礎，那麼務必關注項目細節的進度。
所謂人無完人嘛，大家都有偷懶的時候，其實項目經理看上去很工科，但是最核心的其實是管理。你做項目經理的時候可能下面有個刺頭老偷懶，但是換他來做那個刺頭就打了雞血一樣每天自發加班還督促同僚的工作進度也說不定。這個就管理學的重要性。不過鑒於有極強的操作性的答案的目的，最簡單有效的方法就是：精確到個人，每個人的工作進度你能清晰的了解，而且還能預測出這個星期他能做出個什麼東西來，這樣其實就很合格了。對於拖大家後腿嚴重的隊友，先以安撫為主，然後爭取讓大家齊心協力後腿給弄上來，等項目完了之後再狠狠的整他一次。萬不可在項目中和下屬或者隊友爆發矛盾。其實拖後腿的員工心理也是很矛盾的，雜揉著對過去的悔恨和對工期困難的迷茫和無奈，結果越拖越遠。這個時候你就是他的情感上的知心姐姐，是他的心靈上的心理導師，是他前途上一個促膝談心的前輩和長者。總之先安撫情緒再說，一旦在大家幫忙下進度趕上來了，他就沒哪個糾結的悔恨和無奈了，大部分也不會再拖了。如果屢教不改的那種，項目完工之後堅決砍了。
然後就是上司的問題了，碰到坑爹的上司，一般就兩種選擇：
1，如果你在公司還算站穩的腳跟，那麼可以選擇堅決不改，如果要改，你不保證要求可以100%符合。
2.如果你在公司還很勉強，那麼在你能保證項目質量能匹配領導要求的前提下，可以提前，並不擇手段的去實現。
一般合格的管理層是不會經常出現要求趕工期這種事的，當然目前國內管理層的人不合格的比合格的多太多，所以這個問題還是要好好談一下。如果你在公司站穩了，就是有一定的話語權了，那麼最好選擇堅決不改（當然前提是你有那種喜歡做這種的上司，偶然事件不算），因為你一旦改了一次就會有第二次，然後他步步緊逼，你就發現沒退路了，最後質量上不能保證，下面也怨聲載道，兩邊不討好。
第二種情況就是你需要呆在這個公司，那麼，你就去不擇手段的展示你的價值吧！下屬怨聲載道什麼的，總比在公司內成為一個邊緣人強吧。
幾點心得，談不上方法：
1、遠期溝通，充分溝通。在項目尚未立項的階段就與參與人員尤其是研發人員溝通，讓大家對於項目的意義、需求、目標有充分了解，這樣大家心才能往一處使
2、充分評估與時間預留。對於項目的時間周期評估，需要建立在方法1的基礎上，而且是對主體細節有充分了解，同時，對銜接出有buffer預留，避免意外情況
3、需求鎖定與細節讓步。需求提出後，在研發過程中需要處於鎖定期，不得隨意修改；而由於評估不完善造成的部分細節實現難度，在不影響大前提的條件下，產品人員要有優先順序概念，對可讓步的內容進行讓步，並思考補救措施
4、全程的review。在產品demo基本完成後，不需要等到功能完整，產品人員就應該介入觀察，不要把風險都堆積到上線前的驗證。
方法更需要因應實際情況而定。
若所在的團隊因技術能力問題而出現狀況，那麼跟進的方法就應該抓住keyman，與其分享項目的實現價值，並分析出問題出現阻力的地方，協助其找到方法或資源去解決問題。
如果團隊因職業素質問題出現狀況，則需要從管理上著手建立成員的危機感以及在職感。強勢要求一些多人協作的加班時間，從中發現問題的性質是偏缺利誘還是散漫或安逸，再針對性地制定出獎罰，並持續放大地執行，從而影響團隊重新打起精神。
如果以上都不是，僅僅是在正常情況下分享跟進項目的經驗，那麼用團隊最易接受並能執行的方式去掌握「時」與「質」就好了。
保持團隊內的溝通，反覆檢視工作順序的安排是否合理，以及檢視細分項目的開發工時是否合理，以確保「時」在掌控之中。
盡量讓團隊保持迭代的開發模式，這很難。但能實現的話能在「時」的基礎上就有「質」的保證，某種角度來看也是項目跟進的保障。項目執行無非就是「時間、事件、人」。三者必須都正確才能達到完美的輸出狀態。
先來談「事件」
產品經理最重要的事：盡量保證每一個判斷都是正確的
在項目執行過程中，很多時候的執行不到位都是因為最初的設計本身並不正確所導致。
比如：
1、有人不認同你的設計，所以不願意配合或者發生爭執，心不齊是很難做事的；
2、做到一半突然發現還有些場景和邏輯之前並沒有考慮到，然後臨時打個補丁。不幸的是大部分臨時補丁都無法天衣無縫；
很多產品經理都喜歡認為不要想那麼多，先做了再說。這是典型的用戰術的勤奮去掩蓋戰術的懶惰。你要搞清楚，你balabala說一小時，程序員、設計師、測試工程師就要忙活好久的，然後發現錯了，你一句對不起，別人又要重新來過。換做是你會開心嗎？
所以PM必須要在執行之前，先確保「讓每一個判斷都儘可能是正確的」。
合理的版本時間迭代規劃是一門技術活，需要根據你當前不同限制性條件下來完成任務的拆解工作。這裡涉及到的因素太多，大概羅列一下：
1、如果項目太大，建議分拆成小版本通過迭代的方式來實現。這樣可以做到將每個小版本時間盡量風險可控，出現問題也能及時調整。但對於功能框架的把握能力要求較高。項目分拆也是一門藝術；
2、很多時候需求分配好了，大家悶頭各自做好久，結果發現時間預估不合理。可以儘可能的將每一個feature分拆成若干個小功能，讓每一個小功能的時間盡量達到在8小時以內可完成的程度；
3、項目流程必須清晰可執行，這是確保時間可控的基礎。需要有一個標誌性事件來表示某一個事情可進入到下一個狀態。需求設計與需求執行的工作一定要儘可能分開，否則後續會不同程度的失控；
4、如果以上兩者都執行OK，那麼就要確保迭代版本之間的銜接要穩定。FC和版本啟動會出現並行狀態，工作的銜接要更加的緊密了；
再來談」人「
1、要保證步伐一致，首先需要思想一致。所以，要學會把自己的思想裝進別人的腦袋裡。這個方法因人而異吧，至少你得讓人相信你；
2、溝通永遠是團隊協作最麻煩的事情，有的是因為性格的原因，有的是因為理解不同，有的是因為利益角度問題。也有能夠緩解的方案，比如晨會制度、比如責任人制度，任務進度排期表制度，但是按照我的經驗來看，所有這些制度都只能解決最多60%的問題。其餘還是需要瑣碎的溝通，對於PM來說，必須要有良好的補位意識。沒搞清楚的細節立刻過去溝通確認，研發做出來了一個demo儘快去體驗一下，測試發現了一個bug儘可能了解緣由然後協助判斷是否需要解這個bug，UI設計師出的效果圖是否華而不實的影響研發的工作，過程中要不斷四處看看。這個方面是沒辦法走捷徑的，因為你要的就是完美的執行。
制度和認識很關鍵，每個時間的交付物定死，之後不能隨意改變。
1. 需求評審通過後，需求不能變。
2. 技術部門定出的上線時間不能變。
3. 如果需求有變更，那麼上線時間要做相應的調整，需求提出方負責任。
4. 如果是技術的原因，技術部門負責任。
5. kpi考核嚴格執行，用數據說話。
下面的跟進方式只適合10人以下的小團隊
1 項目計劃電子文檔發給所有人，一份整個項目的計劃，一個是每個人的項目安排，讓每個人認識到自己的工作和自己工作對整個團隊的影響
2 項目的跟進工具只需要完成完成幾件事情即可：能夠及時的收集並直觀得到每天任務的執行情況、能夠明白任務拖延的原因，及早的發現問題，能夠總覽整體項目的執行情況。個人還是喜歡用EXCEL來做跟進原因是比較簡單和靈活，可以根據自己的需要進行修改，特別適合於要磨合的新團隊
3 項目堅持日收集，周評審（根據項目大小會有些變化），日收集的目的是要發現問題，找到任務拖延的根源，協調資源解決，周評審的目的是為了監控項目的進度是否在可控範圍內，同時明晰下周計劃，並將其分配到每天也是很重要的，一定要知道兩個階段的工作是不一樣的，不要做越俎代庖的事情。
4 持續集成，測試同步跟進，不要在項目結束時才發現有好多隱藏問題。
5 定期的慶功會是必要的，可以多種形式，不一定需要特別正式。可以提振團隊成員的凝聚力和信心
6 鼓勵為主，懲罰為輔，特別是在項目延期嚴重的情況下。如果人的信心沒有了，項目就真的徹底失敗了
1 如果項目連續幾周都在失控中，應該反思自己計劃是否得當，然後及時的做出調整和更改
2 項目計劃要留有餘地
3 不要相信計劃是不變的，要根據實際情況進行調整
4 如果一個程序員告訴你他的工作完成了80%，不要相信他
5 項目經理的工作是協調，而不是管束。放正自己的位置，少用命令的口吻
6 項目經理要有一個對工作延期的容忍範圍，沒有到達這個範圍時，不要找開發人員談話，要相信他們會悄悄的把進度趕上來。
7 如果沒有專業的測試團隊，可以考慮讓開發人員互相測試，好處兩點：加深開發人員對整個系統的把握、緩解他們開發的壓力
產品經理主要關注用戶故事或功能點的進度，每個開發周期內，將計劃交付的功能點按照權重劃分，總數為100%。每個功能點再按照需求設計、開發、測試等按比例進行一定的切割，總數為100%，這樣就形成一個功能和工作的矩陣，每天的更新則能清晰的看出開發周期功能實現從0到100%的行進路徑。
任務目標分解之後成員認領或分配，每完成一個功能模塊集體驗收測試，然後放炮開香檳發糖慶祝一番，發現Bug的自己解決。
項目經理盯緊燃盡圖隨時調整資源就可以了。
個人感覺項目的最大困難或者說障礙不是跟進，而是需求調研。初期就成立一個團隊，隨時保持聯絡。
。。。堵工位
大家都說越早讓團隊人員進入越好，但有的項目剛開始pm還沒清晰的頭緒或方案，你怎麼和他們說？越早進入越容易暴露你的無知。
1.按工作線條拆分項目，產品的每一塊從前端設計開發，到後台開發，再到整個機制，數據，都了解清楚有哪些線條，並且確定對應的介面人，做到自己知道什麼問題該找誰
2.按規划進行拆分項目，什麼時間段要達到什麼目的，這裡面最主要的工作是什麼，你該找誰，要了解清楚。
3.每天早上check一下進度（周期視項目情況而定），記錄問題，匯總，如果有必要，每天郵件到項目組待解決問題有哪些
自己能夠明確這些事情的優先順序，知道什麼時候該做什麼，基本上就能夠很好的跟進一個項目了~
首先作為PM你的了解這個項目的總體需求。
需求最主要的就是了解客戶真正想要的是什麼，如果這一問題解決了之後，那麼接下來的事情就是如何讓這個項目正常有序的發展下去。
這個就要涉及到WBS，工作分解結構。
mark 學習啦
項目管理工具 （推薦Trello）+ 定期不定期的check + 產品經理自身很有人緣和魅力
項目管理包含多個方面，需求，計劃，資源，風險，跟蹤，考核。
需求就不說了，這個是重中之重，是項目的基石，務必要管控好需求，反覆變更是項目的大忌，掌控好需要經驗與閱歷。。。
計劃很關鍵，項目要先分解為一級任務包，包括任務，責任人，工期，資源，再逐級分解任務包，儘可能多級分解，並逐一與責任人確認，有助於掌控項目的每一步。計劃的合理性是整個項目受控的基礎。另外，工期的評估很有講究，不同的人結論不一，新老手差異更大，需要特別注意，可適當參考最優，最差，最有可能的狀態，按合適演算法取工期參考值。另外，要注意人員與人員，部門與部門之間的任務銜接，定義好這些任務之間的輸入與輸出可以有效減少扯皮與推諉。。。
資源是保障，如果資源投入得不到保障，優勢資源不能優先調用，項目延期是早晚的事。。。不同的人出不同的活。。。
風險分析與管理務必不能小視。充分識別項目過程中的各種風險，並制定對應的防範策略，有助於控制項目不至於失控。。
跟蹤項目進度，及時發現問題，及時協調解決，關鍵路徑需要重點跟進，異常時需要儘力彌補。。。
考核是手段，項目經理需要好好運用，特別注意考核只是控制項目的手段，不是目的。。。立規，跟蹤，溝通，考核是閉環的過程，不可急躁冒進，其中溝通是關鍵，找准延期問題並妥善處理才是主要目的。
川渝產品經理(PM)交流 321397396
推薦閱讀 《人月神話》 很經典地分析了產品經理的位置 以及項目拖延等情況的解決
推薦閱讀：
※怎樣才能更好的把項目計劃和缺陷跟蹤結合起來？
※如何避免 IT 項目延期？
※手下同事干活不主动/还剩工作内容拖着不干，作为急性子的我（主管）一直帮着干手下同事的活，我该如何处理？
※一個完整的戲劇項目是如何運營的？