有些事情你們覺得不可思議，不可理解，不可能！
但是，就是有人，不假思索的就去做了。
項目要結(jié)束了，想寫個總結(jié)，總結(jié)以下系統(tǒng)設(shè)計設(shè)計上的缺陷，代碼編寫中考慮不足的地方，項目管理方面的不足。
我已經(jīng)不知道什么叫成功的項目，什么叫失敗的項目了。因為定義失敗或成功的標準不一樣，按照PMP的標準幾乎不存在成功的項目，但實際不是按照那個標準衡量的。延期8個月后還是步履蹣跚的上線了，算不算失敗，恐怕還要從經(jīng)濟的角度計算以下成本和收益，如果收益大于成本就還是成功的(當然也包括因為延期而不能去做別的項目所產(chǎn)生成本)。
項目不理想的原因是多種多樣的，但最主要的一個原因是團隊的素質(zhì)，包括每一個項目成員的素質(zhì)，和參與項目的客戶的素質(zhì)。開發(fā)團隊的素質(zhì)決定了團隊以一種什么樣的方式和客戶溝通，得到客戶真實的需求；客戶的素質(zhì)決定了他以一種什么樣的方式告訴開發(fā)團隊他需要什么樣的軟件，要解決什么樣的問題，更有可能的情況是他只知道要解決什么樣的問題，而對軟件一無所知。
編碼的規(guī)范和知識共享：在項目初期要對項目要使用到的技術(shù)有明確的評估，優(yōu)勢和不足。項目要使用的相關(guān)軟件的版本，工程的存放目錄，發(fā)布方式做統(tǒng)一的規(guī)定，避免因版本不一致造成代碼風(fēng)格的不一致。項目成員的能力是不同的，一般一個項目都會有一兩個新的成員加入，如何把以前項目開發(fā)中遇到的問題和解決思路以最快的方式傳授給新的成員就至關(guān)重要。現(xiàn)在普遍的做法是建立內(nèi)部的WIKI共享資料，發(fā)布問題，得到解決的思路，確實是個不錯的方式。但是面對面的交流也是不可少的，一次迭代完成之后應(yīng)該大家坐在一起交流一下開發(fā)中的問題和解決辦法的思路，以及對新的可能出現(xiàn)的偏離客戶需求的功能做一個討論，避免行動遲緩造成的重復(fù)開發(fā)。知識的共享不僅包括技術(shù)資料的共享，更多的是對軟件的認識和思想的共享。
技術(shù)框架：因為技術(shù)框架而成功的項目并不少見，但很少有技術(shù)框架的失敗而最終導(dǎo)致失敗的項目。很多人對框架有錯誤的認識，盲目的追求新的技術(shù)，認為只要技術(shù)上夠強了就會成就一個項目的輝煌。框架最大的一個作用就是對使用框架的成員有強制規(guī)范的效應(yīng)，使得實現(xiàn)同一個功能所需的代碼從結(jié)構(gòu)上是一致的，不管是初出江湖，還是老于世故，別無選擇，易于復(fù)用，便于維護，對于這一點項目越大優(yōu)勢就越突出。就像工業(yè)時代的來臨，以及大工業(yè)時代創(chuàng)造的輝煌，并不是因為瓦特發(fā)明了蒸汽機，愛迪生發(fā)明了白熾燈，而是一系列工業(yè)標準的建立，減少了重復(fù)生產(chǎn)，明確了社會分工，框架的作用也是如此。
面向?qū)ο蠛蛦栴}域：面向?qū)ο笫且环N思想，面向?qū)ο蟊旧韺τ谌绾蚊枋鰡栴}域明沒有太大的幫助，項目設(shè)計上的缺陷大多來源于對問題域的錯誤分析，無端的扭曲了來自客戶的問題描述，這一點已經(jīng)屢見不鮮了。設(shè)計人員過多的追求面向?qū)ο蟮脑O(shè)計模式，而錯誤的把問題域往自己設(shè)計的模式上靠，進而蠻橫無理的要求客戶改變工作方式是不明智的。這一種錯誤來源于設(shè)計人員和需求分析人員對問題域相關(guān)知識的無知。突然想起一句話：對于一個不知道自己站在那里要去那里的旅人來說再好的地圖都是徒勞的，描述的很精準。
軟件的商業(yè)價值：客戶所需要的不是一堆代碼，也不是可以秀的程序，而是要解決他遇到的問題，軟件賣給客戶，客戶不能再去買軟件掙錢，所以軟件本身不能創(chuàng)造利潤，對企業(yè)來說軟件所能做的就是降低成本，其中包括降低流程運作的成本，和便利的獲取信息以便降低決策成本。現(xiàn)在做軟件市場空間已經(jīng)很狹小了，越來越多的軟件企業(yè)向服務(wù)業(yè)轉(zhuǎn)型。更好的軟件和更優(yōu)質(zhì)的服務(wù)才能創(chuàng)造更多的價值。信息化不是軟件化，更多的是信息化的服務(wù)。
軟件所創(chuàng)造的真正價值是什么?產(chǎn)生真正價值的前提條件又是什么?
沒有創(chuàng)造價值而祈求回報即使得到了也是暫時的.
沒有人是傻子,沒有項目做總有它的原因的,很想知道!
|