許多有開發規范的企業會采用瀑布模型、V模型或迭代等模型進行開發，但是，當出現進度緊張的項目時，這樣項目會很自然地采用“Coding & Testing”的開發模式——上來就編碼、寫完代碼再測試的原始開發方式。所以那些規范看起來只是給進度寬松的項目用了，進一步說，他們認為Coding & Testing的開發模式效率是相對高的，而需求分析、設計等活動是給那些有寬裕的時間并且想讓項目看起來過程“漂亮”的項目來做的。

如果Coding & Testing的開發模式是高效率的，那么不論這個項目的進度是否緊張，都應該選擇這樣的模式，沒有理由做畫蛇添足的事情，而且也不是繁瑣的開發過程才能讓項目看起來規范漂亮，簡單才是美；如果Coding & Testing的開發模式是低效率的，那么進度緊張的項目絕對沒有理由采用這種低效的開發模式。因此，不論Coding & Testing的開發模式是高效率還是低效，只有在進度緊張的項目采用該模式，這樣的做法邏輯上是講不通的。

那么相對于軟件工程所提出的一些開發模型，Coding & Testing的開發模式是高效率還是低效的？其實，回答這個問題就像回答“是馬車跑得快還是汽車跑得快一樣”一樣容易。

軟件開發過程中，最重要的工作莫過于需求分析了，如果需求沒有搞清楚，好比目的地不清楚在哪了，此時車開得再快意義也不大。當年，華為為了學習印度優秀的軟件開發過程，在印度成了研究所，國內派了一批工程師到印度取經。國內軟件工程師看到印度軟件工程師做項目很奇怪，項目已經開始了，他們不像中國軟件工程師那樣在電腦前埋頭敲啊敲，而是大家站在白板前“爭爭吵吵”，吵著吵著，需求就吵清楚了，然后再把需求文檔化，之后還要進行嚴格地評審，進一步發現需求理解不錯誤的地方。如果讓中國軟件工程師來做這個項目，在印度軟件工程師一行代碼還沒寫出的時候，估計我們工程師已經把代碼寫得過半了！真不知道這些“效率低下”的印度人如何讓印度成為軟件產業強國的！接下來，印度工程師會依據需求設計系統測試用例，此時還可能發現少量的需求錯誤。再接下來的設計、編碼、單元測試、集成測試和系統測試一路通暢！編碼的工作量一般不會超過項目總工作量的15%，最后系統測試活動一般占總工作量的10%。而中國工程師做的項目，典型的情況是，很快地代碼編寫出來了，接著再測呀改呀，改呀測呀，沒完沒了，最后交給客戶，客戶會說這不是他們想要的，那不是他們想要的，再接著改呀測呀……最后當客戶拿到了還算滿意的產品時，項目的總工作量已遠遠超過了印度人開發方式所需要的工作量。

選擇Coding & Testing的開發模式的人們會認為，雖然事先做好需求和設計的確可以減少編碼、測試以及返工工作量，然而需求和設計本身所占用的大量的工作量足以超過它為編碼、測試、返工所節約的工作量。然而，事實與他們的臆想差別很大，省略了需求和設計，相當于把需求和設計的問題遺留到了后期去解決，其工作量會以十倍、百倍的膨脹，導致最后的測試和返工工作量非常龐大，項目延期在所難免了。

長久以來，編碼工作被視為復雜的高智力活動，因為在Coding & Testing的開發模式下的確如此：編程人員已不是純粹的程序員，他/她在編程時候頭腦中要假象出客戶的需求是什么，同時也要考慮設計問題。一個人在做一件事的同時還要考慮其它的很復雜的事情，難怪一般人編不了程序，或者一般人編了質量也很差。其實，如果軟件規模很小、復雜度很低時，不需要什么軟件工程一樣可以編出可用的程序，如同搭一個狗窩，還需要什么建筑工程嗎？然而，今天我們普遍面對的軟件，其規模和復雜度已經超出了人們同時進行幾方面工作的能力，此時，必須把需求、設計活動從編碼活動中獨立出來才可能把工作做好，比如建筑奧運鳥巢絕對不會一邊在建造一邊在考慮需求和設計。

作為漢捷研發管理咨詢顧問，我常常在培訓和咨詢過程中強調，一個IT企業能夠把軟件需求需求分析做到位了，那么他們的開發能力一定會有一個質的飛躍！最后引用軟件工程領域的經典著作《人月神話》，看看大師們是怎樣看待軟件需求的：

開發軟件系統的過程中，最困難的部分是確切地決定搭建什么樣的系統。沒有其他任何工作比確定詳細的技術需求更加困難。需求對系統的影響比其他任何一個部分的失誤都大…軟件開發人員為客戶所承擔的最重要的職能是不斷重復地抽取和細化產品的需求。