软件项目实施总结
一．空洞的總結上個星期幫一個朋友看了一個項目實施方案，讓我提出一下建議，我剛開始不是很感冒，后來覺得應該給人家意見把，才冒出來系統(tǒng)去整理一下項目實施的東西。先簡單回憶一下項目實施的一些東西，然后整理一點東西出來。??1. 項目組組建1.1多方項目組成員給出多方項目組成員組成。很多吃過虧的客戶，在搭建項目組的時候，甚至在招標書的時候，要求軟件公司的項目組里面必須有項目管理專業(yè)人員，甚至持有pmp證書，或者有專業(yè)的需求分析人員，并持有系統(tǒng)分析證書。1.2 多方項目小組成員的穩(wěn)定性多方項目小組成員的穩(wěn)定性。人員流動通知對方，申請多方認可。特別是相關負責人流動，需要多方確認。2. 實施的進度日程表給出系統(tǒng)上線日程表3. 軟件模塊實施的先后順序先上哪些模塊，后上哪些模塊。新系統(tǒng)和老系統(tǒng)并行運行的機制處理方式。歷史數(shù)據(jù)的處理方式。4.進入新系統(tǒng)的數(shù)據(jù)截斷日期。5.實施中多方會晤機制定期會晤機制？1周幾次？還是每幾天1次，每天1次？6.監(jiān)理方的立場說明監(jiān)理方代表的是甲方的利益，出現(xiàn)沖突的時候應該從維護甲方利益出發(fā)，考慮問題。7. 問題診斷機制實施出現(xiàn)問題時候，監(jiān)理方應該要協(xié)助甲方診斷問題的類別，是來自于硬件提供商，還是軟件提供商，還是甲方的問題。如果不能診斷，應該主持召開多方會議確認問題的來源，類別。8.問題的響應速度要求當問題被診斷后，應該要求問題解決的時間，要求相關單位在規(guī)定時間內解決。如果問題不能在指定時間內解決，應該要考慮補救措施。9.需求變更處理當甲方提出需求變更后，監(jiān)理方應該作出判斷，這個需求是否合理，是否超出了實施前制定的需求基線，如果超出了需求基線，就有可能需要追加預算了。當然軟件需求變更存在一個工作量的問題，如果工作量較小，就不存在甲方追加預算。一般的項目實施都是有1個需求基線，然后免費的需求變更工作量有1個上限，當需求變更的工作量超出這個上限，就需要甲方追加成本了。10. 甲方2次開發(fā)的難度控制當在設計甲方業(yè)務處理流程的時候，應該要考慮到甲方業(yè)務流程 更改后，系統(tǒng)的可配置性。這1點也是j2ee的主要特點體現(xiàn)。當然，如果系統(tǒng)使用了工作流產(chǎn)品的話，可以從工作流角度來考慮解決。11. 財務核算處理方式的靈活能力一般的企業(yè)單位，財務核算的方式是比較固定的，但是也會作變動，當這一塊作出變動時候，應該要求軟件系統(tǒng)能夠比較好的能夠實現(xiàn)。例如：軟件系統(tǒng)以前實行的是集中財務管理，后來改變成為半集中方式，或者分散方式。這寫都要秋軟件系統(tǒng)能夠很好的實現(xiàn)能夠很好的進行業(yè)務處理方式的平滑過渡。12.甲方業(yè)務流程的整理監(jiān)理方作為甲方利益代表，應該和甲方一起協(xié)助億方指定出甲方的業(yè)務相關流程，在甲方乙方有爭論的地方進行協(xié)調，并且在流程指定時候應該就要考慮到流程的更改。監(jiān)理方當然最好能夠先幫助甲方進行流程改那就更好了。或者乙方能夠提供工作流工具就好了，否則這部分工作會暫用監(jiān)理方相當多的時間。另外需求搜集變更也會監(jiān)理方需要高度關注的一件事情。軟件項目實施總結2—項目實施中的數(shù)據(jù)管理
軟件項目實施總結2—項目實施中的數(shù)據(jù)管理
管理信息系統(tǒng)實施成功三大因素依次為：人、數(shù)據(jù)、技術，也許有些人不完全認同，但是數(shù)據(jù)的重要性是大家不可否認的。
為了更好的進行軟件系統(tǒng)的數(shù)據(jù)管理，應該從組織機構角度來做考慮，建立單獨的組織機構來管理數(shù)據(jù)相關工作，或者在實施小組里面專人總負責 。
軟件開發(fā)商和客戶核心的業(yè)務骨干一起制定數(shù)據(jù)規(guī)范，客戶提供符合規(guī)范的業(yè)務數(shù)
據(jù)，只有符合規(guī)范的數(shù)據(jù)才能進入系統(tǒng)。
強調客戶和軟件開發(fā)商的2方項目組成員做到“不能有‘我以為’的思想”，一旦有如此思想，很容易陷入閉門造車，項目需求很容易走樣，因為客戶à所有的客戶，也是在‘我以為’。項目組要想做到控制住需求，一定要拋開自己的設想。所以任何一個項目組成員，第一句話就告訴他，不要有“我以為”的想法。把’我以為’變成’客戶認為’(最好是客戶和軟件提供商一致認為)，這才是最重要的。
呵呵，這又回到了項目管理上。我在這里實際上只是想從數(shù)據(jù)管理這個更具體的角度來闡述問題。
同一數(shù)據(jù)必須一次、一處進入系統(tǒng)，保證其準確性，及時性和完整性和入口的單一性。
管理控制一體化是系統(tǒng)的目的，如果一個數(shù)據(jù)在多個地方存儲，很容易造成數(shù)據(jù)的不一致。
雖然上面提到了數(shù)據(jù)存儲的單一性，但是有些時候也需要存儲副本數(shù)據(jù)。存儲這些
副本數(shù)據(jù)的目的就是為了在使用數(shù)據(jù)副本的地方不受到數(shù)據(jù)源的變化的影響。
例如：數(shù)據(jù)1在業(yè)務A進入系統(tǒng)，業(yè)務B使用到了數(shù)據(jù)1，但是為了避免在業(yè)務B使用了數(shù)據(jù)1后，業(yè)務A又把數(shù)據(jù)1的修改影響到業(yè)務B，那就需要業(yè)務B在使用數(shù)據(jù)1時候保存副本。
比如：城市拆遷資源計劃系統(tǒng)( http://www.netsky-tech.com/)的拆遷合同在使用房源業(yè)務錄入的房源房屋面積信息時,就使用了副本機制，在合同使用房屋面積時候，把面積信息存儲下來，當合同構筑完成時候，如果相應的房屋面積信息發(fā)生了變動，就用另外的業(yè)務來處理這個數(shù)據(jù)變動的相應處理（比如，使用房源的差價款合同來處理）。
有朋友建議用配置管理系統(tǒng)，把數(shù)據(jù)版本機制引入了業(yè)務數(shù)據(jù)里面.做過J2EE的項目，
都知道很多地方可以通過配置來進行管理。其實這個思想延伸到數(shù)據(jù)庫模型的設計時候，就體現(xiàn)出來了業(yè)務數(shù)據(jù)的配置管理的思想的使用。
我們其實也有是用這個思想，但是主要體現(xiàn)在 在基于數(shù)據(jù)表級別上 用數(shù)據(jù)級別+歷史
編號 來識別有效的數(shù)據(jù)。1個很簡單的例子：
一個員工的姓名原來 是aa, 后來改委bb，可以通過 歷史編號 找到原來 的信息是bb
通過數(shù)據(jù)級別識別現(xiàn)在的有效數(shù)據(jù)是aa，我們把數(shù)據(jù)版本控制更多的是采用’數(shù)據(jù)級別’加’歷史編號’另外還加上了一個’生效日期’, ‘截止日期’這2個時間戳.
另外，實際軟件系統(tǒng)的歷史業(yè)務數(shù)據(jù)進入系統(tǒng)就比較煩，可能需要使用版本管理機制來處理才行得通。
5.建立數(shù)據(jù)等級制度
軟件項目實施中業(yè)務規(guī)則經(jīng)常會陷入一個兩難的境地，如果業(yè)務規(guī)則加強，很多數(shù)據(jù)數(shù)據(jù)達不到規(guī)范化的要求，無法入機；如果放寬控制，很多垃圾數(shù)據(jù)就進入了，大家都明白一個道理，對于軟件系統(tǒng)，垃圾數(shù)據(jù)進去，肯定是垃圾數(shù)據(jù)出來，統(tǒng)計查詢結果肯定是這樣的。
? ? 可以建立數(shù)據(jù)的等級制度，制定數(shù)據(jù)進入系統(tǒng)的最低要求。達到最低要求才能進入系統(tǒng)，
比如：
? ? 業(yè)務A,需要數(shù)據(jù)a1,數(shù)據(jù)a2,數(shù)據(jù)a3, 數(shù)據(jù)4。我們可以制定進入系統(tǒng)的關于業(yè)務A的條件是必須要有數(shù)據(jù)a1,a2才可以進入系統(tǒng)（也就是最低要求），如果提供的業(yè)務數(shù)據(jù)同時有數(shù)據(jù)a1,數(shù)據(jù)a2, ,數(shù)據(jù)a3,那就是更高一級的數(shù)據(jù)（第二級數(shù)據(jù)），如果業(yè)務數(shù)據(jù)在滿足第二級數(shù)據(jù)的基礎上，提供了數(shù)據(jù)4，那就是第三級數(shù)據(jù)。
? ?如果用過J2EE平臺的同行理解起來就比較容易，這實際上就是JMS基于主題的消息管理思想用于軟件系統(tǒng)一個具體例子而已，這里不過是強調的是用于管理數(shù)據(jù)的信任等級而已。
? ? 其實很多軟件項目開始制定的的數(shù)據(jù)規(guī)范，一般到后來都執(zhí)行不下去，主要是太理想化了，也許只有到系統(tǒng)真正用起來了，系統(tǒng)數(shù)據(jù)的信任等級才能上去。所以我覺得應該在系統(tǒng)開始時候就把數(shù)據(jù)分等級，不同的等級，業(yè)務給與適當不同的處理，這樣也便于后期的業(yè)務進行查詢統(tǒng)計分析或者數(shù)據(jù)挖掘。
這種思想實際上就是將數(shù)據(jù)可以信任的程度進行分類；而一般的軟件系統(tǒng)是把數(shù)據(jù)定義為兩類，可以進入系統(tǒng)，不可以進入系統(tǒng)；我在這里設想的是，從數(shù)據(jù)可以信任的角度出發(fā)，分成多種類別，使用了一個小數(shù)來描述信任程度，而不是一個二值邏輯變量來描述；這樣從建立軟件系統(tǒng)整體模型的時候，把數(shù)據(jù)信任管理納入考慮之內，在進一步作業(yè)務分析，決策支持或者數(shù)據(jù)挖掘時候是比較有好處的；當然進一步延伸可能就需要從OLTP/OLAP混合建模來考慮，不過真要到那個高度，可能項目范圍就擴大了很多，具體怎樣操作，還要看項目具體情形。
當然，在軟件項目實際操作的時候，可能還會遇到另外一個問題，很可能用戶會亂用這個數(shù)據(jù)信任程度的概念，我個人的建議是在項目實施中如果可能的話，優(yōu)先進入信任等級高的數(shù)據(jù)，然后才是信任程度低的數(shù)據(jù)；當然也可以從人員來角度作為切入點，信任等級越低的數(shù)據(jù)，進入系統(tǒng)就需要的業(yè)務更熟悉的人員來操作錄入，而且經(jīng)過的業(yè)務處理步驟就越多。一句話，數(shù)據(jù)信任程度越低，就應該受到的審查/檢察越多。
參考：數(shù)據(jù)信任等級圖
6.數(shù)據(jù)來源管理
在現(xiàn)實中稍微規(guī)模大一點的軟件系統(tǒng)涉及到的組織機構都是比較大的，有很多還可能是松散的組織管理模式。在這類組織機構中，同樣的業(yè)務數(shù)據(jù)可能很多部門都會是數(shù)據(jù)錄入點和數(shù)據(jù)分析點，為此可以從數(shù)據(jù)采集/來源角度來描述數(shù)據(jù)本身。
從當前項目利益來說，數(shù)據(jù)來源管理方便數(shù)據(jù)查詢分類，長期來說可以建立起數(shù)據(jù)信任等級。
對于數(shù)據(jù)來源的識別，一般需要有特定信息來記錄數(shù)據(jù)的來源，特別是一些大型企業(yè)當然分支機構較多的公司企業(yè)政府，也應該這樣來管理。
事實上，數(shù)據(jù)來源管理是數(shù)據(jù)信任管理的進一步延伸，是數(shù)據(jù)信任管理的前置條件。一個數(shù)據(jù)，可以是來自于A部門的也可能是來自于B部門的。為了方便統(tǒng)計查詢和數(shù)據(jù)信任管理的加強，應該記錄下數(shù)據(jù)的來源地。
具體操方式可以有以下幾種：
1)? ? ? ? 數(shù)據(jù)錄入人員的工作人員編號，知道了數(shù)據(jù)錄入人員的編號，就知道數(shù)據(jù)的來源地。
當然，實際工作種存在人員調動，替操作（1個人用另外一個人的身份進入系統(tǒng)數(shù)錄入），
這些都有可能需要考慮到，否則可能造成數(shù)據(jù)來源管理失效。
2)另外一種方式就是直接記錄數(shù)據(jù)錄入的部門編號。
??這種方式弊端就是不能記錄下數(shù)據(jù)的具體操作人員。
其它說明：如果系統(tǒng)中引入了工作流產(chǎn)品，數(shù)據(jù)來源這部分工作可以由工作流來擔任。
具體例子：
在現(xiàn)實的軟件系統(tǒng)中可能存在一個主數(shù)據(jù)庫/數(shù)據(jù)中心，若干分數(shù)據(jù)庫/數(shù)據(jù)中心，系統(tǒng)在每過一定時間進行數(shù)據(jù)上傳/下載，為了進行數(shù)據(jù)合并和控制數(shù)據(jù)的修改，應該每個分數(shù)據(jù)中心只能處理修改自己的數(shù)據(jù)，可以查詢總數(shù)據(jù)中心/其他分數(shù)據(jù)中心的數(shù)據(jù)。如果沒有引入數(shù)據(jù)來源管理（數(shù)據(jù)屬地管理）和數(shù)據(jù)版本的控制機制，不知道系統(tǒng)在作數(shù)據(jù)中心合并會怎樣子？
7.數(shù)據(jù)項的分類編碼
數(shù)據(jù)項的分類編碼,實際上是數(shù)據(jù)項來源管理的一個具體延伸。數(shù)據(jù)項編碼的目的就是更快更好的識別數(shù)據(jù)代表的業(yè)務意思。一個典型的例子就是ERP中的BOM表（基本物料清單）.
數(shù)據(jù)項的分類編碼,不只是在系統(tǒng)模型建立上有指導意義，在進入系統(tǒng)的業(yè)務數(shù)據(jù)的規(guī)范化同樣有指導意義。
數(shù)據(jù)項的業(yè)務編碼和系統(tǒng)編碼分離。業(yè)務編碼很多時候只是為了識別業(yè)務數(shù)據(jù)的需要，很難保證業(yè)務數(shù)據(jù)的唯一性要求。而且業(yè)務編碼可能會發(fā)生變動，有些單位的總體規(guī)劃從調研到討論制訂、到項目審批通過，再到最終實施，常常幾年過去了，需求發(fā)生變化，這種編碼規(guī)則不發(fā)生變動幾乎不可能。2000年我參與的一個企業(yè)軟件系統(tǒng)，就一個產(chǎn)品編碼規(guī)則2個月就發(fā)生了5次變動。從更長的時間范圍內來說，應該考慮數(shù)據(jù)產(chǎn)生時期問題，不同時間階段產(chǎn)生的業(yè)務數(shù)據(jù)，使用的業(yè)務規(guī)則不一樣，數(shù)據(jù)編碼這個層次很多時候很難識別數(shù)據(jù)當時的業(yè)務環(huán)境。
以一個簡單的例子來說明：
業(yè)務數(shù)據(jù)表的primary key系統(tǒng)應該是系統(tǒng)定義的，而數(shù)據(jù)項的業(yè)務編碼只能作為索引或者備用鍵使用，這樣就減少了數(shù)據(jù)業(yè)務編碼規(guī)則的變動對系統(tǒng)影響減少到更小的程度。
8.算法的版本化
本來我打算在前面的基礎上，再談一下業(yè)務流程的管理設置問題，不過，現(xiàn)在工作流思想深入人心，我也就跳過了。我打算從數(shù)據(jù)的核心業(yè)務處理，算法處理角度來闡述。
其實在現(xiàn)實中的軟件項目中，大家提到的較多的BPR,工作流這些東西，但是很少提到
算法這個單詞。當然，不可否認，很多軟件項目，特別是電子政務/OA的業(yè)務主要是體現(xiàn)在
流程/文件上，算法這部分比較簡單（當然，我這樣說，有人可能不認可，暫且就不爭論它了），就沒有必要去強調算法的重要性了。
為了避免垃圾數(shù)據(jù)進入系統(tǒng)，垃圾數(shù)據(jù)出來，有必要對數(shù)據(jù)進行分類管理。正如前面提到的那樣，對于進入系統(tǒng)的數(shù)據(jù)，進行信任等級劃分，數(shù)據(jù)來源的分類；但是對于系統(tǒng)出口，為了避免出現(xiàn)垃圾數(shù)據(jù)，需要在數(shù)據(jù)處理階段，也要進行分類處理，這里就引入了算法的版本化，來適應不同的數(shù)據(jù)/業(yè)務需要。
在實際項目中，可能不同信任等級的數(shù)據(jù)，采用不同的算法去處理數(shù)據(jù)，這樣才使得數(shù)據(jù)的處理更有針對性，更符合實際需要。
從需求變更的角度出發(fā)，軟件開發(fā)商可以先實現(xiàn)一些數(shù)據(jù)信任程度低的算法，然后再根據(jù)項目實際情況，決定是否實現(xiàn)更高一級數(shù)據(jù)等級的算法。在現(xiàn)實軟件項目，數(shù)據(jù)信任等級低的采用的算法也會簡單一些，由于需求變更，增加了新的數(shù)據(jù)信任等級更高的數(shù)據(jù)，這時候可以考慮暫時采用低等級的算法進行處理，然后再結合人工干預，達到數(shù)據(jù)處理的要求。大家都明白一點，算法復雜，測試的難度就大，但是使用這些更高等級的算法的幾率是很少的，處于成本的原因可以把這些算法的實現(xiàn)滯后。
當然我這樣說，并不是意味著放棄高等級的算法，一些根據(jù)項目實際情形需要來操作。? ?? ?
數(shù)據(jù)根據(jù)信任程度分成等級，呵呵，這就是所謂工廠方法模式嘛，算法也分成等級結構，這就是所謂的模板方法模式。
數(shù)據(jù)在處理后，應該記錄下被使用的算法版本，這樣才便于以后統(tǒng)計查詢分析或者數(shù)據(jù)挖掘之類工作的開展。
例如：在一個商品交易中，一個商品可能被購買的價格是正常價格，節(jié)假日優(yōu)惠價，會員優(yōu)惠價，在交易流水賬中，應該記錄下交易時候是采用的那個價格類型，原始價格多少，實際購買價格多少。記錄下原始價格，是因為，商品的原始價格本身可能是變化的。
再以拆遷資源計劃系統(tǒng)( http://www.netsky-tech.com/))為例，房屋補償?shù)膬r格價格可能是來自于管理參數(shù)，也可能是來自于申請，實際到底是來自于哪個，算法應該記錄下來。
9.業(yè)務規(guī)則使用的版本化
前面已經(jīng)提到了數(shù)據(jù)錄入的版本化，還有算法的版本化，也就是計算結果的版本化。但是還沒有談到一點，到底啥時間該采用哪個版本算法。
在J2EE項目中，一般是采用配置文件的方式來控制版本。從配置管理角度的來說，一切都根據(jù)配置文件來決定使用哪個版本的數(shù)據(jù)錄入的分級(數(shù)據(jù)信任程度分級)，然后根據(jù)配置文件決定數(shù)據(jù)處理使用的算法版本。
其實在J2EE項目中，可以采用類似apache commons-validator這樣的包，來進行數(shù)據(jù)錄入的信任等級建立。
前面都已經(jīng)提到了從工廠方法模式的角度來建立數(shù)據(jù)信任等級制度，但是并沒有解決到底啥時間采用哪個方法處理數(shù)據(jù)。也許有人建議，采用工廠方法模式的思想，把數(shù)據(jù)當成產(chǎn)品，把算法當成工廠，來處理（注意：不是制造）數(shù)據(jù)。這個想法也許能夠滿足一些系統(tǒng)的需要，但是更多時候是失效。
為此，我覺得有必要把算法的分配使用當成為一個業(yè)務管理策略來管理，通過單獨的業(yè)務模塊去設置業(yè)務的算法管理策略，可以把這些策略保存為配置文件或者直接保存到數(shù)據(jù)表；在J2EE項目中，常用的方式使用XML的格式保存為配置文件，但是如果這個策略比較復雜的時候建議還是保存到數(shù)據(jù)表。
10.補充說明
? ?由于最近事情比較多，對于項目實施中的數(shù)據(jù)管理先整理這些，有空的話，再繼續(xù)整理。
大家如果有興趣，可以切磋交流一下.
數(shù)據(jù)分級及算法版本化的思想對于較復雜的業(yè)務系統(tǒng)來說是非常重要的.
用戶及開發(fā)人員都不會希望系統(tǒng)在運行時中有太多的垃圾數(shù)據(jù), 但這與現(xiàn)實情況往往是個矛盾,現(xiàn)實數(shù)據(jù)采集往往是由人手工完成的,故收集回來的數(shù)據(jù)五花八門,系統(tǒng)如果沒有數(shù)據(jù)分級的處理,那么結果可能是實施不下去導致用戶滿意度下降,并且開發(fā)人員整天處于救火狀態(tài)(不管是
為了處理無窮盡的垃圾數(shù)據(jù)還是為了降低數(shù)據(jù)限制以讓現(xiàn)實數(shù)據(jù)進入系統(tǒng)).算法的版本化與數(shù)據(jù)
的分級是相關的,不同級別的數(shù)據(jù)需要不同的算法來處理,不同時期的數(shù)據(jù)可能需要不同一算法來
處理等等. 軟件項目實施總結3—項目實施中的數(shù)據(jù)管理2
這算是最后一個軟件項目實施總結，寫的簡單，算是結束這個自己定下的任務了。具體內容如下。
數(shù)據(jù)精度
數(shù)據(jù)精度問題，數(shù)據(jù)單位問題。數(shù)量的上下文。
數(shù)據(jù)處理中的定點數(shù)，和float數(shù)。實際上在一些數(shù)據(jù)中間運算中，不管那種方式，都會丟失精度。雙方要在這方面做出約定。中間結果四舍五入的使用原則，保留精度，最后結果的精度。
在一些加權計算中，中間計算會丟失精度，為了不影響最后結果，可以考慮使用減法的原則，把結果確保達到業(yè)務要求。
說道數(shù)據(jù)精度，就又牽涉到數(shù)據(jù)的業(yè)務描述的詳細程度。當然如果從模糊數(shù)學來解釋可能更好解釋。我在這里引入目錄樹的數(shù)據(jù)描述方式，或者說是用基于主題的方式來描述業(yè)務數(shù)據(jù)。
數(shù)據(jù)單位
一般管理系統(tǒng)中都會存在數(shù)據(jù)單位問題，如果作一些出口軟件。這個那是自然更需要面對和考慮的問題了。
數(shù)據(jù)盤點
一般業(yè)務數(shù)據(jù)都會存在天/周/月盤點，盤點時候，自然存在物品自然損耗，資金損耗，需要進行壞賬處理。而且，從系統(tǒng)實時調度決策的準確性，也需要定期作盤點。
數(shù)據(jù)收集與準備
??靜態(tài)通用數(shù)據(jù)的收集整理。
??軟件項目的這部分數(shù)據(jù)收集整理是相對比較容易一些的。
一般包含一些基本的組織機構數(shù)據(jù)，基本的業(yè)務數(shù)據(jù)。例如：
商品條目文件，基本工作流程，供應商基礎資料，銷售客戶數(shù)據(jù)
數(shù)據(jù)正確性保證
一般進入的系統(tǒng)的數(shù)據(jù)都需要手工進行復核，最好至少有1個人
出現(xiàn)有爭議數(shù)據(jù)(如何處理?數(shù)據(jù)的糾偏機制?)
數(shù)據(jù)核對數(shù)據(jù)的準確性
朋友同事對實施的一些看法，主要從管理角度來提出的。
項目風險一般存在:人.技術,意外,數(shù)據(jù)安全。
6.1.項目組織
項目經(jīng)理一定要勇于拍板，敢于承擔責任，項目經(jīng)理不應天天坐辦公室的,他需要親自于客戶打下交道.和客戶打交道,需要找一些能拍板的,或對某一方面特別熟悉的。和客戶打交道,需要找一些能拍板的,或對某一方面特別熟悉的。
軟件系統(tǒng)實施，雙方項目組聯(lián)系脫節(jié)，是否例行溝通堅持下來了
在上線前,需要充分估計可能存在的風險,并定制好應急計劃.定制這事應是群策群力的.
其實實施很多時候，或者說本來就應該從管理角度來考慮問題，處理問題。要叢多哥方面來闡述從甲方，乙方，監(jiān)理公司（咨詢公司），還有實施小組的人員搭配，多方項目組成員的搭建，客戶投訴管理流程，著很多是從管理角度來考慮 的另外多方會晤機制，開會一定要目的明確，特別是一些問題解決會議，一定要落實到實處，否則這種情況多了，開會成了1個休息的時間，或者干脆有人就不來了，即使來了，也是白搭，沒有聽進去，人家心理會想?yún)⒓佑惺裁匆饬x？
6.2. 尋找項目動力
提高系統(tǒng)在客戶心中的價值.如對一些實用性的小功能加大力度推行. 發(fā)握系統(tǒng)中的閃光點. 說高科技人家不懂,說點易用的好接受. 這實際上是1個易用性的具體執(zhí)行，還可以適當?shù)卦谟脩羧褐凶鲆幌率褂们闆r的調查.這有利于發(fā)現(xiàn)系統(tǒng)中存在的不足. 這實際上是定期上線調查，捕捉系統(tǒng)的問題。
6.3 實施體操作小組不要濫用
不要形成實施人員幫做業(yè)務的不惡習,要培養(yǎng)起一批用戶骨干. 不然會累死自己. 臨時替操做人員，成為了永久替操作人員。
6.4 項目計劃
在制定計劃時,注意解決那些不急,但很重要的問題. 制定計劃時要符合實際, 計劃要有階段性，然后定期調整不要比們草車，不結合實際，注意解決那些不急,也可以叢資源的準備問題來說，如果從項目管理角度來說，這寫問題的解決需要一些前提任務，如果在指定計劃沒有把著一點作好模塊定好了上線日期后,就盡量保證時間一到就能用,不要影響客戶的業(yè)務. 項目任務的排序是肯定需要的。
6.5. 系統(tǒng)上線初期
用戶業(yè)務手工和系統(tǒng)并行云做是最容易出問題的。
系統(tǒng)上線后,需要客戶方統(tǒng)一做法. 明確數(shù)據(jù)走兩條路的造成的影響不負責. 不然老是幫忙補數(shù)據(jù),沒完沒了. 還有一個問題，就是歷史數(shù)據(jù)的劃分問題，著部分弄不好，很容易被陷在里面，實施小組很難脫身，依賴性養(yǎng)成；是很難改過來的，他們客戶覺得有實施小組存在,有問題也不敢立馬解決,需要確認一下才敢做.例行交流會議肯定要開的，那怕加班來開都是應該的2邊都是應該這樣，否則大家都不止到別人在干啥。
6.6. 數(shù)據(jù)交割期限的設置：
主要是歷史數(shù)據(jù)的劃分問題，這部分弄不好，很容易陷入一直在處理系統(tǒng)歷史數(shù)據(jù)問題。
6.7 QA庫的建立
把一些常見的問題，以及應該采取的處理方式，收集起來，形成一個常用問題解答庫，也就是一個知識庫。
6.8. 培訓
培訓相關需要的內容：
相關業(yè)務培訓（當然有培訓手冊）
培訓后的答疑
培訓后的考試
培訓一定要注意培訓順序和培訓重點，還要抓住業(yè)務骨干，不要只管范圍，不管質量。
6.9. 論系統(tǒng)模擬上線
系統(tǒng)模擬上線的目的要明確，就是為了模擬系統(tǒng)正式運行的環(huán)境，發(fā)現(xiàn)軟件系統(tǒng)問題。實施范圍必須明確，實施培訓手冊到位，培訓計劃先于模塊實施上線。
一般系統(tǒng)上線前都要有模擬上線。
為了得到好的效果，模擬數(shù)據(jù)一定要有真實行，最好是采用現(xiàn)有的真實數(shù)據(jù)。
另外模擬一定要讓模擬操作人員認識到這是在作真實業(yè)務數(shù)據(jù)一樣，或者干脆瞞天過海,就說是真實上線。否則模擬人員不認真對待，很容易讓模擬流于形式，很多在模擬中應該出現(xiàn)的問題沒有出現(xiàn)，這樣就嚴重了。
模擬上線根據(jù)實際需要可能還會分幾次進行（同1批人），或者分成幾批人進行，也可能分成幾
批幾次進行。當然這樣也可能會造成由于人員分批不當，有些問題或者很多再后面的模擬才能暴露出來，或者由于大家有依賴思想，以為別人會發(fā)現(xiàn)問題，自己就可以不用那樣用心了，特別是在模擬人員有很多業(yè)務工作要做的時候更是如此了。當然，如果有一定獎勵措施，就可能好一些了。
7.結束語
??我經(jīng)常寫一些技術學習的心得，但是對于一些項目實施/系統(tǒng)分析這類和管理結合比較緊密的東西，我基本是憑興趣，一時心血來潮去寫的。其實現(xiàn)實中的軟件項目很多程序員喜歡在工作學習中寫學習心得，但是很少有去寫管理心得。關于這個項目實施總結，我本來打算主要從項目管理角度來闡述的，
但是由于種種原因放棄了，干脆就從系統(tǒng)分析角度/系統(tǒng)開發(fā)根據(jù)實施效果去總結。由于最近這幾個星期亂七八糟的事情太多，從開始寫這個東西到現(xiàn)在已經(jīng)好幾個星期了，差不多寫總結的熱情也耗光了，也就宣布這個項目實施總結結束了。
8.參考資料
8.1. blog.itpub
搜索”實施”，應該可以找到一堆項目實施的資料
8.2 分析模式：可復用的對象模型
（美）Martin Fowler
http://www.china-pub.com/computers/common/info.asp?id=16605
8.3. 本人實施的相關文章
項目實施總結1
http://blog.itpub.net/post/197/7122
軟件項目實施總結2—項目實施中的數(shù)據(jù)管理
http://blog.itpub.net/post/197/7937
8.4. 大連圣達的網(wǎng)站 http://www.sinoprogress.com/
高復先是這個公司的老板
信息資源規(guī)劃（IRP）系列講座之四：營造數(shù)據(jù)環(huán)境（高復先）
http://www.amteam.org/docs/BDDocument.asp?Action=View&ID={A7C57098-1C76-491A-AAE4-FE3288422531}&ReturnTo=BDSearch%2Easp
8.5.實施信息的獲取
8.5.1去一些專業(yè)網(wǎng)站收集,比如：
http://www.topoint.com.cn/
http://www.ccidnet.com/
http://www.zdnet.com.cn/
http://www.amteam.org/docs/bpwebsite.asp
http://www.uml.net.cn/
http://www.51cmm.com
8.5.2.通過google去搜索了，這個是地球人都知道的.
8.5.3通過朋友介紹信息來源然后去這些地方采集信息.
總結
- 上一篇： 交通灯管理系统I
- 下一篇： oracle集群搭建视频,Oracle