一個程序員，同樣的東西，一個月做出來和三個月做出來到底有什么不同呢？底層架構(gòu)不同、可預(yù)見未來支持的擴展不同、優(yōu)化不同，可以這么說，從某個角度上說，是完全兩種東西。

開發(fā)時間的常用評估方式

首先，評估開發(fā)時間的問題，兩個常見的方式，***種，會從底層程序員往上報自己需要的時間，經(jīng)過主管、經(jīng)理再到總監(jiān)每一層都會多報出一個百分比的時間，以備用來解決不可預(yù)知的問題或bug，其實不預(yù)估時間的項目往往是最快的，程序員盡力去完成，但在有一定規(guī)模的項目組中卻不可取，沒有哪個老板或投資人會對沒有時間規(guī)劃的項目開發(fā)組充滿信心。企業(yè)也不會任由程序員來規(guī)定時間。而報到老板那的時間也會直接被砍一刀，三分之一的時間被砍掉都算是少的。

第二種方式，如果是合同定制的，開發(fā)需求非常明確的，一般都會有一個明確的開發(fā)周期和時間節(jié)點，開發(fā)任務(wù)會“以終為始”的方式來開展，舉個例子，六個月的工期，那么第六個月的時候交付產(chǎn)品，需求、設(shè)計、開發(fā)、測試各自匹配出相應(yīng)的時間，在這個時間段內(nèi)完成任務(wù)。只要對方不改需求，時間給的合理，這樣反而簡單了，一般情況下都可以保證deadline來之前上線交付。

開發(fā)時間被壓縮的要求，往往來自于不懂行或者沒有開發(fā)背景的老板，一方面是項目進度、企業(yè)進度這類客觀性的要求，另一方面是怕程序員偷懶，工作不飽和，自己白付工資這種主觀性的考慮，在他們的視角中，開發(fā)一套系統(tǒng)，三個月的時間成本和一個月的時間成本是一個簡單的數(shù)學(xué)關(guān)系，所謂的高層，從來不會關(guān)心你短時間內(nèi)開發(fā)的系統(tǒng)所遺留的問題，那是程序員應(yīng)該解決的事，而這些問題實際上會像滾雪球一樣一直堆積，最終在某個時間段內(nèi)集中爆發(fā)出來，后果就是重寫，而我剛好就遇到這么一起事件，項目進行半年后，那邊的負(fù)責(zé)人告知我，他們的系統(tǒng)的架構(gòu)已經(jīng)無法再加任何的功能了，只能重寫。

我們假定這個程序員的水平在中等偏上，不存在技術(shù)水平以及任何情緒的問題，一切都是按照比較公平的方式去比較，現(xiàn)在企業(yè)要做一套系統(tǒng)，需求明確度60-80%，為了簡化模型復(fù)雜度，我們只要一名程序員，這名程序員負(fù)責(zé)系統(tǒng)的所有的任務(wù)，程序員報三個月的開發(fā)時間，如果這個時間被無端壓縮至一個月，那三個月開發(fā)出來的系統(tǒng)和一個月開發(fā)出來的系統(tǒng)到底區(qū)別在哪呢？

架構(gòu)不同，決定了對未來可擴展的支持的不同

系統(tǒng)做的可大可小，關(guān)鍵看給的時間，時間不夠，即便有能力也會把系統(tǒng)做成小的、擴展性差，為什么呢？程序員都會選擇當(dāng)前環(huán)境下的***解，和時間賽跑的項目***解就是，快點上線。底層架構(gòu)？領(lǐng)導(dǎo)又不關(guān)心你操哪門子心。未來可擴展性？表示不關(guān)心，只知道項目完不成會更糟糕。反正先讓你看到個東西，管他底層是啥樣子呢。

舉個例子，你的系統(tǒng)是做一個學(xué)校的客戶關(guān)系管理CRM，實現(xiàn)客戶的錄入、分配、跟進、報名的功能。假如老板或甲方壓縮時間，給的時間不夠怎么辦，那只能做做表象的東西，一個客戶表，一個跟進表，兩者一對多關(guān)聯(lián)，再加一個用戶表和報名表，用戶表和客戶表一對多關(guān)聯(lián)，客戶表和報名表一對多關(guān)聯(lián)，完工。項目做完啦，其它不管了，也沒時間管，誰讓你給的時間少呢？那上面這套系統(tǒng)哪還有問題呢？程序員報三個月，被老板壓縮到一個月，老板是不是賺到了？

同樣的東西，壓縮時間做出來，老板真的是賺到了嗎？

上面那套系統(tǒng)，程序員未來可預(yù)見的業(yè)務(wù)擴展，但由于被壓縮了時間，所以底層架構(gòu)是按照最快最簡單的方式來實現(xiàn)的，那架構(gòu)在哪會出問題呢？問題可大了，比如：1、對方需求沒說支不支持多校區(qū)，整個數(shù)據(jù)庫設(shè)計被設(shè)計成了一個校區(qū)，想要多校區(qū)？不支持的，你們沒說，沒這個概念。2、班級的問題，你們沒提，我們也沒給你們加，一個學(xué)員可以進幾個班，一個班級可以安排多少課，是分開計課時？還是一起計課時，不管你上不上都會劃去一節(jié)課。3、補課？繳費？退費？補款？沒說啊，沒說可不沒有么？為什么我們不寫啊，我們只寫你們提的需求里的功能，謝謝。4、操作權(quán)限問題和數(shù)據(jù)權(quán)限問題，一個客戶的市場收集人、銷售分配的人、登記客戶的人是三個人？不支持，按需求合同來。5、你還要統(tǒng)計跟進次數(shù)？什么，還按部門統(tǒng)計，你們重新提需求文檔吧，先把***階段的給錢給結(jié)了。6、訪問速度太慢啦？把服務(wù)器的性能調(diào)一下，多加點錢就好了，服務(wù)器費用從每月3000增加到每月9000。

上面簡單列出了一些問題所在，有看得見的功能上的完善，還有看不見的架構(gòu)擴展，你只要不說我們就不寫，你壓縮時間，我們就壓縮你看不見的，一切以時間為準(zhǔn)。這樣的系統(tǒng)，再來幾次新需求，可能就要重翻了，重新翻系統(tǒng)的話，該花費多長時間不會減的。本來多給幾個月，這些東西全給做上了，這一壓縮時間，多花費出來的時間你還是要給程序員開工資的，別指望靠每天免費加班來榨取剩余價值，程序員離職對項目的損傷更大，并且，項目是公司的，公司是老板的。上有政策下有對策，所以業(yè)內(nèi)有句話是這么說的，得罪誰，也別得罪程序員，否則，***你怎么死的都不知道。而這句話并不是危言聳聽，覺得程序員老實好欺負(fù)的老板的最終下場都很慘烈。

除了功能和架構(gòu)以外，還有什么？

那除了功能、和架構(gòu)以外，還有什么“本應(yīng)該可以做”，但由于時間原因沒做的呢？性能監(jiān)控和優(yōu)化、緩存、日志分割和備份、數(shù)據(jù)庫備份、代碼重構(gòu)等等等等，這些東西你做了，別人看不見，不做，對系統(tǒng)交付也不會產(chǎn)生問題，時間緊任務(wù)急，被時間壓急眼了，不做也罷。