1樓：
樓上諸多答案沒有考慮到的一點是：並非程式設計師估不出來，而是不敢說。
乙個模組分給你，老闆心中的底線是兩個月做完。你說，「這模組估計要做四個月」。呵呵。
然後這個模組給你旁邊的小X做了因為此人說「乙個月做完」。後來他做了乙個月果然做完了，又花了三個月改bug。
於是你就學會了「100分的東西，你60分也是做，做100分也是做，做120分也是做」。
你估乙個四倍的時間然後慢慢寫固然好，但客觀條件不允許。你只能估乙個做60分的時間。所以你每次時間都不夠，然而這又有什麼關係呢。
不是你不願意估更多時間，而是老闆們不允許你估那麼久。
2樓：
專案計畫進度表誰做的？請他出來對此負責！
專案經理是誰？請他出來解釋一下！
人力估算不夠，需求範圍邊界控制不住，由於需求變更導致的合理延遲都可能是延期的原因。
3樓：邢二二
程式設計師，尤其是剛畢業的新手，沒經驗，又老實。 盲目地自信，加上領導給點壓力/鼓勵，想提高productivity. 看了幾個高優先的功能就估計出個時間，其實坑了自己也坑了隊友。
老老實實的按照輪子哥說的，x4！
4樓：花生
乙個月，通通乙個月，小公司老闆只給乙個月...
不過老闆也只給個大概的需求，嗯，邊做的時候邊細化，然後具體到某一項的時候再加時間，最後做出來的bug眾多慢慢改
我看過有承諾乙個月做完實際花了一年半還bug眾多最後爛尾的專案
5樓：
曾經做過乙個專案。因為裡面某個模組在國內沒找到（找到我之前）有這方面知識的（技術太老），專案經理估了一年。我恰好懂這個技術，於是被招進去做。
最終，搭環境、設計、編碼、測試等等，不到三個月搞定。剩下9個月，幫別的部門打雜，然後學C++，然後跑了。。。
所以看到 @vczh 說的乘以4，立馬high了。
6樓：
侯世達定律：做事所花費的時間總是比你預期的要長，即使你的預期中考慮了侯世達定律。
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
侯世達定律指做複雜任務需要花費的時間總是很難預計的。[2]
7樓：SillyForce
很簡單，估時間的人經驗不足，總是用「功能實現」這種POC性質的標準去估算產品開發時間。
舉個最簡單的例子來講，乙個寫檔案的程式，乙個大三學生不借助高階庫用C十分鐘就寫出來功能了，但是考慮到不同編碼，語言支援，目錄長度，移植性，程式效率，硬碟讀寫速度，檔案型別，執行緒訪問，重入性等等等等吧反正，我估計你如果沒做過，沒踩過所有的坑，一小時寫不出個差不多像樣的程式，一下子你扔進去六倍時間不奇怪。～
8樓：William
軟體開發的一大特點就是需求永遠在變，而且無法在一開始就確定清楚。因為使用者在看到可工作的產品之前，並不能明確定義自己需要什麼功能。
所以要準確的估算專案完成時間，最有效的辦法就是縮短迭代的週期，增加反饋的頻率。持續交付就是一種很有效的解決方案，對產品的任何修改，都能夠以最快的時間反饋給使用者；開發團隊也可以根據使用者的反饋，隨時調整開發進度和技術方案。所以專案最終完成的時間一般是在專案開始一段時間以後，甚至在後期才能被最終確定。
遊戲程式設計師如何使用自己的時間完成一款獨立遊戲？（手遊）？
業餘時間山寨過幾個小遊戲，純粹自己娛樂。沒想過要賺錢或者滿足創作慾望，因為都是抄的也沒臉宣傳。不過做的時候倒是有點心得，個人作品還是要根據作者自身的特點揚長避短。如果本身不擅長美術那就先不要染指靠美術效果出彩的遊戲型別。可以先通過一些風格化的取巧方式把美術部分繞過去，完成整個遊戲。然後再回過頭來考慮...
如何從程式設計師轉型專案經理
啊哈時刻產品經理 從程式設計師轉型專案經理，是從執行層轉管理層，算是一種質的改變，有不少需要注意的。我本人是研發轉專案經理後再轉產品經理，經歷過這個階段，可以分享下自己的經歷。管團隊。從單純接受工作安排按要求完成工作任務，到確定團隊目標給團隊成員分配工作任務，要學習和調整自己的工作習慣和工作方式。首...
程式設計師沒完成任務怎麼解雇
勸退吧，讓他自己辭職。好的的程式猿，不在乎換工作 不好的程式猿，留著也是公司負擔，你累他也累。規定時間內完不成任務的可能很多 1.技術難度超過預期 2.計畫的時間太短 3.負責的專案本身不是他所擅長的領域 4.要維護的專案很多，公司規定的時間被其它專案的維護任務頻繁占用 5.任務時間內變更需求，導致...