云南NG上線，苦熬了10個月，總算有成果，教訓>成功經驗。

1、系統規劃的很美好，可惜：美麗的想法，總是不能體現在實現的系統中。系統設計，不夠明細，導致執行走樣
      需要強有力的“拍板”強人

2、責任要到人，明確告知責任人，這個事情你需要負責到底！哪怕不是你的問題！
     

3、需求分析應該及時反饋到測試用例。測試用例應該完善，軟件質量的最后關卡。聯調測試嚴重缺乏，人肉太多，但測不出東西來

也有好處：     標題是有點大，昨天看規范忽然意識到，在信息內容規劃上面，廠商們做的還是很不夠。

    目前數據庫、主機的規劃是非常常見，客戶們也做的比較好的。

    我想說的是：文檔類，很多附件是直接存在主機上的，沒有放在數據庫中。

    文檔包括：（1）內部管理文件：公文等，主要在OA系統中
              （2）合同文件：包括各種業務申請、合同文檔、與客戶相關的文件
              （3）技術方案：售前提供的技術文檔，如：解決方案
              （4）培訓文檔：
               等等

    這些文檔是否應該集中、專門保存管理？指物理上的集中，如：統計放在文檔服務器中。

    每次系統割接和升級，倒換數據，這些重要文件很容易忽略。

    直接存在數據庫中？可以避免這個問題，但畢竟不直觀。

    或許應該有個專門的文檔管理系統，把各個業務系統中的文檔集中存放，統一管理。


    運營商的系統，不會每年讓都這么大規模的讓你折騰，是的，這次機遇難得！目前參加的項目，需要對原系統推翻重來，無論從數據模型，還是技術架構上，都需要進行大規模的升級改造。

    由于系統業務的復雜，雖然需求明確，前期需求分析也做的很充分，但開發人員還是需要對照原系統的代碼來開發業務邏輯。因為需求分析得再細，也細不到某個前臺錄入的數據，應該特殊處理到某個字段。

     因此開發起來效率不高，而且業務不滿足的風險極大！

     公司在需求管理方面，可以說投入不可謂不大，有專門的人，購買專門的系統來管理，但通過這次系統升級發現，之前的需求管理對這次一點幫助沒有，最多是保存了些原來客戶提的需求文檔。做分析的時候還可以，但真正指導開發，還是有一定差距！問題到底出在什么地方？怎么樣的需求管理，才能把當前系統的情況完整展現出來？

     我也不知道，我只能把現在的情況描述下來，希望有經驗的人士給點意見，在此多謝先：
     （1）需求分析：把整理的需求文檔匯總，1-2年下來，這些文檔有幾個G，一個人看下來簡直是不可能的任務，分模塊后，一般每個模塊有個需求小組來完成需求分析工作，輸出業務模型（概念數據模型），更多是讓這些人（將來的組長）熟悉自己要做的業務細節。
     （2）概要設計：主要的工作是細化概念數據模型，成物理模型。
     （3）詳細設計：我們基本沒有，因為這個工作量太大，一般到概要設計，出數據模型后，邊開發，邊做詳細設計，這時還會繼續維護物理數據模型。
     （4）代碼開發：人員流動很大，新員工很多，很多不熟悉業務，不知道要做的東西干什么的，技術和業務培訓會經常進行。這時，問題來，架構設計后，開發人員對照著原代碼的邏輯進行寫程序，因為需要了解原來的程序怎么走的，為什么這么判斷，這個工作很煩躁且必須，因為你不能丟掉原來的功能點和業務限制。

     （5）測試：這也是問題，問題就是用例的粒度很粗，沒有特別熟悉業務的人員，因此業務限制的缺失無法測試得到！

      這么看來，還是功能點的詳細設計沒有做好，業務限制沒有整理出來，如果通過非常明細的測試用例來指導開發呢？

     MBA掛了，今年繼續！
     人就是這樣子，無論之前信念多堅定，而真正輪到自己的時候，還是會猶豫。當知道自己掛了，無緣南大時，還是想到了調劑，雖然自己一再給自己強調，堅決不調劑。

      再也不想了，今年繼續更加努力！