【原創】客戶方領導與業務人員對項目影響分析

【原創】客戶方領導與業務人員對項目影響分析
 作者：沈哲磊 2005－04－15
 項目開發的過程，就是人與人之間交流和溝通的過程，項目開發的復雜性
也體現在了人員類型的廣泛和溝通的困難。記得巴比塔的故事，上帝為了不讓人們
建成巴比塔，就擾亂了人類的語言，使人們溝通困難，所以巴比塔就成了一個失敗
的項目。

 從項目的整個建設周期，我們會碰到大量知識體系、觀念見解、立場都各
不相同的人員，如何理清人員間的關系，使這些人良好的溝通互動，從而對項目產
生良好的推動作用而不是阻礙或者拖延項目的進展，是項目經理不得不面對的問題。

 若按照一般的思路，項目中涉及的人員可以簡單分為技術人員和業務人員，
技術人員向業務人員了解需求和業務流程，并按要求開發出相應的系統指導業務人
員使用。但在實際工作中按照這樣簡單的思維方式是遠遠不夠的，我們必須將項目
各種人員都詳細識別出來，標記他們對項目的影響范圍和影響程度，從而有計劃和
策略的引導這些人員為項目的成功服務。
 
 為了描述方便，沈哲磊制定了如下的人員分類表
   項目關聯人員分類表：
　　　　?。?br/>　　　　　|　　　客戶方　  　|　　開發方　 　　|　其它關聯單位
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
高層領導　|　　客戶單位領導　|　開發單位領導　|　分包開發商領導
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
項目管理　|　　客戶開發領導　|　開發項目經理　|　分包商項目經理
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
項目開發　|　　業務描述人員　|　開發技術人員　|　業務關聯被調研單位
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
項目實施　|　　業務操作人員　|　安裝調試人員　|　設備采購部門
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
項目維護　|　　系統管理小組　|　技術支持小組　|　關聯系統維護組
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

 通過上表，我們可以看到，這是一個由三類單位構成的有層次的體系，
15種不同層次的人員在不同的階段按順序進行著橫向與縱向交流與互動。
 
 其中不同的人員在項目的過程中發揮著不同的作用，在以往的開發管理思
想中，大家往往重視的是項目開發方的管理和開發流程的控制，著重于如何在有限
的時間和成本限制下高效的完成任務。但客戶滿意才是成功的評判標準，如何管理
客戶，調動客戶的資源
為項目的成功服務？

 在本文中，沈哲磊僅探討客戶方五類人員對項目的影響：
（客戶單位領導、客戶開發領導、業務描述人員、業務操作人員、系統管理小組）

客戶單位領導：
 領導重視原則是項目成功的首要原則。
  在項目啟動前期，客戶方單位領導往往
    1）作為開發需求的初始提出者啟動一個項目的初始規劃和可行性分析
    2）同時作為客戶方最高領導與開發單位高層領導協調項目的初始資金預算和
         初始進度計劃。
    3）組織或指定本單位某些相關領導，參與項目管理或開發指導、協調。
  在項目啟動后、開發過程中，客戶方單位領導往往
    1）作為客戶方資源的最終調配者，保障項目在許可范圍內資源的追加
    2）作為問題或爭端的客戶方協調者，爭端在需要業務流程、制度變更時是常
         常發生的。
    3）作為業務關聯單位的聯系人，協助開發方到關聯單位調研分析業務的接洽
  在項目實施后，客戶方單位領導往往還作為最終的驗收者，負責驗收項目質量，
 并最終接受項目成果。

    通過客戶單位領導在各個階段的工作，我們可以看到，客戶單位領導是項目開
發是否成功的最終評判者，是對項目整體宏觀需求有完整把握的直接需求提供者，
更是客戶方資源和客戶方關系的調配者。無論如何，項目經理也要盡力把握客戶方
單位領導的宏觀需求，協調和發揮客戶方單位領導的主觀能動性，從而促使項目在
各方面能夠將人為因素和資源阻礙降到最低，最終引導項目走向成功。

   
客戶開發領導：
    客戶開發領導是由客戶單位領導指定的項目委員會成員。往往具有一定的
實際領導權限，并熟悉客戶各種業務流程，甚至同時也熟悉項目的技術開發。
    客戶開發領導由于具有客戶單位領導的授權，和開發單位領導的許可，可以
參與項目的具體管理過程中，及時的了解項目的進展情況，并努力對項目過程中非
開發技術因素產生的阻礙協調解決。
    有一部分開發單位認為不應將客戶方領導引入開發團隊，認為這樣將會被逼著
在短時間內完成不可能完成的任務，或者客戶開發領導在需求調研結束后，提出對
系統更多的功能要求，最終可能導致項目失敗。
    這種認識是錯誤的。這種情況往往發生在開發企業本身開發過程不規范，對于
項目范圍管理、合同管理、以及需求變更管理不完善所導致的。對于一個管理規范
的開發企業，經過評審的文檔和合同對于項目范圍、時間約束都是十分清晰的，即
使由于認識深入發生需求變更，也可以采用良性的方式，采用雙方接受的變更管理
或者預先合同約定的附加子合同形式進行再次范圍約束和調整。當然，附加子合同
往往同時涉及新的追加費用、調整開發時間問題，對于開發單位可以從經濟和時間
上得到補償，也避免了對于客戶單位不會由于不了解進度和開發情況，在最后驗收
時否定項目，導致項目失敗的風險?？蛻舴揭材軌虻玫饺科谕墓δ?。同時保障
了開發單位和客戶單位雙方的利益。
    當然，作為開發單位團隊要經常的定期的向客戶開發領導匯報項目進度和阻礙
情況。使情況得到客戶方的理解和支持，得到緩解。
    客戶開發領導往往也作為需求的描述者每周定期或全天接受系統分析師和技術
團隊的咨詢和調研。并協助團隊進行跨部門、跨單位的業務調研和實施工作。

業務描述人員：
    業務描述人員不僅包括了客戶開發領導，和業務部門經理，更廣泛的包含了業
務的具體操作人員、關聯單位業務人員。
    系統分析員往往難以深入了解企業的業務流程，調研業務流程和設計系統架構
依賴于他所接觸的人員和相關流程文檔。如何在盡可能短的時間內，將業務流程分
析清晰、透徹是一件非常具有挑戰的工作。
    通常系統分析員做的工作是收集文檔，傾聽各類各流程業務相關描述人員的描
述，然后分析文檔，從中提煉出能夠涵蓋描述業務流程和相關數據信息。但這樣是
不夠的，由于業務描述人員的多樣性，和業務人員自身對業務掌握情況和程度的不
同，同一個流程往往有多個似是而非的表達方式。而且，由于系統建設必將影響業
務流程和工作習慣的建設特殊性，總是存在對業務人員本身工作的正面或負面影響，
不同人站在不同的位置，對項目建設也會采取支持、回避甚至阻礙的態度，這也導
致業務描述人員描述的偏差。所以，系統分析員應盡力從宏觀的角度分析業務流程，
大膽假設，小心求證，必要時候甚至考慮調整優化現有的業務流程，再由全部領導
評審通過，保障業務流程描述的正確性。

業務操作人員：
    業務操作人員在需求調研階段承擔業務描述工作，他們是系統的最終使用者，
是系統內各種數據和資料的提供者，只有他們順利的使用系統，并且樂于使用系統
來提高日常工作效率，系統才能夠說是真正的建設成功。
    所以項目經理要主動有效的調動業務人員的積極性，消除業務人員對使用和推
廣系統的顧慮，無論這種顧慮是由于對系統的不熟悉、對計算機的不熟悉或者對系
統實施帶來的業務流程調整、工作方式改變等原因，項目經理都要想辦法解決。
    可以采用使用培訓、數據初始化等方式降低系統的使用難度。但更應該在一開
始系統調研時就抱著如何為業務操作人員考慮的心態，與業務操作人員探討應該如
何方便其工作，降低其工作的重復性和減輕工作負擔。這將調動業務人員的積極性，
從而使調研工作順利進行，以及開發實施的配合支持。
    并且業務人員接受系統程度越高，整個項目長期成功的可能性就越高。

系統管理小組：
    系統管理小組是系統實施后經過系統管理培訓的客戶方維護小組?？蛻舴较到y
管理小組承擔了系統日常的用戶、權限、數據信息、臨時使用幫助的管理工作。
    系統管理小組的工作成效，將直接影響系統使用的效果。組建和培訓一個具有
一定技術能力的客戶方系統管理小組，將大大減輕開發單位的技術支持工作量和工
作強度。并且，能夠提高解決問題的響應速度，提高用戶滿意度。
    為了加強系統管理小組的工作能力，應在系統基本開發完畢，進入beta測試階
段時，就開始編寫相關維護說明書和相關文檔，組建和培訓客戶系統管理小組。
讓客戶系統管理小組同步參與系統實施過程，并在實施后，開發單位應保持一個技
術支持小組跟蹤和在技術上輔助客戶系統管理小組的日常工作。

總結
    通過對客戶方各類相關人員的分析，大家可以看到，一個項目的成功，缺少了
客戶方人員在工作上的大力支持，基本上是不可能的。
    而合理和有效的引導客戶方各類人員為項目的提供支持幫助和指導，將取得項
目的成功，并最終獲得客戶單位與開發單位雙贏的良好效果。

作者：沈哲磊 2005－04－15   http://blog.powrise.com