分類: 問答 常識詞典 編輯 : 常識 發布 : 04-07

閱讀 :457

產品經理有什么好的項目跟進方法？作為PM，一項很重要的工作是跟進項目開發，大家談談經驗，如何保證項目按期完成，細節達標，不管是軟方法還是硬方法，暢所欲言吧7 個答案

答案 1：

呵呵，個人不喜歡用KPI和所謂制度去壓技術，我比較喜歡在前期解決問題。這個方法其實也很簡單。讓美工、技術更早的進入到項目里。需求確認后，做原型之前，就把技術負責任拉進來一起討論清楚細節、接口傳遞方式、相關依賴項等等。做原型之后，讓技術再確認，原型和之前討論的需求實現方式是否吻合，不吻合進行調整。這時就要提前告知美工需要制作的總頁面數，如果頁面很多，要求美工做一張確認一張切一張，和技術同步進行。原型提交美工后，花一點時間和設計人員說清楚，你要的是什么，哪些需要為技術保留，哪些請直接做成圖片，哪些地方是按鈕，哪些會進行動態調用別做死在頁面上。和技術確認的排期，除非是非常非常確認的時間點，否則，請用動態管理方式，如：頁面獲取后，10個工作日內完成開發，預計聯調測試需要1天時間。留出充分的時間。比如，本來開發到測試完成是11天，多留1天作為機動，以備不時之需。驗收測試的時候，請親自參與，并及時調整測試環境中發現的問題。上線后2小時內，請首先作為用戶去體驗正式環境的各種情況。隨時進行調整。（一般上線后2小時內可以進行簡單的調整，若正式環境發現大BUG，那么趕緊下線還來得及）調整完成后，宣傳就上吧，呵呵。

答案 2：

幾點心得，談不上方法：1、遠期溝通，充分溝通。在項目尚未立項的階段就與參與人員尤其是研發人員溝通，讓大家對于項目的意義、需求、目標有充分了解，這樣大家心才能往一處使2、充分評估與時間預留。對于項目的時間周期評估，需要建立在方法1的基礎上，而且是對主體細節有充分了解，同時，對銜接出有buffer預留，避免意外情況3、需求鎖定與細節讓步。需求提出后，在研發過程中需要處于鎖定期，不得隨意修改；而由于評估不完善造成的部分細節實現難度，在不影響大前提的條件下，產品人員要有優先級概念，對可讓步的內容進行讓步，并思考補救措施4、全程的review。在產品demo基本完成后，不需要等到功能完整，產品人員就應該介入觀察，不要把風險都堆積到上線前的驗證。

答案 3：

制度和認識很關鍵，每個時間的交付物定死，之后不能隨意改變。1. 需求評審通過后，需求不能變。2. 技術部門定出的上線時間不能變。3. 如果需求有變更，那么上線時間要做相應的調整，需求提出方負責任。4. 如果是技術的原因，技術部門負責任。5. kpi考核嚴格執行，用數據說話。

答案 4：

方法更需要因應實際情況而定。若所在的團隊因技術能力問題而出現狀況，那么跟進的方法就應該抓住key-n，與其分享項目的實現價值，并分析出問題出現阻力的地方，協助其找到方法或資源去解決問題。如果團隊因職業素質問題出現狀況，則需要從管理上著手建立成員的危機感以及在職感。強勢要求一些多人協作的加班時間，從中發現問題的性質是偏缺利誘還是散漫或安逸，再針對性地制定出獎罰，并持續放大地執行，從而影響團隊重新打起精神。如果以上都不是，僅僅是在正常情況下分享跟進項目的經驗，那么用團隊最易接受并能執行的方式去掌握“時”與“質”就好了。保持團隊內的溝通，反復檢視工作順序的安排是否合理，以及檢視細分項目的開發工時是否合理，以確保“時”在掌控之中。盡量讓團隊保持迭代的開發模式，這很難。但能實現的話能在“時”的基礎上就有“質”的保證，某種角度來看也是項目跟進的保障。

答案 5：

樓主可以邀請幾個人來回答嘛，坐板凳，觀望……

答案 6：

初期就成立一個團隊，隨時保持聯絡。

答案 7：

我覺得項目上，溝通環節是少不了的，時間計劃也都會有。我覺得重點問題是在于不精通技術的產品經理如何去設定產品開發真正所需的時間周期（而不是由技術員說幾天就幾天）以及如何驗收代碼（即評估代碼質量，而不是找BUG）

下一篇:大家覺得-的 Web- 3.0 怎么樣？它是不是一種趨勢？ 下一篇 【方向鍵 ( → )下一篇】

上一篇:京東商城的圖書只能退貨，卻不能換貨？ 上一篇 【方向鍵 ( ← )上一篇】