漫談系統整合軟體行業專案管理

2021-03-04 09:38:41 字數 4415 閱讀 6686

先就從專案管理開始。

專案管理是從上世紀六十年代開始,直到進入二十一世紀逐漸成熟、發展的人類對自身組織管理的高階發展形式。其深遠背景是隨著人類大規模生產力的空前提高,人類對物質、精神的需求不再停留在滿足的高度,而是進一步提高到個性化、獨特化的高度;隨之而產生的是我們面對的自然和人類自身的工作課題也進一步複雜化和深度化,這些如果用傳統的常規管理模式,用二十世紀三四十年代發展起來的機器大工業管理理念和方式已經是力不從心。關於專案管理的權威定義可以參考pmbok.。

就企業而言,全球化的競爭加劇和產品週期的縮短,使得企業靠一種或一類產品滋潤幾年甚至幾十年的時代一去不復返,如果不及時推出領先同行的產品占領市場,距離淘汰的日子也就不遠。對於所有領先於行業的企業而言,如何研發新一代產品,如何進行市場營銷策劃,開拓新的市場份額,這些工作的重要性已經遠遠超過產品的生產和包裝。而就前者的管理而言,就是專案管理的範疇,而後者則是傳統的常規管理模式。

就行業而言,新型行業面臨的風險和未知領域較多,側重於專案管理,傳統行業由於有了成熟的生產規範、工藝,側重於常規管理,但這並不意味著傳統行業與專案管理無關,事實上傳統行業只有勇於創新,用於冒險,才能獲得新的生機。任何企業都要靠市場營銷和產品創新這兩條腿來走路,短了任何一條都會成為瘸子,而這兩條腿都適合專案管理的路子。

事實上專案經理在海外是相當重要的崗位,其資歷和能力都有嚴格的要求。如果你的名片上跟個pm的標籤,一般都能獲得別人的敬重,這跟國內pm是基層的班排長角色的定位很不一樣。

軟體行業是只有二三十年發展歷史的新型行業,幾乎就是伴隨著專案管理技術的發展而逐步成熟的。軟體行業的專案管理幾乎集中了專案管理的所有難點和風險,軟體企業的管理幾乎就是專案管理的天下,雖然在海外,隨著軟體開發技術和管理的成熟化、工程化,出現了一些工程化、規範化的組織、標準,如iso、cmm、pmpok等,但遠遠不能與傳統行業的標準規範如機械行業、建築行業相提並論,一張建築圖可以讓任何乙個國家的建築師都能看得懂,可乙份軟體文件別說是跨國,就是兩公司之間都沒有共同的標準規範。

軟體行業要成為傳統行業,還有相當長的路子要走。換句話說,軟體行業的薪水,至少還有相當時間要高於其他傳統行業,國內有一些人說要培養軟體藍領,眼光不錯,看得很遠,關鍵是只有幾十年發展年齡的軟體行業是否能夠達到像建築行業那樣的成熟和規範,找幾個藍領甚至是農民就能蓋出一棟大樓來?在藍領的後面,軟體行業還需要很多東西來配套,而這些東西不是一天半月能建立起來的。

很多人知道印度的軟體企業很規範,有的企業甚至人數過萬,管理上沒有一套是不可想象的,但細究一下,大家在市場上用過印度商標的軟體嗎?沒有,其實很多大家熟悉的軟體的底層模組可能就是印度人開發的,但我們不知道,真正掌握軟體核心技術的不是印度人,而是美國人和日本人,他們把模組的編碼工作讓印度人去幹,而策劃、設計和其他一些核心工作都是關起門來自己幹的。難道我們也得像印度一樣重點培養軟體藍領,在軟體這樣的高技術領域也像傳統行業一樣成為發達國家的末端加工基地嗎?

軟體行業的專案管理,可以粗分為包括軟體開發在內的系統整合專案,純硬體的系統整合專案和系統軟體開發開發專案。由於對後兩類涉足不多,下邊只說第一類。

系統整合軟體專案在所有軟體開發專案中是比較複雜的,與其他軟體專案相比,集中表現在以下幾點:

1、必須集軟體與硬體技術於大成,要求專案組不但要精通軟體,而且要掌握硬體技術,這與純的系統軟體開發專案和純硬體整合專案的要求是不同的。將軟硬體技術進行完美結合,給客戶提供價效比最高的系統,是系統整合專案孜孜以求的目標;

2、必須集業務與計算機技術於大成,系統整合專案有明確的客戶和目標性,必須是對某種行業某種業務或幾種業務的支援,如金融、電信、稅務等等,系統具有明確的業務要求,這與系統軟體作為一種通用工具來開發是截然不同的。這就要求專案組除了精通計算機技術,還必須精通相關領域的業務知識,專案組對相關領域業務知識的掌握水平和前瞻性,很大程度上決定了系統的質量和生命週期;

3、客戶的多方性和複雜性,系統整合專案與社會、人群息息相關,乙個系統整合專案的成功帶來的不僅是經濟效益,更多的是社會效益。當乙個成功的系統整合專案開始服務於社會,方便於人群時,開發人員應該因此而感到自豪和欣慰。另一方面,正是因為系統整合專案的貼近社會,客戶的關係處理就顯得複雜得多,這裡不僅有甲方,合作方,包括雙方的合作方和系統軟體提供商,,還有顧客和社會等等;

4、管理的複雜性,正是如上說述,專案管理的複雜性就可以理解了。

最後談問題,從目前國內的系統整合業的發展狀況來看,系統整合商的發展很容易走入以下誤區(以下問題側重從技術的角度來思考,並不針對某家具體的公司,請勿對號入座):

1、重市場,輕實施:這個就不必談了。

2、重專案效益,輕管理、技術積累:作為專案經理,他的首要目標是確保專案的準時完成,成本控制在底線以內,同時讓客戶和公司雙方滿意。如果做到這些,這個專案經理就是合格甚至優秀的了。

但從企業的角度而言,如果僅滿足在這個層次,問題就大了,因為公司的生存不像乙個專案就幾個月或一年的時間,有些企業是有成為百年老店的決心的。我們發現一些公司擁有大量的成功專案案例,但其管理水平、技術能力並沒有得到顯著的提高,甚至會因人員的流失而下降,說明大量的成功專案並沒有給企業帶來管理和技術的積累,離開了一些技術骨幹,企業就是乙個空殼。這是專案經理的錯嗎?

大家思考一下。

3、重第三方提供的技術,輕自身的系統整合技術:系統整合的真諦在於在滿足客戶目前和將來一段時間的需求的前提下,提供給客戶最佳價效比的系統。整合商容易犯的錯誤是替系統軟體商和硬體商打工做廣告,一味強調第三方提供的硬體、系統軟體技術是如何先進,而沒有強調自身的在某一行業的系統整合技術如何,沒有自身的品牌培養意識和技術積累意識。

從長遠而言,對於乙個系統整合企業而言,沒有明確自身的優勢所在和命脈所繫是危險的。整合商要始終清醒意識到,無論是硬體還是系統軟體,這些核心技術都不是自己的,別的整合商都能輕而易舉的獲得,只有對相關行業的業務的深刻理解和前瞻,和積累起來的系統整合經驗、技術才是系統整合商的核心競爭力。

4、重技術,輕業務:這個與上點相關,如果把技術與業務同時放在天平上,對於系統整合商來說,傾斜的永遠應該是業務這一邊。客戶需要乙個系統,首先而且是主要的目的是看這個系統能滿足和支援什麼樣的業務,今後的拓展能力如何,而不是這個系統是靠什麼技術去實現的。

乙個理智的使用者絕對是要求系統在滿足業務及其今後一定階段拓展的前提下,實現的代價越小越好,技術越簡單越好。這是很多整合商忽略了的地方。客戶對技術往往是迷信和迷茫的,引導客戶、培養客戶對於乙個欲成為百年企業的整合商來說應該是必不可少的。

系統整合商要培養自己技術人員不僅要精通技術,更重要的是精通業務,特別是系統整合後的業務。對於系統整合技術人員言,對業務掌握的要求要異於一般的業務人員,一是考慮到系統處理方式下如何優化業務的處理模式,二是必須掌握業務發展的前瞻性,確保系統在短時間內不落伍,隨著社會的發展,系統整合開銷對於任何乙個客戶來說,已經成為越來越大的支出,我們要理解客戶對系統的期望和感情。昆明農信一位客戶說過一句話,你們開發只是幾個月,可我們要用幾年啊。

就個人感覺,我覺得業務的門坎要高於技術,如金融、保險,沒有十幾年甚至幾十年的經驗是不敢稱之為專家的,特別是對業務歷史、發展的深刻理解,沒有時間的浸淫是找不出感覺的。而相對而言,一些計算機技術,特別是一些新技術,如新的語言和中介軟體技術,乙個畢業生通過乙個專案甚至自學就可以基本掌握,很難說這些技術的門檻很高。

在國內,除了一些硬體條件限制的技術(如mainframe)外,其他的只要能在pc上實習,盜版光碟又能買得到的技術,都不可能讓你長久維持高薪的,這些東西新畢業生往往掌握得比老人快得多。有句笑話,在中國,任何先進的it技術的門檻就是5元――一張盜版碟的價錢,好像最近都不要5元了。

那老人的價值在那裡?如何使自己持續增值,至少是不貶值,應該是我們經常思考的問題。

5、重技術,輕設計:技術人員在深刻理解了客戶的業務需求後,採用適當的架構和設計,根據架構和設計選用適當的技術去實現這個系統。但在具體的實施過程中,我們往往把這個順序顛倒了,對於技術出身的人員來說,容易犯的錯誤是迷信技術,忽略對業務的深刻理解和在此基礎上的業務設計和系統架構、設計,總是用技術的角度去看待、評價系統,作出來系統往往是技術先進、設計蹩腳、業務落後或不適用,這種例子實在是太多了。

6、重開發,輕測試:這個就不羅索了。

7、重測試,輕開發:這個其實和上一點犯的是同一毛病,由於這幾年對測試的重視言語深得人心,有些整合商就幻想僅靠測試去確保系統質量,很多編碼人員也不願去做內部測試,把問題留給測試人員去發現,這就走向另乙個極端了。大家要清楚測試的地位,測試工作只是對系統質量的確認和最後的把關,而不能將所有的系統問題遺留到測試階段去解決,很多問題在前期解決的代價要遠遠小於測試階段發現、解決的代價,俗話說得好,一人疏忽百人忙,這個虧我們不能再吃了。

事實上乙個系統的質量不是靠測試來決定的,而是在開發階段結束時就已經定型了。測試只是最後的把關和驗收,測試工作很重要,但千萬不能迷信。

8、重程式,輕文件:這個也不羅索。

9、重個人能力,輕整體協作:這一問題在大型的專案中表現得尤為突出,過去我們的系統整合專案基本上都是四五個人搞定,在溝通和協作上即使沒有規範的流程和文件控制都不會有太大的障礙,每個人的效率都可以達到很高,從而整體也同樣達到高效。但在十人以上甚至幾十人的專案管理過程中,原有模式就會給專案帶來了空前的混亂,雖然每個人的效率並沒有降低,但由於溝通不暢和誤解產生的重複勞動、額外勞動大大增加,整體效率顯著降低,這是我們急需解決的重點問題,因為我們不可能永遠做手工作坊式的小專案,公司要成長,個人要進步,這一點也需要我們大家思考。

後面歡迎大家繼續。

系統整合專案合同管理

資訊系統工程的建設過程實際上就是合同的執行和監控過程。合同是工程專案建設 的基本依據,也是監理工作的主要依據之一。合同管理是資訊系統工程建設合同得到有 效履行的有力保證。作為系統整合專案管理工程師,應該熟悉合同管理的基本內容和要 求,掌握合同的索賠及違約管理的技巧和技能。13.1專案合同 13.1....

系統整合專案管理大綱

系統整合專案管理工程師考試大綱 一 考試說明 1.考試目標 通過本考試的合格人員能夠掌握系統整合專案管理的知識體系 具備管理系統整合專案的能力 能根據需求組織制定可行的專案管理計畫 能夠阻止專案實施,對專案進行監控並能根據實際情況及時做出調整,系統地監督專案實施過程的績效,保證專案在一定的約束條件下...

系統整合專案整體管理

專案整體管理過程負責專案的全生命週期管理 全域性性管理和綜合性管理。全生命 週期管理意味著專案整體管理過程負責管理專案的啟動階段直到專案收尾階段的整個項 目生命週期。全域性性管理意味著專案整體管理過程負責管理專案的整體包括專案管理工 作 技術工作和商務工作等。綜合性管理意味著專案整體管理過程負責管理...