抖音上有很多程序員和產品經理的段子。說產品經理提的需求有多無理的，那只是段子而已。現在產品經理也是一種競爭很激烈的行業，如果有，那也做不長久。

說到底產品需求在前，開發在后。而需求是動態變化的，開發卻是基于最開始的需求，所以確實會存在做完后，發現功能沒用的情況。這種情況很大一個原因是軟件是一個虛的東西，沒做完之前，摸不著看不到的，所以就不一定是客戶和用戶需要的。這種解決方案就是短周期迭代開發，讓一部分功能先上線驗證。我見過的大部分企業，迭代周期都在1-2周。最高不超過4周。

至于另一種產品經理沒思考好，等開發做了一半，來修改需求的。這種情況，需要開發和產品都提高理解需求的能力，對，開發也需要。因為說到底，軟件做出來長啥樣是程序員決定的（生產者）。只有理解了需求，才能做好需求。

越是排期長的版本，時間也越不可控。雖然大家都會做計劃，但因為工作量是偏主觀的，每個人的準確度并不一樣。所以項目的整體工作量經常不準確。那如何解決這個問題？

1、每天的工作排期，除了正常的編碼時間，還要考慮會議、電話以及其他相關活動時間。

2、不要計算工作量完成的百分比，而應該測算剩下多少工作量沒完成。如果最初估計完成時間是40小時，而開發了30個小時之后，你認為還需要另外30個小時才能完成，那就如實說明情況，并調整計劃。通過加班或者加快其他任務來解決。

3、為每次完成時間與真實的預估時間做一個對比，如果你評估2天，實際花費6天，那么兩者系數為3，那么下次你評估的時候就乘以3。通過多次調整，就會趨于正常。特別是管理者要幫助下屬建立正確評估工作的能力。

4、測試時間，大版本的測試時間會超過預期，主要還是測試出的問題太多。這需要在平常加強自測，比如使用單元測試之類的工具，輔助開發。另外就是達成共識，不是所有的測試問題都要修復，給bug分等級，等級低bug是可以放在下一個版本處理的。

5、最重要一點是，到底是時間不夠，還是時間都被一些娛樂事物給使用了。反思自己的有效工作時間。

說到測試，現在的對bug的定義會更嚴格些。 每一個用戶抱怨的點，都算bug。包括體驗（操作上）。如果代碼問題解決不了，可以考慮通過修改文檔或者培訓來彌補。