IT國內應用軟體專案管理的若干問題(轉)

隨著企業IT建設的深入和國際交往的增多，應用開發的專案管理日益受到重視。國內面向企業客戶的應用軟體開發專案管理的問題和差距何在？更多的可能是實踐問題而非理論問題，以下結合筆者在集團使用者、外資企業和國內民營企業的專案經驗和思考，作些初步的探討。 專案管理意識 　　不能真正區分專案實施和專案管理的工作任務，是目前存在的普遍問題。可概括為“沒事做”和“沒人做”並存的現象，這往往由開發骨幹兼任專案經理所致。一方面，如果設立專職的專案經理，專做專案管理而不做任何分析、設計、編碼、測試等具體的技術實施工作，就會感覺“沒事做”，或是在打雜。另一方面，由於主要或全部精力均忙於具體技術工作，各種專案管理任務（如：專案分析/評估、專案計劃的制定/檢查/調整、上下左右的溝通、專業資源調配、專案組織調整、專案財務控制、風險分析/對策等）不可避免地疏於顧及，專案管理的事情“沒人做”，導致專案控制的問題“積勞成疾”，後悔莫及。 　　在中、小型專案中，管理任務可能不飽和，有條件的專案經理可以兼任專案技術主管或業務諮詢，關鍵在於要有將專案管理工作區分出來的意識和責任感。 專案成本基礎 　　專案管理的精髓是必須在規格（Specification）、成本（Cost、Resource）和進度（Schedule）之間取得平衡。而目前國內的系統整合企業，普遍沒有建立專業工程師的成本結構及運用控制體制。因而無法確立和實現專案成本的指標、考核和控制，導致公司與專案經理之間的責任不清。直白地說，專案經理可以不計成本地申請資源，“韓信點兵，多多益善”，而公司處於兩難，答應則可能投入太大，拒絕則必須承擔專案失敗的責任。上級經理成了專案經理。 　　不建立專業資源成本結構，就無從實現專案的成本管理，就不會有真正的專案管理。 專案管理制度 　　規範化而且切實可行的專案管理制度，必須因企業、因專案而異。一般而言，應是專案管理原理、企業/行業特點和專案規模/性質、企業開發文化/素質等各種因素綜合的產物。產生的過程應是，由具一定的理論素養、豐富的規範化專案實施經驗和總結能力的資深專案管理專家，結合企業的具體情況，有針對性地制定，並經培訓、試行、調整予以落實貫徹。 　　國內目前的普遍情況，或者是企業無專案管理制度，僅憑個人經驗實施專案管理；或者是書生制度，照搬教條，紙上談兵，束之高閣。其結果是，不僅實際的專案管理無所依循，而且也使專案監管層難以落實專案的間接監控和支援。 專業服務組織 　　國際上的企業級應用軟體的開發組織，基本上分為產品研發和專業服務兩類。國內由於市場成熟度低等原因，多以直接面向客戶需求的專案型開發為主，應屬專業服務型的技術組織結構。 　　目前國內的差距主要在於，一是公司策略上將專案實施部門定位為配合系統產品銷售的成本中心，而未能作為一個獨立核算的業務單元或業務方向；二是基本採取層次性的業務管理性組織結構，而缺乏業務管理和專業管理（諸如運營經理、資源調配、資源開發、行政助理、專案會計、專案質量監控等）的分工合作的矩陣結構；三是缺乏縱向專業深度的設計和結構。 　　專業服務組織結構的差距，使專業服務部門市場定位模糊，發展方向迷茫。平時不利於專業隊伍建設，不能持續有效地發展和提高技術隊伍的專業素養；售前活動中，不利於程式化地組織售前支援及控制售前風險；專案實施中，不利於合理及時的專案資源的調配，不能將運營（Operation）監管和專案監管有機結合，以確保專案監控狀態。 專案計劃 　　專案計劃是專案經理實施專案管理控制的基礎。目前的差距主要有：一是專案計劃的制定不夠嚴謹，隨意性大，可操作性差，因而實施中無法遵循，如專案計劃過於粗略，落實Breakdown（“粒度”）不足；沒有做到任務、進度、資源三落實。二是缺乏貫穿專案全程的詳細專案計劃，甚至採取每週制定下週工作計劃的逐周專案計劃方式，其實質是“專案失控合法化”。三是專案進度的檢查（與進度計劃比對）和控制不足，不能維護專案計劃的嚴肅性。 　　專案計劃的Breakdown或曰“粒度”，是一個需要小心把握平衡的問題。越細則控制力度越大（筆者曾見過細到0.25小時/人的），但專案管理的成本越高；反之亦然。以國內目前的狀況，個人看法，3個月以下的專案，應細到人天，至少2～3人天；半年以上的專案，至少應到人周。 　　如果專案經理對於專案專業領域不夠熟悉，則專案計劃主要應由專案技術主管和Teamleader（團隊領導者）具體起草，因為他們最熟悉工作內容和具體資源的適應性，專案經理做溝通、調整、平衡、確認，並負最後之責。 專案風險意識 　　專案風險意識就是失敗意識。每當我們啟動一個專案的時候，我們往往憧憬專案投產之日的成功，但是否想過精疲力竭後失敗的沮喪？做專案不比賣產品，產品賣出就是成功，專案投產才算成功；產品是靜態的，專案是動態的；產品質量有問題可以包換、保修，專案一旦失敗，時間不能倒流，客戶損失的可能就是市場競爭優勢和機遇。風險意識，就是對這種結局的可能性的警惕。如此，我們就會小心謹慎地處理許多專案業務需求、技術方案和組織管理的問題。 　　目前市場競爭的激烈和市場的成熟度不足，可能導致應用開發專案的惡性競爭風險。客戶希望物美價廉而加需求、壓價格、壓進度；廠商惟恐出局而拍胸脯、打包票。忽視必要的科學的可行性分析和評估，簽訂不可能完成的服務合同，專案尚未啟動，已經註定了其中的高風險。事實上，這種風險是雙方的，廠商可能是經濟和信譽上的損失，客戶也可能是經濟和業務發展上的損失。 業務參與意識 　　客戶購買IT系統的目的是為了更好地發展自己的業務。應用軟體將通用計算機變成了專用的業務系統，因此應用軟體中滲透著業務制度、策略，成為應用軟體甚至是IT系統的靈魂。因此，國際上成功的案例是業務部門貫穿始終地參與，作為確保專案成功的底線（Bottom Line）之一。 　　遺憾的是，我們經常會看見技術人員“獨立”地開發“創新”性的系統，究其原因，往往有：認為應用開發是IT的事情；認為業務人員的認識囿於手工或現行方式; 業務人員工作太忙，無暇參與專案；嫌業務人員要求太多、太口羅嗦，以致頻繁變更需求。儘管這些原因不無道理，但歸根結底，應用專案是來自於業務部門的需求，最終供業務部門使用。業務參與不足，既可能產生業務偏差的隱患，也可能因業務人員不理解、不認可而夭折。 　　成熟的專案經理，應確保專案實施中業務參與的全面性、深度和權威性。[@more@]