一、概述

此文檔電子化項目是×公司作為BPO項目外包給某北京知名外包公司的項目的一個子項目，于2008年8月正式啟動。此文檔電子化項目的功能是把×公司多年的紙質文檔通過軟件和人員錄入，錄入到計算機內，以電子文檔的方式進行保存，以便于長期保存，并方便之后的查詢和使用維護。此軟件的使用者包含×公司的項目管理人員，現(xiàn)場作業(yè)人員，筆者所在公司的大概200個錄入人員，圖像采集（掃描和拍照）人員，電子圖像優(yōu)化和質檢人員，條碼打印人員等等，使用者較多，業(yè)務流程較為復雜。此項目乙方的管理團隊包括項目經理，下設開發(fā)團隊和測試團隊，分別由技術經理和測試經理負責，本人有幸作為測試經理參與了此項目。根據(jù)本人多年的項目經驗，結合此項目的實際特點，并與項目團隊進行了深入和溝通和討論，總結出此項目的相關風險，以進行管理，后使此項目的成果能夠成功上線運行，使此BPO項目能夠順利的進行下去。

二、項目管理風險

此項目的管理工作是采用的項目經理負責制，項目團隊下設軟件開發(fā)團隊和測試團隊，以及業(yè)務咨詢團隊，并設有各自的團隊管理人員。項目管理采用項目經理每周五召開項目管理者例會，各團隊的管理者向項目經理匯報項目的進展情況。各團隊項目經理根據(jù)各自團隊的進展情況，自主召開團隊會議，商議各種情況，并制定措施。

由于項目經理和下面項目組成員溝通很少，有時候對項目的實際進展情況并不是很了解，在項目計劃的制定和調整方面與實際的項目進展情況有些脫節(jié)。軟件開發(fā)團隊包含8名成員，由技術經理進行負責。技術經理是技術出身，很多疑難的技術都自己進行攻關解決，由于技術經理太專注于技術，導致團隊管理有些混亂。當測試團隊發(fā)現(xiàn)BUG之后，指定了責任人，但是由于核心的東西都是由技術經理進行開發(fā)的，且技術經理經常會根據(jù)自己的意愿進行修改，開發(fā)人員并不知道內部技術細節(jié)，BUG的修改速度很慢。

三、版本控制和質量保證風險

（1）項目開始初期，沒有測試團隊的介入，完全是軟件開發(fā)團隊進行的，版本管理的任務自然由開發(fā)團隊承擔下來。雖然團隊建立了VSS進行版本控制管理，但是由于開發(fā)人員自身的特點，且管理的寬松，很多時候開發(fā)人員開發(fā)的源碼沒有及時的放到VSS上，導致打包安裝程序的人員提交給測試人員的版本常常是不完整的新版本。經常會出現(xiàn)在測試人員測試出現(xiàn)問題，流程走不通，請開發(fā)人員過來救急的時候，才發(fā)現(xiàn)測試人員測試的并不是新版本。給測試人員的心理和感情上造成一定的刺激，激發(fā)不滿，給測試人員的情緒造成負面影響。

（2）測試人員是在軟件基本成形后才介入的。因為沒有完整的文檔支持，所以了解業(yè)務需要經歷一個痛苦的階段。由于系統(tǒng)初始編碼，是業(yè)務人員和技術經理根據(jù)其他公司的BPO流程進行一定的研究之后，根據(jù)和客戶的初步溝通所定制的，因此需求會經常的進行變更。而為了趕進度，技術經理經常是通過口頭傳達需求變更細節(jié)，質量保證人員有時候并不能及時的獲得新的需求，無法及時做出應對。同時，由于需求的變化，質量人員需要進行大量的重復測試。

（3）開發(fā)人員打包后的安裝程序需要一定的組件支持，對環(huán)境的依賴性較強，有時在客戶端安裝卸載后再次進行安裝無法正確運行，需要開發(fā)人員查找原因，有時是所需要的組件沒有正確注冊，有時又是其他的原因。這要求測試人員完全模擬用戶的實際運行環(huán)境進行測試，并且必須對干凈的系統(tǒng)進行GHOST，隨時準備重做系統(tǒng)。

四、項目溝通風險

（1）項目組內部的溝通項目組的成員除了項目經理、技術經理是專門為此項目招聘的人員，其他都是為了此項目臨時從其他事業(yè)部的資源池內抽調過來的，人員各自的項目技術和行業(yè)背景都有所不同，技術能力也參差不齊。這要求技術經理能夠和項目組成員做詳細的溝通，了解其技術背景，并根據(jù)各個成員的背景來進行任務分配。由于此項目本身文檔不夠完備，業(yè)務變更比較頻繁，為了趕進度需要通過技術經理口頭傳達需求變更細節(jié)，所以要求項目組內部需要多多的溝通，避免導致需求版本不一致。

（2）新建立的系統(tǒng)必須為×公司已有的系統(tǒng)留有接口，方便之后的系統(tǒng)集成工作。必須對×公司已有的項目運用的技術有一定的了解，并據(jù)此進行設計。所以很多設計必須依賴和受限于×公司現(xiàn)有的系統(tǒng)的設計。必須和×公司，及其原有軟件的提供商做好各方面的溝通和協(xié)調工作。

×公司文檔電子化的程序涉及人員和部門較多，軟件的使用角色也較多，且文檔類型較為復雜，必須經過深入的溝通才能理清此間的業(yè)務關系。

五、技術風險

（1）需要用到打印機和掃描儀，實際現(xiàn)場的工作量每天要達到5000頁（共3臺掃描儀），而且根據(jù)客戶的要求，需要分別表明掃描后紙張的正反面。但是現(xiàn)在選定的掃描儀是kodak，其提供的掃描程序在速度上很快，能夠支持現(xiàn)場的需要，但是并無法區(qū)分正反面，不能夠滿足用戶的要求。項目經理寫了掃描驅動程序，能夠區(qū)分正反面，但是速度上不去，不能滿足客戶的要求。這是一個技術難題，需要盡快予以解決。

（2）圖像優(yōu)化程序是使用的第三方的控件，所有都被封裝，但是有些功能實現(xiàn)的并不好，需要進行改進。這需要拿到第三方的源碼，需要自己進行技術突破或支付一定的費用，但是這并不在預算范圍內。

（3）此項目的流程非常的復雜，有很多個流程狀態(tài)，且流程分支很多，需要進行細致嚴謹?shù)倪壿嫓y試。

結論

此軟件開發(fā)項目的風險因素很多，但是由于我們在項目初期和中期進行了深入的分析，及時的進行必要的調整，采取了適當?shù)姆婪洞胧�，加強了項目內部的溝通，及時發(fā)現(xiàn)問題并積極予以解決，此軟件項目現(xiàn)在已經成功上線并開始使用。