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