用新的技術。而這一切走向極端就會讓研發(fā)陷入不可控制的地步。在我做物流和教育平臺產(chǎn)品的時候，都遇到了這樣的問題。架構(gòu)師希望產(chǎn)品做得更大，滿足更多的業(yè)務需求，同時又希望幾乎每個業(yè)務模塊組件化，具有更多的通用性，采用盡可能新的技術。最終造成計劃的一拖再拖，讓公司領導層喪失信心。第二種情況在一些規(guī)模較小的產(chǎn)品研發(fā)中也很常見。技術領導人在時間、資金或PM的壓力下基本上放棄了軟件品質(zhì)的追求。他們只希望在規(guī)定的時間內(nèi)盡快做出一個東西就行。他們基本上不太考慮組件性、擴展性等等。這樣做出來的產(chǎn)品和項目也就差不多了，因為他的通用性、擴充性太差?？梢钥闯觯@兩種情況都可能導致產(chǎn)品的失敗。第一種總是想一口吃成一個胖子，他們忽略了軟件開發(fā)的跌代性，軟件總是在不斷的跌代、更新中，螺旋式上升發(fā)展的。而第二種則是技術人員的悲哀，他們沒有條件去追求軟件的品質(zhì)，只能寄希望于產(chǎn)品的下一個版本。事實上，沒有前一個版本良好的框架，新的版本要想做好，幾乎是重新開發(fā)。所以一個優(yōu)秀的架構(gòu)師，既要不放棄心中的完美主義的理想，又要對現(xiàn)實做一定程度的妥協(xié)，在這種平衡中，領導團隊進行技術開發(fā)。事實上，在中國軟件產(chǎn)業(yè)的現(xiàn)階段，急功近利的公司太多了，他們不會提供更多的條件、更多的空間讓架構(gòu)師去實現(xiàn)一個優(yōu)秀的產(chǎn)品。這是我們所有做軟件技術人員的悲哀，這是所有想走向、或正在架構(gòu)師崗位上的人員的悲哀。
在軟件產(chǎn)品開發(fā)的這一階段，除了以上的情況，還有許多問題同樣會導致產(chǎn)品的失敗。例如公司對軟件工程的理解和掌握。軟件工程強調(diào)使用過程來保證項目的成功，一般都會提出一整套的理論，如一些核心流程、步驟、方法、規(guī)則等等，例如RUP,XP。有很多項目經(jīng)理、架構(gòu)師和軟件公司的高層都希望去使用這些方法，以保證項目、產(chǎn)品的成功。特別是公司的上層領導，他們只能通過這種方法來保證對項目的控制，所以特別熱衷于實施這些方法。然而事實上呢?。大家都常有這樣的經(jīng)歷：
為了文檔而寫文檔，寫出來的文檔基本上可以扔進垃圾箱，沒有任何作用了。我這樣說，并不認為軟件工程有什么不好，關鍵在于你怎么去使用它。軟件工程是一門實踐性很強的學科，需要我們根據(jù)不同的現(xiàn)實情況不斷的調(diào)整、實施，而不是照本宣科的一些教條。最怕遇到這種情況：
一些領導或項目經(jīng)理讀了幾本軟件工程的書，自以為找到了靈丹妙藥，就開始在項目中強力實施。比如制訂一些步驟、計劃，在什么什么時間，達到什么什么成果，要寫什么什么樣的文檔等等。在我以前做教育軟件產(chǎn)品中就充滿了這種傾向。了在某為一時間交出架構(gòu)設計文檔，我們大部分時間不是去考慮、驗證架構(gòu)，而是為了寫出這份文檔。結(jié)果是，到我們要去實現(xiàn)時，發(fā)現(xiàn)根本行不通，整個架構(gòu)存在嚴重的問題，到這個時候再回頭重做設計，代價太大了。個人感覺是，要合理的使用一些軟件工程理論，需要項目經(jīng)理、架構(gòu)師有豐富的實踐經(jīng)驗，能夠根據(jù)不同的產(chǎn)品研發(fā)情況，制訂自己的一些確實可行的方法。軟件工程是一些通用的理論，從來而且應該是可以靈活裁減的。四、其他步驟 如果說上面的步驟都很好的做到了，那產(chǎn)品應該說基本上成功了。有了一個合理的的架構(gòu)設計，那么詳細設計和編碼應該不是一個問題，這只需要我們的軟件工程師的努力就可以了。當然測試是很重要的，但基本上不會導致產(chǎn)品的研發(fā)失敗。