2023年作為專案經理，負責了乙個集團公司資訊化（軟體）系統專案，該專案涵蓋了對公司從生產到管理的各個環境的管理，系統需求複雜，建設週期長。該公司主要是從事路橋建設業務的，在全國很多地方都有專案部，同時又兼做該集團所在地的部分路橋工程的甲方。因此系統即包括對他作為乙方的業務的管理，又包括他作為甲方的業務管理功能。
根據公司的業務情況將系統分成了三大塊分別進行建設：
專案管理子系統：主要是對各專案經理部業務的管理功能；
工程管理子系統：主要是對公司作為甲方的業務的管理功能；
日常管理子系統（協同辦公）：主要是對集團各管理部門日常工作的資訊化，如：財務、人力、行政、資產、安全等等的管理；
該專案涉及業務範圍廣、涉及部門及使用者多、業務處理流程多並且複雜，從需求調研開始一直到系統開發完成共花費了15人年的工作量。作為這個專案的管理者和主要設計人員，在該專案中積累了很多的經驗教訓，也碰到過很多的挑戰。在這個專案中我主要從事了可行性分析、需求管理、系統分析設計、軟體開發過程控制、專案團隊管理幾個方面的工作，下面就分析從這幾個方面來進行總結。
在剛拿到這個專案的招標檔案時，根據該專案涉及的功能點多，涉及業務部門多且範圍分散的特點。我們進行了初步的專案風險分析：
1、 功能點多，業務部門多，因此需求調研的物件會很多，調研週期會很長；
2、 系統複雜、開發周期長；
3、 因為開發周期長，那麼就很容易出現在開發期間使用者需求變更的情況；
4、 使用者業務部門分布的地域比較廣，因此系統實施、培訓難度會比較大。
針對上面發現的這些風險我們做出了，將系統分割成三個子系統，然後逐個進行開發，逐個進行部署和培訓。在第乙個子系統的開發過程中開始進行第二個子系統的需求調研及分析工作，在第乙個子系統進行入部署階段時，開始第二個子系統的開發階段，同時第三個子系統進行需求分析階段，從而減少系統複雜度。通過與使用者協商我們決定先開發作為甲方使用的工程管理系統，然後開發作為管理部系統的協同辦公子系統，最後再開發專案管理子系統。
在需求調研時，我們採用各個業務部門分別組織調研。首先與被調研的業務部門組織需求調研會議，我們了解業務部門的業務情況，了解業務部門各工作崗位的職能和日常工作。然後與部門負責人確定什麼業務可以實現資訊化，什麼是實現不了的。
調研會議完成之後，我們編寫出需求調研報告，需求調研報告的主要內容是，對該業務部門的業務說明、業務流程歸納，各業務崗位的職能說明等等。完成調研報告後再將報告提交給各部門的對口人員閱讀，由他進行確認，是否涵蓋該部門的業務，業務流程歸納得是否正確，然後再根據業務人員對報告的意見進行修改，最後確定無誤之後由部門負責人進行簽字確認。
在調研過程中我們經常會發現有很傳統地業務處理方式，無法進行資訊化自動化的，或者要進行資訊化很困難，對於這種情況我們首先會向使用者提出是困難，然後申明我們實現不了，如果使用者同意不實現，那麼我們將在調研報告中明確說明不實現，如果有些使用者要求必須實現，那麼我們就設計一種較容易實現的替代方案來實現該業務要求，並要在報告中說明。這個問題非常重要，如果我們不能在調研階段估計出需求的可行能，那麼會直接影響專案的程序，增加開發成本和開發時間。
在需求調研過程中，因為客戶的個人知識結構不同、或效能不同，往往會有不同的側重點，有些人強調結果，有些人強調細節，我們發現如果跟著客戶的思維走，往往會很偏面，經常出現遺漏的業務。因此需要在調研時對客戶進行引導，不要出現偏移主題，或者在乙個問題出現長時間爭論的情況。對於有些我們熟知的業務，或者做過類似功能系統的業務，我們要給客戶進行介紹說明，通過模擬的方式得出完整的業務需求。
在調研中我們還經常發現各部門業務需要與其它業務部門介面的情況，或者需要使用其它部門的資料，或者需要為其它部門業務提供資料，或者需要其它部門協辦的業務需求。對於這種情況我們採用的方式是，先將這些問題在調研報告中記錄下來，等將有業務關係的這兩個部門的需求都了解了之後，再組織這兩個部門的相關人員和我們一起討論介面業務問題。
根據對各部門調研生成的調研報告，使用uml中的用例分析方式來進行分析，將自然的業務表達語言轉化為專業的，可以精確表達需求的uml語言。在需求分析過程中重點關注業務處理流程、業務資料流程。同時關注具體每乙個用例的處理場景、輸入輸出、異常情況處理等細節。
在需求分析和細化的過程中我們會發現還有很多細節是我們在調研過程中並沒有涉及到的，那麼需要我們對客戶進行二次調研。最後生成系統需求規格說明書。
在需求分析過程中我們在進行用例識別是要特別注意用例的粒度問題，如果粒度太小，需求文件會過大，而且會出現過多關注細節而忽略整體的情況，如果粒度太大，又會遺漏很多具體的業務細節。我的經驗是，在進行用例識別時，有乙個標準，只有完成乙個原子的業務功能單元，就是乙個用例，原子業務單元是對可以客戶達到乙個業務目的最小單元，而不是為了完成業務中間的乙個步驟。
隨著專案的深入展開，開發人員對客戶的業務越來越熟悉，客戶對系統的輪廓也越來越清晰，這是雙方都會發現在需求調研階段又一些沒有考慮到的問題，或者理解錯誤的問題，這時候就會不可避免的出現需求變更的情況，需求變更是對專案進度影響最大的事件。因此要求我們在需求調研和分析階段必須仔細認真的理解業務，同時要求我們盡可以的幫助客戶清晰將來的系統輪廓，這樣就可以做到在開發中少出現需求變更的情況。
但是需求變更或多或少都會在開發中出現，在我們專案，我們使用兩種方式來減少需求變更對專案進度產生影響。一是從設計上，調計出耦合度少，層次清晰的系統，這樣當要進行功能調整時，速度為較快，設計上的問題將在下一節中進行說明。別乙個方面當出現變更時，我們先要客戶提高變更的目的，是為什麼解決什麼問題，要解決這個問題會引起什麼新的問題，因為客戶往往不會從整體去考慮，我們需要找可能引起的新問題與客戶說清楚，這樣很多情況下可以說服使用者不去做變更，如果不能說服客戶，那麼我們也可以變更可能影響的地方都考慮到，然後設計出代價最少的解決方案。
需求變更確定之後，編寫需求變更說明書，找相關的客戶負責人簽字確認，以免出現同乙個業務功能出現反覆變更的情況。
考慮到該系統是分成幾個子系統逐一開發的，而這幾個子系統之間又會存在一定的互動。因此我們在設計初期階段就需要考慮到這個問題，但是在設計初期我們只是了解其中乙個子系統的詳細需求，對於其它子系統需求我們並不特別了解。因此我們在設計時採用的是通用化、模組化、標準化作為指導原則。
首先，可以識別出使用者管理、部門管理、許可權管理、工作流程控制、報表管理這幾個模組一定會在這幾個子系統中都會使用到，而且這幾個子系統中使用的還必須是共用這些模組，才可以做到將這幾個系統組成乙個有機整體。因此我們為這些模組設計出通用的解決方案。這樣到三個子系統都開發出來時，因為使用相關的許可權管理、工作流、報表，所以可以使用者方便做到在各系統之間跳轉。
各部門之間的業務流程也可以相互對接，各子系統產生的業務資料可以配置到同一張報表中，從而可以很方便的完成了系統整合功能。
考慮到該系統功能多，短時間內不可能乙個人做完所有詳細設計工作，因此我先做好架構設計，將系統模組劃分好，設計出模組間的介面，訂好設計規範之後，具體每乙個模組的設計工作分配專案的幾個骨幹人員來完成，完成後再組織審評。
在設計階段還對系統工程的結構進行規劃，約定採用四層結構來進行來進行工程規劃，即將系統分成「表現層」（即各功能頁面）、「業務外觀層」（對業務層進行封裝供表現層呼叫）、「業務邏輯層」（實現業務邏輯）、「資料持久層」（實現資料查詢和儲存）。約定將**放到相應的層裡，這樣可以減少物件之間的耦合情度，提高**的可讀取性和可維護性。
考慮我們系統使用的b/s結構，同時有大量的功能（80%）都是對業務資料進行增、刪、改、查、瀏覽、顯現的工作，這些功能的實現**會有大量的類似性，因此安排人員根據這個專案的特點編寫出了乙個**生成器，實現對這些類似功能的自動生成工作，這樣開發人員只需要對自動生成的**稍作修改就可以完成乙個功能的開發，可以大大提高開發效率。
同時考慮到本專案的開發人員多，開發周期長，為了方便交流，我們制訂了**編寫規範，對從變數命名、注釋、介面定義、類的職責等多方面進行的規範。並在開發前對開發人員進行了相關的講解和培訓工作。
專案開發過程控制我參考了rup方法來進行過程管理方法，同是結合專案的實際情況進行了刪減，並引用了部分敏捷開發思想。首先引用了rup中的迭代思想，將專案劃分成若干個迭代週期，為每個迭代週期設立乙個里程碑，要求每個里程碑必須按時完成。迭代週期的劃分，和每個迭代週期的工作按排，以風險等進行排列，先將風險大的排列在前面的迭代週期進行完成，以降底專案開發中的風險，盡早將大的風險識別、緩解或者解決。
對了方便控制，一般將每乙個迭代週期設計在2到3周的時間。對風險優先順序定義的原則是，對專案進度影響越大的其優級先級就越高.
風險主要用為幾類，技術性的、業務性的、人員變動、客戶原因等：
1、 將在技術實現在有難度的列為風險；
2、 準備使用新技術的，而該新技術專案組的人員沒有豐富相關經驗的列為風險；
3、 將業務實現複雜，需要花費大量時間的列為風險；
4、 將業務不清晰，或者可能出現變更的列為風險；
5、 將專案可能出現人員流動的情況列為風險；
在每個迭代週期內的工作必需要在週期內完成，而不能遺留到下乙個週期，如果發現不能在里程碑到來之前完成工作的話，那麼可以通過新增資源或者加班的方法解決。只有控制好每個週期的里程碑才能控制住專案的總體進度。
為了控制專案質量，定期安排人員進行**review，檢查開發人員是否尊守了**規範，是否按四層結構進行了物件劃分，程式邏輯是否合理，需求理解是否出現偏差。一發現問題就要相關人員進行說明，並要求相關責任人進行修正，通過這種方試保證**的質量。
該專案成員多，建設週期長，因此該專案管理中的專案成員溝通交流問題是個大問題，而且在專案開發過程中又碰到了幾個開發人員流失或調動的情況。這些問題占用了專案的大量時間，因為溝通問題，出現過功能重複開發的問題，出現過開發人員對需求理解錯誤的問題。因為專案人員流失的問題，後來人員了解前任的**和業務都花費了大量的時間，從而增加了專案的開發時間。
某集團公司資訊化專案方案書
根據我們的組網經驗，結合太鋼公司企業網的建設必須要統籌規劃，全面安排，確保網路的合理性 先進性 經濟性和安全性，並且要為網路未來的發展留有足夠的擴充餘地。堅持實用性並充分保護使用者的投資 堅持開放性 相容性和可互連性，向事實上的工業標準tcp ip協議靠攏，同時考慮支援ipx spx 堅持技術的先進...
某集團公司資訊化規劃專案框架
某集團公司資訊化規劃專案2008 12 05 一 專案背景 某大型集團公司 以下簡稱 集團 自上世紀90年代中期改制以來，勵精圖治，創新發展，在做強主業的基礎上，呈現出相關多元發展的強勁態勢，核心競爭能力不斷增強，被國家 確定為重點培育發展的大型能源基地之一。經過近10年來的迅猛發展，該集團公司在傳...
集團公司資訊化規劃專案
一 專案背景 某大型集團公司 以下簡稱 集團 自上世紀90年代中期改制以來，勵精圖治，創新發展，在做強主業的基礎上，呈現出相關多元發展的強勁態勢，核心競爭能力不斷增強，被國家 確定為重點培育發展的大型能源基地之一。經過近10年來的迅猛發展，該集團公司在傳統領域形成了a b c三個支柱產業，在高新技術...