產品經理怎麼跟工程師溝通時間進度問題？
比如需要開發一個什麼東西，工程師會說：30天
問為什麼30天 會告訴你工作量很大。
怎麼判斷是否真的需要30天？如果自己（不專業）覺得不需要 怎麼跟工程師溝通？
謝邀。
通常，如果你讓工程師不必為他所說的話負責任，你就能得到負責任的回答。
坦白說，看到這個問題，也許是我惡意推論了，我總覺得提問者內心深處有一種潛意識，把自己和工程師當成上下游的關係，把工程師對工期的估計當作對自己的承諾。「30天才能給你。」「不行，我15天就要。」這不是溝通，這是對立面的談判。道已錯，追求術有什麼用？
工期很難準確估計，這與產品很難準確定義需求一樣。我見過一些號稱能解決這兩大難題的方法或者工具，但是：
(1) 它們本身會帶來額外成本，而且往往大得讓人難以接受
(2) 更重要的：它們在扯皮時有效，在推進項目時失效
如果工程師給出一個正常的工期預估，那麼很有可能不能按期完成。而如果不能按期完成可能會被你找麻煩，那他會給出一個足夠充分的時間來保護自己，這很自然。
真正有效的辦法，是讓彼此間的溝通，永遠不會成為日後扯皮時的證據。這樣才有利於拿到最真實的信息，方便作為正確的判斷。自然，還是無法準確，但互聯網本身就充滿著不確定性，這正是它魅力之所在；工期的不確定，是這個「大不確定性」中很小很小的一部分，如果這都無法承擔，還做毛產品經理呢。回答過一個類似的問題，原文鏈接：產品經理怎樣合理的預估項目開發時間？
===================以下是搬磚過來的，方便懶得點連接的同學======
對於預估項目周期，沒有什麼比經驗更準確的了。比如你曾經做過類似的項目，當時用了一個月；這個次做的項目還是同等的規模，同樣的質量要求，同一批工程師（至少水平相當），那麼這次的項目差不多也要一個月。
為什麼這麼依賴經驗呢？因為項目周期這種事情，除去工程師寫代碼設計師畫圖的時間之外，還有很多其他事情會耽誤時間：比如大家對需求爭來爭去的時間、伺服器上傳速度慢耽誤的時間、老闆改主意了返工的時間、修改bug需要的時間、工作站死機了沒存檔重新做的時間等等等等，這些時間很難用公式來計算，只能說憑藉經驗來估計。所以你項目做得越多，時間估計的就越準確。
其次我們就會用到專業。雖然說有很多時間是沒法靠公式計算的，需要用到經驗，但是依然有那麼一部分工作時間（而且比例還不小）是可以靠「公式」來計算的。如果你想掌握這個「公式」，就得掌握相應的專業知識。這個專業不是產品經理的專業，而是相關環節的專業。比如你讓前端工程師切一個純的靜態頁和讓他加入js特效花費的時間肯定是不同的，js特效是彈一個浮層出來還是阿賈克斯的拖動時間也是不一樣的，你需要明白這些不同的需求在處理起來大概要花多久，有沒有可以縮短時間又滿足需求的方法（儘管你不需要知道方法的細節）。這對於你計算項目時間也是非常有必要的。
最後才是溝通，如果你前兩項都不掌握，溝通是沒有基礎的：在你眼裡工程師漫天要價，在工程師眼裡你異想天開。你只有大概知道合理的時間是多少，才能運用溝通技巧，去說服工程師用一個比較合理的時間完成項目。
不想做產品經理的構架師不是好程序員……
以這句話開始回答的目的在於，現在社會早已進入了全面分工時代，那些依靠一己之力完成中型以上項目/產品已不可能，同時具備多種技能的人員（產品+構架 or 構架+開發 or 開發+測試）從比例上來說對大部分公司來說都是奢望。
在各種工作量估算方法中，無論是「土的不能再土」的經驗估算，還是在CMMI中的FPA，在組織適用的條件下都是好的估算方法。但是之所以在大多數中小型公司會出現樓主這樣的問題，個人認為有一下幾個原因：
1、缺少統一的估算方法/標準：如果組織確認用經驗來估算，那麼工作量的準確程度取決於估算人的能力、工作態度（可能還有心情）；因此我個人是建議在組織中推行相對客觀的FPA方法，但是這一方法需要得到組織的認可，也有相應的成本代價；
2、缺乏有效的監督/反思機制：在很多組織中，是不會去反思項目為什麼會延期，分析原因並加以改進，日常項目研發監控也不能很好的落實。長此以往，項目延期會成為習慣；
3、缺乏對承諾的尊重：如同個人信用一般，很多人只把計劃當做計劃，而不是將計劃當做承諾；誠然這樣的要求似乎有點高，但是多次的延期，必然造成他人對你的不信任。
我們用的Scrum，沒錯就是大家都吵吵嚷嚷的Scrum，甚至還有人罵這玩意兒。答完後發現有點不符合Po的原題，湊合看吧。
=======================================================================我們現在做的也還不好，不過有幾點可能能給大家參考。
1、業務上達成一致
這裡的的達成一致時指的就最後要交付的東西達成一致，產品要做成什麼樣子，需要哪些資源。就是不斷的互相討論，但僅僅是業務層面的，給出用戶使用場景，但盡量別去扣技術細節。
2、結論上信任團隊
充分信任你的團隊，也讓團隊充分信任你。
讓專業的人做專業的事兒，東西只要沒做出來就是個未知的，對於未知事物的估計，研發人員自身的技能、經驗、職業素養都很重要。但是有一點 了解到團隊人員怎麼去估算時間，比一位的去扣人家自己估算的是否合理要有用的多。首先信任大家給你估算的時間。
3、過程中不斷優化
一次就達到很好的估算時間，基本不現實。了解他們的估算方式後，就可以先開始幾個周期完全信任大家的預估時間，然後做記錄，讓大家看到自己的效率是提升還是降低了，想幹事兒的不會磨洋工的，不想幹事兒的早點負分滾粗。
比較激進的程序員，欲求展現實力地樂觀估計出的時間，基本上是要乘以3，才是最後真正能上線的時間。
有經驗些的程序員會估出一個比較穩妥的時間，以應對如果開發中遇到棘手技術問題和添改需求的情況，也能加下班能解決。以避免延期對士氣的嚴重打擊。
所以工期估算跟開發者的性格與經驗相關，不能一概而論，這需要與開發團隊長期合作的默契來辨別。
早期評估出的工時，就跟有的人拍著胸脯說：「這是最最終版需求，絕不再改」，一樣
的不靠譜。
唯一可以確定的是，一定要每天溝通進度，至少每隔一周重新評估一次餘下的工作量，修正進度計劃或更改上線時間。
磨嘴皮是最大的時間小偷，要想珍惜時間，最有用的就是早定需求儘快開工，code wins arguments， 項目時間的管理精髓在於天天溝通和持續評估.1.首先要知道這個產品的地位，並不是什麼產品的進度都要求那麼趕
2.如果是領導重視的，可以定期匯總，讓領導知道，催起來也不會那麼費勁，有什麼事發生也比較不像告狀，能及時處理問題。
3.多跟客戶或者領導那麼溝通，很多進度不是死線，了解能夠延期多久，再跟工程師就延期溝通。
4.如果是又不重要又麻煩的，就放過工程師吧，大家都是出來混口飯吃。能拖就拖吧。
- 將大任務拆分成小任務分別評估。
- 組織幾個工程師同時評估，取平均值。
- 最後的時間留出 1/3 餘量，應該就比較安全了。
說實話，導致這個問題的原因很多，
很多項目，由於項目分析不到位，別人問我多久完成，
我也不能回答，
預估時間長點吧，感覺很丟人，顯得自己能力不行。
時間短點吧，其實如果沒有深入分析，就憑經驗，經常項目超時，2倍是完全就可能的。
【引言】
一個產品項目，標準的流程大致是要經歷市場調研分析、需求分析設計、技術分析設計、編碼開發、測試、驗收上線、運維等過程。按照CMMI的研發流程，對應就是立項階段、需求階段、設計階段、編碼階段、測試階段和發布階段等6大階段。
其中：
立項和需求階段，主要是產品經理的工作；
設計階段分為兩方面，一方面是產品UI設計，這主要是UI設計師和產品經理的工作，另一方面是技術設計，這主要是技術人員的工作（架構師或項目經理或直接的開發者）；
編碼階段，主要是技術人員的工作；
測試階段，主要是測試人員的工作；
驗收發布階段，主要是產品經理的工作。
以上6個階段，每個階段都有項目組成員的工作分工。當然，產品經理和項目經理是貫穿整個項目流程的（有些公司的有些項目，項目經理和產品經理是同一個角色）。
雖然互聯網產品講究的是短平快和快速迭代，工期周期都相對較短，但整體項目也需要經歷以上階段。
【分析】
產品經理在做產品項目時，工期評估通常分兩類：
1. 第一類是已有時間期限，只能按時間倒推法評估。例如根據市場或運營反饋一個緊急產品需求，需要兩個星期內上線，產品項目目標很明確，總共只有兩星期時間，包括需求分析、定義和設計，再到技術設計、編碼開發，最後測試驗收並發布上線。那麼在已有時間期限內，項目組成員其實也沒什麼別的選擇，只能按期完成。在這種情況下，產品經理要做的就是權衡每個階段的時間比，同時與項目組成員多溝通，大家都面臨時間緊迫、任務量大的現狀，只能加班加點，按期完成目標，誰都不能拖後腿（這是項目時間很明確且無法改變的情況下，也就是是領導的死命令，項目組成員必須按期完成的情況。如果還有得改，產品經理應為項目組成員爭取合理的時間和資源）。
2. 第二類是沒有死命令，可以根據正常研發流程來評估項目工期及各階段的工作時間。在這種情況下，每個階段的對應成員都要給自己對應階段的工作來評估合理的時間（當然，這是在需求已定稿的前提下來評估的）。而產品經理要做的也是合理的評估各階段的時間比，以及項目工期總協調。在這種情況下，每個成員都要對自己評估的工作時間要負責，且要在自己評估的時間內完成自己的工作，如果某個階段有延期，就會發生連鎖反應，有可能就會讓整個項目延期，而這個一般是不允許發生的。在整個過程中，產品經理和項目經理要把監測和把控整個項目進度。
【方法】無論是以上哪類情況，產品經理都要對技術人員評估的時間要信任（不僅是技術人員，其實是各成員的評估時間）。而產品經理要做的就是搜集所有成員的評估時間，與預期設定的項目工期做一個對比。如果符合預期，這是最佳效果，就按各評估時間推進即可；如果不符合預期（通常都是不符合預期的），那就權衡各階段的時間比，同時再協調。產品經理要做到這個，一個是要基於以往的項目經驗，另一個就是要看具體的項目情況。
及時溝通，是推進項目進展的必要也是最基本的要素，這不僅僅是要求產品經理這樣做，項目組成員都要這樣做。
項目中，不怕出現意外情況或突發情況，怕就怕有問題自己捂著，等到別人發現時才溝通。別人不問你，自己打死也不說的這種人，無論是產品狗還是程序猿，都是不合格的，更別提什麼扯皮了，還是自己好好反思去吧。
首先，請信任你的工程師。其次，要對這個項目有明確的時間預期。
一切成功合作都建立在彼此信任的基礎上。建立起這種信任，研發信任你，需求是靠譜的有效的，你相信研發，會為了項目努力工作，如果沒有這個前提，合作註定不會愉快。
pm在提需求時，是需要問問自己可以接受的時間底線是什麼的，為什麼是這個時候？然後，帶著你的需求去溝通。這時，有時是會需要一些說服的技巧：描述出這個項目的藍圖、預期，以及要求時間點原因，如果有彼此第一點的前提，並且在不是很過分的前提下，或許也不成太大問題。
溝通時請務必說清楚需求，讓大家理解一致。其次，如果真是一個大的項目，例如30天的項目，請叫上項目所有成員，一起分拆。把這個大的項目拆分成一個個小的需求點（用戶故事），每一個小的需求點，需要做哪些工作，每項工作需要多久，每天完成哪些任務，列個表，做個項目進度牆，大家按進度行事，會靠譜許多。
最後，pm請在實際項目中慢慢積累經驗。有技術背景的pm會好些。如果沒有，請多和研發溝通，這個項目，需要完成哪些步驟，每項步驟大致需要多久時間。如果有出乎意料的長或是短，問問原因。如此積累，會更靠譜！要麼，去學習，讓自己成為「懂」的人，再來評估；
要麼，相信程序員；
要麼，把評估30天的程序員開了，換個評估15天的程序員，如果完不成，後果你來負。
要想讓工程師報個准數, 需要養成讓工程師先做設計的習慣, 或相關產品部門拿出設計的習慣, ER模型, UML類圖, 或界面原型圖, 再根據每個細節排時間表甘特圖. 這樣靠譜點, 你今天問工程師這個要多久, 他說30天, 明天問那個要多久, 他說15天, 30天後你問怎麼那個任務還沒完成, 工程師會無辜的說: 我是說要30天, 沒說這30天都在干這一件事呀. 呵呵, 我也是悲催工程師, 干過幾年經理, 理解雙方的難處.
我在目前的公司做開發9年了，幾乎沒出現過延遲交付，很少需要靠加班來避免延遲的情況。但是我還是對準確估算時間這件事感到困惑，因為我感覺能夠達到上面效果的一大因素是，我們公司並不是一個節奏很快，壓力很大的公司。在這樣的氣氛下允許開發人員給出一個相對安全的估算時間，相對的我覺得付出的代價就是開發效率有些低下。下面說一些我認為對準確估算時間有幫助的建議吧。
第一先達成前提再開始估算。我覺得開始進行時間估算的前提有兩項，一明確需求，二明確採取的方案。明確做什麼和怎麼做之後才能談花多少時間的問題。對於技術人員來說有過相關經驗的任務可能很快就能確定技術方案。但是對於缺乏相關經驗的全新任務提出可能的技術方案，驗證可行性本身就是一個耗時的過程。這個時候一個選擇是交給更有經驗的人來確定技術方案。另一個選擇是先別忙著估計時間，先安排一個調研任務吧。給出一個限定的時間，1周，2周，1個月。如果在限定時間之後對於怎麼完成預期的目標還沒有什麼靠譜的想法的話，放棄這個這個項目不見得是什麼壞事。
第二，誰去幹活就交給誰去估計，不同開發人員之間的效率可能相差幾十倍。
第三，大任務分解成小任務進行估算，但是要為把小任務集成起來預留時間。我覺得任務的粒度分解到1至2天比較合適。
第四，工作效率是有彈性的，壓力大一點，可能效率能高一點。但是效率不可能隨著壓力無限提高。壓力下的完成時間不見得是個準確的時間，這次完成了，下次不一定能完成。這次完成了，過程很痛苦，下一次也許就不願意完成。對效率的追求應該是整個團隊的價值觀層面的事情，通過讓團隊成員分享高效率帶來的成果，讓團隊成員自發主動的在估算的時候給出一個盡量準確的時間，而不是一個盡量「安全」的時間。
000000
預測開發工期的難度比開發本身大多了。很多程序員喜歡樂觀的估計，你要把時間乘以2比較樂觀。如果你催，最終出來的產品很難保證質量
其實，這個很有可能僅僅是他的直覺。
列出更為詳盡的計劃，按照計劃執行。
同時做好，60天依舊無法完成的準備。
相信我，工程師說要30天完成
通常實際需要的是60天
所以，lz不要疑心別人故意偷懶，還是多想想30天沒完成怎麼辦吧推薦閱讀：