一般來說，公司程序是東一塊西一塊的拼湊起來，程序與程序相互之間是網(wǎng)狀的聯(lián)系。項(xiàng)目結(jié)束了，會議總結(jié)出些問題。例如：軟件如何與管理制度、管理流程、管理理念靠上邊?需求如何獲取?我一直認(rèn)為做管理軟件，不能在制度上、流程上有自己的標(biāo)準(zhǔn)，你只能被別人牽著鼻子走。
第一點(diǎn)：需求如何去細(xì)化把握?首先需求是要以層次去劃分的，最簡單就是上中下即管理層的關(guān)注管理理念及方向、中間項(xiàng)目管理層關(guān)注的整體流程以及各個(gè)模塊的之間的依賴關(guān)系，最后是操作人員的操作細(xì)節(jié)，整個(gè)過程是由上而下去細(xì)化的，管理層提出的理念基本上就是這次項(xiàng)目的目標(biāo)，這個(gè)很重要，基本上是項(xiàng)目的大方向，中間層的管理流程是最復(fù)雜也是最容易出問題，一般在這方面出現(xiàn)的問題最多。到了操作人員基本上就是界面上的東西，就是這里應(yīng)該多一個(gè)字段，那里改個(gè)什么標(biāo)識的，但是不能夠end user影響key user,最后把整個(gè)方向都改變了。
第二點(diǎn)：這次項(xiàng)目的需求一直無法落地，除來一些業(yè)務(wù)原因外，應(yīng)該說在獲取需求的過程中我們?nèi)狈σ恍┖玫墓ぞ?，我們的業(yè)務(wù)場景(包括正向的流程與逆向的流程)整理不夠完善，這些可以測試案例一同整理，很多討論都停留在文字的敘述方面，其實(shí)多做一些流程圖、用例圖、系統(tǒng)集成架構(gòu)圖會，更直觀，業(yè)務(wù)員看了后更容易看清楚自己所在的位置。
第三點(diǎn)：ODS和數(shù)據(jù)倉庫的方案解決網(wǎng)狀程序間數(shù)據(jù)關(guān)系。現(xiàn)在很多程序之間數(shù)據(jù)交換是用db_link來連接的，相互間的形狀的網(wǎng)狀的很混亂，ODS及DW就是把各個(gè)系統(tǒng)的數(shù)據(jù)都集中到數(shù)據(jù)倉庫中，統(tǒng)一規(guī)劃，一些綜合性分析報(bào)表直接在DW出，減少了很多問題。
第四點(diǎn)：程序是持續(xù)優(yōu)化的過程，只要系統(tǒng)存在，優(yōu)化的需求就不會中斷。但是，這種需求的修改是要按版本來規(guī)劃的，絕對不能夠東一個(gè)補(bǔ)丁西一個(gè)補(bǔ)丁去做，這樣做程序缺乏穩(wěn)定性，并且測試和考慮也不充分，風(fēng)險(xiǎn)很大。
第五點(diǎn)：一個(gè)項(xiàng)目做完后，要升華一些知識和方法論以及資料。簡單來說是取完水要架根管子，每個(gè)項(xiàng)目做完會有一些測試案例、安裝文檔、會議記錄、流程圖等，這些是項(xiàng)目資產(chǎn)，不要每做一個(gè)項(xiàng)目，所有的東西都要從頭來過，例如測試案例，只要整理一下，下一個(gè)項(xiàng)目還是可以繼續(xù)使用的，只要把修改點(diǎn)加上去，節(jié)省很多時(shí)間。