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