信息系統(tǒng)項(xiàng)目失敗的原因分析及對策

李惠

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

1 引言

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

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

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

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

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

3.1 系統(tǒng)因素

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

3.1.1 需求不明確

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

3.1.2 準(zhǔn)備不充分

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

3.1.3 計(jì)劃不切實(shí)際

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

3.2 情景因素

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

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

表 2：基于Scrum 的解決方案

3.2.1 高層支持

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

3.2.2 促進(jìn)因素

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

3.3 人員因素

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

3.3.1 客戶參與度

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

3.3.2 開發(fā)團(tuán)隊(duì)技能

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

3.4 商務(wù)因素

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

3.4.1 合理價(jià)格

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

3.4.2 邊界明確

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

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

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

4.1 敏捷軟件開發(fā)

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

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

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

（3）緊密合作的自組織團(tuán)隊(duì)；

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

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

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

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

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

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

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

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

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

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

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

5 小結(jié)

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

5.1 甲方配合度問題

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

5.2 乙方不能主動(dòng)進(jìn)行改善的問題

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

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