李惠

（南京富士通南大軟件技術(shù)有限公司 江蘇省南京市 210012）

1 引言

根據(jù)PMI（Project Management Institute）的報告Pulse of the Profession 2020，從系統(tǒng)的目標達成（MetGoals）、滿足預(yù)算(Within budget)、及時交付(On Time)、范圍蔓延(Scope creep)、項目失?。≒roject failures）五個方面看，在各類組織中，信息系統(tǒng)研發(fā)和運營方面都存在諸多問題。如果將以上五個方面中的任一方面未達成則視作項目失敗的話，則失敗率將超過50%。分析項目失敗的原因并找出解決方案，對提高項目的成功率尤為重要。

本文將結(jié)合筆者的實踐，提出一種改進的信息系統(tǒng)項目失敗的原因分析模型，并提出基于敏捷軟件開發(fā)的模型來解決項目失敗的問題。

2 信息系統(tǒng)失敗原因分析模型

Rajiv Sabherwal 等人提出信息系統(tǒng)成功的個人與組織決定因素中，基于信息系統(tǒng)成功、用戶相關(guān)和情景相關(guān)三個維度，從信息系統(tǒng)購買方（后文統(tǒng)稱甲方）的角度進行分析和建模，可以很好地對信息系統(tǒng)是否成功進行評價[1]。但是，該模型忽略了信息系統(tǒng)的提供方（后文統(tǒng)稱乙方）和開發(fā)過程。對于項目失敗的原因分析，不僅要從甲方，也需要從乙方的角度進行分析。筆者結(jié)合多年的從業(yè)經(jīng)驗，借鑒Rajiv Sabherwal 等人的評價模型，從系統(tǒng)、情景、人員、商務(wù)4 個維度出發(fā)，結(jié)合甲方和乙方的視角進行信息系統(tǒng)失敗的原因分析。分析模型如表1所示。

3 信息系統(tǒng)項目失敗原因分析

3.1 系統(tǒng)因素

從系統(tǒng)因素出發(fā)，主要有如下3 個方面對系統(tǒng)的失敗有重大影響。

3.1.1 需求不明確

在過去的幾十年里，各企事業(yè)單位導入的各種信息系統(tǒng)，大多都借鑒了國外成熟的系統(tǒng)和實施方法，需求相對容易把握。但是最近幾年，伴隨著數(shù)字化技術(shù)的發(fā)展，需要向數(shù)據(jù)要價值，這方面還處于探索階段，且各行各業(yè)的數(shù)據(jù)差異大，甲方的訴求也大不相同，因此需求也相當不明確，導致項目的難度變大。

3.1.2 準備不充分

大多數(shù)企業(yè)對信息系統(tǒng)寄予了過高的期望，以為導入信息系統(tǒng)可以解決一切問題，比如生產(chǎn)制造企業(yè)，以為導入了ERP、MES等系統(tǒng)后，馬上可以起到降低庫存、提高產(chǎn)能等效果。但實際上，信息系統(tǒng)是幫助客戶固化標準流程，可以提高工作效率和資源利用率，而不能從主觀上幫助企業(yè)梳理業(yè)務(wù)流程[2]。因此在導入信息系統(tǒng)之前，必須首先對業(yè)務(wù)流程進行梳理，將工作流程進行標準化。企業(yè)在沒有將業(yè)務(wù)理順之前就上馬信息系統(tǒng)，往往導致達不到既定目標，從而把責任怪罪到信息系統(tǒng)上。

3.1.3 計劃不切實際

由于諸多原因，信息系統(tǒng)開發(fā)項目一般周期都比較短。大多數(shù)企業(yè)要求簽訂合同兩～三個月以內(nèi)甚至更短的周期內(nèi)交付系統(tǒng)。乙方面對一個完不成的計劃，而又不愿意失去商機，就只能在各個方面進行“偷工減料”，項目失敗的概率也大幅提高。

3.2 情景因素

情景因素主要是公司高層的支持以及各種面向項目的政策支持，是信息系統(tǒng)開發(fā)成功的助推劑。

表1：信息系統(tǒng)項目失敗分析模型

表 2：基于Scrum 的解決方案

3.2.1 高層支持

信息系統(tǒng)從立項到開發(fā)實施再到后期運用，都離不開高層支持，因為高層的支持，代表了公司意志，員工必須遵照執(zhí)行。同時高層具有較大的權(quán)力，比如人事評價、資源調(diào)度等，這些權(quán)力影響著員工個人的利益。因此高層出席項目的里程碑會議、在各種場合對項目鼓勵等，影響著所有項目干系人，能加強他們對項目的認同感和責任感，對項目的成功起到關(guān)鍵作用[3]。

3.2.2 促進因素

在導入信息系統(tǒng)時，適當?shù)拇龠M因素有助于提升用戶的參與。比如給予參與項目的員工一些表揚甚至是物質(zhì)性獎勵。

3.3 人員因素

信息系統(tǒng)的開發(fā)和運用都離不開人的參與。經(jīng)常會有一種誤解：信息系統(tǒng)的開發(fā)階段是乙方開發(fā)團隊的事，上線運營后是甲方運營團隊的事。但是一個真正成功的信息系統(tǒng)，無論是開發(fā)階段還是使用階段，都離不開甲乙雙方開發(fā)和運營團隊的共同參與。

3.3.1 客戶參與度

客戶的積極參與是項目成功的關(guān)鍵[4]。無論是業(yè)務(wù)調(diào)研階段還是開發(fā)過程中的需求確認，都需要典型客戶代表以及具有最終決定權(quán)的關(guān)鍵干系人參與?？蛻魠⑴c度不高的話，往往會導致問題在項目后期或者交付后才被發(fā)現(xiàn)，糾錯代價極高。

3.3.2 開發(fā)團隊技能

毋庸置疑，開發(fā)團隊的技能，無論是項目管理水平還是技術(shù)能力，都直接影響項目的進度、質(zhì)量和成本。好的項目經(jīng)理對外積極主動與客戶溝通、把握項目范圍，對內(nèi)制定計劃、協(xié)調(diào)資源并按照計劃推進。而項目組的編碼人員的能力也至關(guān)重要，好的程序員不僅效率比普通人員高，而且代碼質(zhì)量更好。

3.4 商務(wù)因素

商務(wù)因素有很多，這里主要指信息系統(tǒng)開發(fā)實施的價格和邊界兩個因素。

3.4.1 合理價格

在信息系統(tǒng)建設(shè)過程中，如果乙方的收益不能保證合理的利潤，又沒有其他值得期待的收益（比如進入某個行業(yè)、樹立標桿客戶等），則很容易導致乙方“偷工減料”。價格之所以出現(xiàn)不合理的情況，可能是惡意競標、層層轉(zhuǎn)包等原因?qū)е碌摹?/p>

3.4.2 邊界明確

信息系統(tǒng)作為軟件項目，往往很難對開發(fā)范圍進行非常精準的界定。實際操作中，往往是靠甲乙雙方不斷交流逐步明確邊界，交流的過程是一個相互博弈的過程。如果甲乙雙方不能進行良好的溝通，將會導致需求蔓延，最終導致項目失敗。

4 避免信息系統(tǒng)項目失敗的對策

根據(jù)前文的原因分析，可以發(fā)現(xiàn)大部分的問題都通過甲乙雙方進行深入交流、共同明確需求和計劃并不斷迭代以降低風險進行解決。而敏捷開發(fā)模式本身具備的特征，正好可以作為解決信息系統(tǒng)項目失敗的一種解決方案。

4.1 敏捷軟件開發(fā)

敏捷軟件開發(fā)方法出現(xiàn)于上世紀60年代，90年代開始，一些開發(fā)方法如Rapid Application Development（RAD）、Scrum、Extreme Programming (XP)等越來越受到人們的關(guān)注，特別是Scrum 和XP 的實踐者甚多。這些方法論強調(diào)了四個方面：

（1）開發(fā)團隊和業(yè)務(wù)干系人之間的密切合作；

（2）商業(yè)價值頻繁交付；

（3）緊密合作的自組織團隊；

（4）代碼匠藝、驗證和交付代碼的巧妙方法[5]。

2001年2月，17 位軟件行業(yè)領(lǐng)軍人物聚在一起，共同發(fā)布了敏捷軟件開發(fā)宣言和十二條原則。基于敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱就是敏捷軟件開發(fā)模式[5]。其中“客戶合作高于合同談判、響應(yīng)變化高于遵循計劃[6]”的思想對解決信息系統(tǒng)的失敗有很好的啟迪。

Scrum 是敏捷開發(fā)方法的一種實踐，是開發(fā)和持續(xù)支持復(fù)雜產(chǎn)品一個框架。在這個框架中，整個開發(fā)過程由若干個長度為一到四周的Sprint 組成，每個Sprint 優(yōu)先開發(fā)對客戶具有較高價值的需求[7]。

4.2 Scrum解決信息系統(tǒng)失敗的方案

根據(jù)Scrum 開發(fā)框架的特征，結(jié)合信息系統(tǒng)項目失敗的原因，制定面向信息系統(tǒng)開發(fā)的解決方案，如表2所示。

根據(jù)Scrum 的角色、工件和事件分別對甲方和乙方的相關(guān)干系人進行定義。

（1）甲方工作內(nèi)容：甲方派出人員作為產(chǎn)品負責人（Product Owner，簡稱：PO），收集需求，決定開發(fā)內(nèi)容，即產(chǎn)品列表；同時決定每個Sprint 開發(fā)列表，并參與每個Sprint 的計劃會議和評審會議。根據(jù)敏捷宣言中“業(yè)務(wù)人員和開發(fā)人員必須相互合作，項目中的每一天都不例外”的規(guī)定，甲方的PO 作為專職人員，隨時保持與項目開發(fā)人員的溝通。另外，PO 必須具有一定的影響力，能夠從業(yè)務(wù)人員處收集到真實的需求，并且能夠在重要的里程碑節(jié)點，邀請高層人員試用并對系統(tǒng)進行評價。

（2）乙方人員擔任ScrumMaster（簡稱：SM）和開發(fā)團隊的角色，主要負責各產(chǎn)品列表的實現(xiàn)工作，提交可見的成果供甲方驗證。乙方人員必須參與計劃會議，討論Sprint 的工作內(nèi)容；參加每日站會，匯報進度和工作成果，及時解決每日問題；參加評審會議，了解客戶的反饋；參加回顧會議，不斷進行反省和提高。

通過基于Scrum 開發(fā)框架的解決方案，可以解決信息系統(tǒng)失敗原因中的“需求明確性、計劃合理性、高層支持、客戶參與度、邊界界定”等導致的問題。由于雙方統(tǒng)一了戰(zhàn)線，形成了一個有機整體，因此對需求、計劃的理解和制定將更加趨向一致。對于“準備充分度”原因?qū)е碌捻椖渴。ㄟ^甲方人員擔任PO 角色可以得到很大程度的改善。由于每兩周就發(fā)布一個版本，因此可以將版本及時提供給重要干系人試用，及時了解他們的想法，通過持續(xù)吸引重要干系人的關(guān)注，從而解決“高層支持、促進因素”的問題。

另外，對于需求尚不明確的信息系統(tǒng)，也可以通過Scrum 開發(fā)框架，采用POC（Proof of Concept）的思想進行驗證，當發(fā)現(xiàn)結(jié)果不理想時可以及時終止項目，及時止損。

關(guān)于“價格合理”的問題，Scrum 框架雖然無法直接解決，但是由于雙方人員是一個有機的整體，雙方交流頻繁，信任程度將得到大幅提高，因此對于合同價格的惡意競爭將大幅減少，甚至只是簽訂框架性合同，然后根據(jù)每個Sprint 的工作量進行結(jié)算。

5 小結(jié)

在信息系統(tǒng)開發(fā)過程中，雖然采用Scrum 框架可以解決現(xiàn)有問題，但是也面臨如下兩個方面的課題：

5.1 甲方配合度問題

雖然甲方人員作為產(chǎn)品負責人，但是往往不能100%專職，以及可能產(chǎn)品經(jīng)驗不足，導致人不能勝任。這種情況下，需要乙方有經(jīng)驗的人員主動輔佐，齊心協(xié)力干好產(chǎn)品負責人的工作。

5.2 乙方不能主動進行改善的問題

由于敏捷軟件開發(fā)決定了雙方的透明度，乙方在工作過程中提出的各種節(jié)省成本、提高質(zhì)量等方面的改善都很難有新的回報，因此容易導致乙方不再積極主動進行各種生產(chǎn)改善，導致團隊整體能力和工作效率不能提升。

雖然Scrum 框架可以解決信息系統(tǒng)失敗原因中的諸多問題，但是由于在實操層面還有一些課題，因此需要根據(jù)實際情況進行調(diào)整。在具體項目實施時，不應(yīng)生搬硬套敏捷開發(fā)框架，而應(yīng)該把握敏捷思維，結(jié)合實際情況選擇最優(yōu)的做法，爭取項目的成功。