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