抖音上有很多程序員和產(chǎn)品經(jīng)理的段子。說產(chǎn)品經(jīng)理提的需求有多無理的，那只是段子而已?，F(xiàn)在產(chǎn)品經(jīng)理也是一種競爭很激烈的行業(yè)，如果有，那也做不長久。

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

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

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

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

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

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

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

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

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