基于快速原型模型建立商业呼叫中心SPOMP的应用研究
摘要：本文從快速原型（Rapid Prototyping，RP）這一軟件生命周期模型的原理出發(fā)，結(jié)合呼叫中心（Call Center，CC）軟件項(xiàng)目外包的現(xiàn)狀，提出應(yīng)用快速原型模型于呼叫中心軟件項(xiàng)目的外包管理，試圖以軟件工程的工程化和標(biāo)準(zhǔn)化思維來(lái)解決呼叫中心軟件項(xiàng)目外包的問(wèn)題。本文重點(diǎn)分析了呼叫中心軟件項(xiàng)目外包現(xiàn)狀，提出適合用快速原型來(lái)解決問(wèn)題，并給出了應(yīng)用快速原型模型建立呼叫中心軟件項(xiàng)目外包管理平臺(tái)（Software Project Outsourcing Management Platform，SPOMP）的方法集和工具集。
關(guān)鍵詞：快速原型（Rapid Prototyping，RP），呼叫中心（Call Center，CC），軟件項(xiàng)目外包管理平臺(tái)（Software Project Outsourcing Management Platform，SPOMP）
總言
對(duì)于軟件產(chǎn)品的生產(chǎn)，軟件工程領(lǐng)域有很多理論和實(shí)踐成果，已成為一門(mén)學(xué)科。軟件工程的意義在那里呢？有兩點(diǎn)：一是工程化，即工序流程加方法集和工具集；二是標(biāo)準(zhǔn)化，開(kāi)發(fā)和共享都必須有標(biāo)準(zhǔn)作為基礎(chǔ)。軟件工程理論本身是源于軟件開(kāi)發(fā)的實(shí)踐，但更多是工程理論具體應(yīng)用的產(chǎn)物。基于軟件工程的認(rèn)知，對(duì)于軟件項(xiàng)目的管理，就必須建立起一個(gè)平臺(tái)，這個(gè)平臺(tái)有一套完成軟件產(chǎn)品的工序流程，每道工序有相應(yīng)的方法和工具來(lái)產(chǎn)生成果，并輔以標(biāo)準(zhǔn)使他人或下道工序可理解工作成果并繼續(xù)完成下道工序的工作。
對(duì)于呼叫中心軟件項(xiàng)目的外包管理，搭建一個(gè)怎樣的平臺(tái)來(lái)滿足呼叫中心的軟件產(chǎn)品需求就是本文探討的核心。外包性的軟件項(xiàng)目，體現(xiàn)在軟件工程的生命周期里，需求階段無(wú)疑是決定軟件外包成功的關(guān)鍵因素，因此探討建立呼叫中心SPOMP的中心就是如何有效地完成需求工作。圍繞需求，研究在呼叫中心軟件項(xiàng)目外包下，應(yīng)用快速原型模式建立呼叫中心SPOMP是本文的立足點(diǎn)。
1．背景
對(duì)于呼叫中心應(yīng)用解決方案的提供商，集成是一個(gè)高度發(fā)散的概念，同時(shí)具有深度內(nèi)斂的意義。因?yàn)榧?#xff0c;就必須為自己定位在呼叫中心行業(yè)中的作用，就必須尋找在呼叫中心行業(yè)中的優(yōu)勢(shì)，才不至于涉獵非我所長(zhǎng)的業(yè)務(wù)和逆向產(chǎn)業(yè)鏈上下游。依托電信運(yùn)營(yíng)商的背景，集成呼叫中心供應(yīng)商和信息軟件開(kāi)發(fā)商，為各行各業(yè)建立專(zhuān)業(yè)呼叫中心，發(fā)揮呼叫中心作為企業(yè)運(yùn)營(yíng)核心的作用，這是當(dāng)前電信呼叫中心的一個(gè)明確性做法。
當(dāng)前呼叫中心市場(chǎng)，以信息軟件開(kāi)發(fā)商和以電信運(yùn)營(yíng)商作為呼叫中心應(yīng)用解決方案的集成商是兩大主流。既然市場(chǎng)存在可替代的角色出現(xiàn)，就要求我們重視同競(jìng)爭(zhēng)對(duì)手在應(yīng)用解決方案上的差異，顯然客戶可感知的軟件產(chǎn)品是競(jìng)爭(zhēng)的關(guān)鍵點(diǎn)，也是差異化的關(guān)注點(diǎn)。
客戶對(duì)于呼叫中心背后電信的運(yùn)營(yíng)能力和供應(yīng)商的設(shè)備性能都存在一定程度盲區(qū)，但對(duì)于呈現(xiàn)在客戶面前的軟件產(chǎn)品，客戶卻可以評(píng)頭論足。換句話說(shuō)，客戶關(guān)注的是呼叫中心應(yīng)用解決方案的最終成果，即是呼叫中心信息軟件。一道菜后面的工序如何繁雜、原料如何華奢、配料如何精致，食客最終感知的是菜的色、香、味，于是乎如何做出色香味俱全的菜，背后的工序和原料及配料講究就不可少。如之，作為呼叫中心應(yīng)用解決方案的最終感知產(chǎn)品的信息軟件，其差異化決定了競(jìng)爭(zhēng)能力。面對(duì)同樣的需求，信息軟件開(kāi)發(fā)商顯然具有更高的需求響應(yīng)和實(shí)現(xiàn)能力，因其工程化和標(biāo)準(zhǔn)化程度較之電信呼叫中心軟件項(xiàng)目的外包性質(zhì)要高。如何提高電信呼叫中心的需求響應(yīng)和實(shí)現(xiàn)能力，建立其軟件項(xiàng)目外包配套的管理平臺(tái)即是本文的論述點(diǎn)。
本文所指的呼叫中心是以廣州電信商業(yè)呼叫中心為背景，衍生到在呼叫中心運(yùn)營(yíng)和建設(shè)上具有同樣問(wèn)題和類(lèi)似特點(diǎn)的軟件項(xiàng)目外包。以電信網(wǎng)絡(luò)運(yùn)營(yíng)為基礎(chǔ)，建設(shè)呼叫中心平臺(tái)提供商業(yè)外包的；具有既定呼叫中心平臺(tái)架構(gòu)和業(yè)務(wù)軟件基礎(chǔ)框架，為不同行業(yè)和不同企業(yè)提供不同應(yīng)用的呼叫中心行業(yè)應(yīng)用解決方案；依賴(lài)呼叫中心集成商進(jìn)行前期呼叫中心的建設(shè)和維護(hù)，包括呼叫中心應(yīng)用解決方案中配套軟件的開(kāi)發(fā)；以呼叫中心平臺(tái)和業(yè)務(wù)軟件為產(chǎn)品持續(xù)性地提供呼叫中心整體解決方案，以產(chǎn)生社會(huì)和經(jīng)濟(jì)效應(yīng)，并帶來(lái)營(yíng)收；這是大致描述了本文所指呼叫中心的基本特點(diǎn)，這些特點(diǎn)也決定了選用快速模型模式來(lái)建設(shè)呼叫中心SPOMP的合理和適用。
2.商業(yè)呼叫中心現(xiàn)狀
軟件項(xiàng)目外包本身所具有的特點(diǎn)，加以廣州電信商業(yè)呼叫中心軟件外包項(xiàng)目為背景分析當(dāng)前軟件外包現(xiàn)狀，期以加深對(duì)軟件外包和呼叫中心軟件外包的理解，從而為廣州電信商業(yè)呼叫中心建立SPOMP以及以之推廣作為具有類(lèi)似特點(diǎn)的呼叫中心的軟件項(xiàng)目外包管理。因此，此現(xiàn)狀既是共性與個(gè)性的結(jié)合，那么所探討建立的呼叫中心SPOMP既可用于特定的廣州電信商業(yè)呼叫中心也當(dāng)可適之于具有類(lèi)似特點(diǎn)的呼叫中心，除問(wèn)題相似，更在于軟件工程的應(yīng)用在軟件外包上應(yīng)當(dāng)根據(jù)具體情況尋找對(duì)應(yīng)模式以解決。
現(xiàn)狀的分析出發(fā)于軟件外包特點(diǎn)，并結(jié)合實(shí)際廣州電信商業(yè)呼叫中心的軟件外包項(xiàng)目，因此現(xiàn)狀所指出的問(wèn)題不特定指那個(gè)項(xiàng)目，而是從項(xiàng)目中提升到具有通用的高度。本文就從軟件工程生命周期的幾個(gè)環(huán)節(jié)談?wù)劗?dāng)前呼叫中心的軟件項(xiàng)目外包現(xiàn)狀。
2.1 需求認(rèn)知的折扣
需求認(rèn)知的折扣體現(xiàn)在兩方面：一是需求傳遞過(guò)程，需求信息失去第一手的效應(yīng)；二是需求理解上，各環(huán)節(jié)有各自取向。這里把需求作三方面的劃分：一是項(xiàng)目初始需求；二是項(xiàng)目移植平臺(tái)的需求；二是項(xiàng)目維護(hù)的需求變更。這三面需求都存在一定程度的需求傳遞和需求理解上折扣，如項(xiàng)目初始需求從客戶口頭到書(shū)面的不規(guī)范需求；再到客戶經(jīng)理的業(yè)務(wù)需求理解和技術(shù)人員的技術(shù)需求理解，最后才到外包公司的項(xiàng)目經(jīng)理，這個(gè)過(guò)程通過(guò)幾番傳遞和理解，需求失真是相當(dāng)嚴(yán)重；再如項(xiàng)目維護(hù)的需求變更，客戶的需求是有一個(gè)過(guò)程，從對(duì)業(yè)務(wù)軟件的零認(rèn)識(shí)到具體操作后的了解，一般在維護(hù)初期有大量的需求提出，此時(shí)，在客戶和外包商之間需求難以取得平衡，當(dāng)客戶對(duì)業(yè)務(wù)軟件操作時(shí)間越長(zhǎng)，提出維護(hù)的需求變更可能具有更大的技術(shù)難度，此時(shí)，外包開(kāi)發(fā)商未必能支撐開(kāi)發(fā)從而導(dǎo)致外包開(kāi)發(fā)商在需求上顧左言他。
對(duì)于需求認(rèn)知折扣的問(wèn)題，快速原型模式可有效解決；對(duì)于外包開(kāi)發(fā)商因需求變更無(wú)法支撐開(kāi)發(fā)，可在設(shè)計(jì)過(guò)程要求其提供架構(gòu)設(shè)計(jì)，從而避免外包開(kāi)發(fā)商在需求認(rèn)知上打折扣；同時(shí)，應(yīng)對(duì)需求響應(yīng)機(jī)制做變革，尤其是項(xiàng)目初始需求，如在需求響應(yīng)上，對(duì)客戶提出的一些不可理喻之類(lèi)的需求應(yīng)當(dāng)有一套完善的響應(yīng)機(jī)制，包括技術(shù)上和業(yè)務(wù)上說(shuō)服客戶并尋求解決方案。
2.2需求界定的模糊
需求范圍，實(shí)際上就是確定要開(kāi)發(fā)出怎樣的一個(gè)軟件產(chǎn)品，界定功能從根本上抑制了客戶不合理的需求。需求界定，目的就是給軟件開(kāi)發(fā)方（電信呼叫中心的外包商）和軟件需求方（電信呼叫中心的客戶）一個(gè)明確的功能范疇，回答的就是要做什么？在一個(gè)特定行業(yè)里，軟件具有通用性和一般意義上的功能需求，言則，呼叫中心行業(yè)的軟件也是如此。但行業(yè)軟件不能代替具體個(gè)體的軟件需求，更何況呼叫中心的軟件是面對(duì)各行各業(yè)，基礎(chǔ)架構(gòu)可以相同，但具體功能塊的意義卻存在一定特異性。
對(duì)于呼叫中心軟件，在需求階段，需求的界定仍然是不可或缺的，但目前存在兩個(gè)思維上的陷阱：一是需求的界定依賴(lài)經(jīng)驗(yàn)，一般沒(méi)有任何需求過(guò)程就直接交付外包商去進(jìn)行設(shè)計(jì)開(kāi)發(fā)；二是追求功能上的通用性，重于可配置的說(shuō)法，而對(duì)架構(gòu)的通用性卻沒(méi)有任何歸納和提升，舍本逐末可見(jiàn)一斑。除這兩點(diǎn)影響到需求的界定，需求認(rèn)知的折扣也一定程度上使需求的界定南轅北轍。
這里有個(gè)例子，在電話呼入的關(guān)聯(lián)應(yīng)用界面上，根據(jù)經(jīng)驗(yàn)，電信方提出在彈屏上顯示的客戶資料可由客戶自己配置并給出常用的資料字段意義，這一點(diǎn)是針對(duì)所謂可配置的提法又是借鑒當(dāng)前一些客戶的彈屏資料需求，從業(yè)務(wù)功能上說(shuō)沒(méi)什么可挑剔，但從技術(shù)上分析，卻是相當(dāng)粗淺。表現(xiàn)在數(shù)據(jù)庫(kù)和性能設(shè)計(jì)上有過(guò)多負(fù)擔(dān)，在界面編排上則過(guò)于粗糙，而在業(yè)務(wù)管理上也不能達(dá)到通用軟件（從一個(gè)客戶移植到另一個(gè)客戶，不需要代碼改造而直接進(jìn)行業(yè)務(wù)配置）的意義。
愚見(jiàn)：不如在架構(gòu)設(shè)計(jì)上預(yù)留接口來(lái)應(yīng)對(duì)不同客戶不同彈屏資料的需求，就是在技術(shù)設(shè)計(jì)上達(dá)到通用軟件的意義而非業(yè)務(wù)管理上。因要求業(yè)務(wù)管理上的通用性，不但影響性能更導(dǎo)致界面粗糙，而就目前來(lái)看，幾乎每個(gè)新客戶都要進(jìn)行或多或少的技術(shù)改造，既然如此，不如在架構(gòu)上設(shè)計(jì)好這些不同業(yè)務(wù)應(yīng)用，避免給客戶造成軟件粗鄙的感覺(jué)。關(guān)于需求界定的文章，筆者另有專(zhuān)述。
2.3項(xiàng)目控制的錯(cuò)位
值得大書(shū)特書(shū)的是項(xiàng)目在各個(gè)階段延期現(xiàn)象的普遍性，更離奇的是對(duì)外包商在延期上的縱容，導(dǎo)致延期的原因在于沒(méi)有有效的利用軟件工程方法和工具來(lái)控制，使外包商在項(xiàng)目進(jìn)度上處于主導(dǎo)地位，此為錯(cuò)位體現(xiàn)之一；項(xiàng)目各階段工作成果離預(yù)期相去甚遠(yuǎn)，原因則在于對(duì)項(xiàng)目工作過(guò)程的控制幾乎為零，通過(guò)項(xiàng)目例會(huì)和幾張excel表完全無(wú)法達(dá)到實(shí)質(zhì)控制的效果，反而被外包商的延期引發(fā)我方的工作目標(biāo)和工作計(jì)劃修改，此為錯(cuò)位體現(xiàn)之二。 技術(shù)上使外包商居于主導(dǎo)地位，在項(xiàng)目進(jìn)度和項(xiàng)目質(zhì)量以及項(xiàng)目資源調(diào)配上都極大影響著我方的效益。
要從根本上解決這個(gè)問(wèn)題，就是要建立一套運(yùn)作機(jī)制和一個(gè)技術(shù)平臺(tái)，在技術(shù)上使我方居于主導(dǎo)地位。任何試圖不從技術(shù)上尋找控制方法的都將失敗，沒(méi)有實(shí)力就無(wú)法達(dá)到控制目的，只能任由技術(shù)控制方來(lái)主導(dǎo)項(xiàng)目進(jìn)展。技術(shù)控制方才清晰知道需求能否以及如何實(shí)現(xiàn)，何時(shí)以及是否可完工。關(guān)于項(xiàng)目控制中的主導(dǎo)地位問(wèn)題，筆者在其他文章中有專(zhuān)門(mén)闡述。
2.4工作成果的零亂
零亂，項(xiàng)目階段性工作成果不齊全和工作內(nèi)容不到位。軟件生命周期的每一個(gè)階段，外包商并沒(méi)有提供齊全的工作成果，即便提供了部分成果，其離標(biāo)準(zhǔn)軟件工程的要求還有相當(dāng)大差距，“偷工減料”并不足以為反應(yīng)這種現(xiàn)象，只能用“得過(guò)且過(guò)”來(lái)刻畫(huà)外包商應(yīng)付電信方軟件需求的心態(tài)。軟件工程在之所以成為一門(mén)學(xué)科，有其理論和實(shí)踐，表現(xiàn)出極大生命力，呼叫中心軟件開(kāi)發(fā)無(wú)疑是大型的軟件工作，利用軟件工程來(lái)完成是絕對(duì)有必要的；而軟件工程演變到今天，文檔重于代碼，既是大多數(shù)有經(jīng)驗(yàn)軟件開(kāi)發(fā)人員所認(rèn)同，也體現(xiàn)了工程化和標(biāo)準(zhǔn)化的思想，更是今天龐大軟件開(kāi)放與共享的基石。在軟件項(xiàng)目外包中，對(duì)電信方而言，要的就是軟件的文檔成果，如果電信方自己可以產(chǎn)生代碼就不需要外包了。
2.5設(shè)計(jì)開(kāi)發(fā)過(guò)程的零控制
一旦把需求交付給外包商，直到測(cè)試驗(yàn)收，中間的設(shè)計(jì)開(kāi)發(fā)控制目前是處于空白的。實(shí)際上，這一部分的完成主體就是外包商，但問(wèn)題是電信方所提交的需求本身就或是不完善或是沒(méi)有得到客戶認(rèn)可的，而測(cè)試驗(yàn)收上往往沒(méi)有驗(yàn)收依據(jù)和標(biāo)準(zhǔn)，如之，如果不對(duì)設(shè)計(jì)開(kāi)發(fā)進(jìn)行一定控制，項(xiàng)目延期便是司空見(jiàn)慣的了。在技術(shù)一定要由我方主導(dǎo)，尤其在設(shè)計(jì)上，需求分析和概要設(shè)計(jì)是必須控制到位的，也必須是我方主導(dǎo)完成的。
面對(duì)一個(gè)問(wèn)題或一件事，完成或解決不能基于“不會(huì)”的心態(tài)，只有“不能”做到，也只有信息“不全”導(dǎo)致解決起來(lái)有難度，“不會(huì)”要去學(xué)去試驗(yàn)而不能成為借口。外包商的項(xiàng)目延期是因技術(shù)的“不會(huì)”還是“不能”就需要電信方有技術(shù)上的分析，而不能聽(tīng)?wèi){外包商之言語(yǔ)，如果是技術(shù)“不能”或信息“不全”則可以另找解決方案，如是“不會(huì)”則不能遷就。要避免外包商的“不會(huì)”就要在設(shè)計(jì)上要求外包商對(duì)需求做充分的技術(shù)分析，包括有技術(shù)難度的開(kāi)發(fā)量和開(kāi)發(fā)周期并進(jìn)行一定的試驗(yàn)，一切要建立在試驗(yàn)基礎(chǔ)上作分析。如果外包商在設(shè)計(jì)上已經(jīng)肯定了需求上是完全可以實(shí)現(xiàn)，那么開(kāi)發(fā)中出現(xiàn)因“不會(huì)”導(dǎo)致的延期就是外包商的問(wèn)題。如果設(shè)計(jì)過(guò)程中，經(jīng)過(guò)試驗(yàn)，某些功能需求在技術(shù)上存在“不能”的程度，那么就當(dāng)尋找替代解決方案并向客戶反饋。
充分的設(shè)計(jì)、分析、試驗(yàn)是避免項(xiàng)目延期的關(guān)鍵步驟，但在當(dāng)前是缺失的。項(xiàng)目延期是設(shè)計(jì)開(kāi)發(fā)過(guò)程零控制帶來(lái)的問(wèn)題之一，需求變更找不到切入點(diǎn)則是問(wèn)題之二。在設(shè)計(jì)過(guò)程中，要做代碼開(kāi)發(fā)量估計(jì)，細(xì)分模塊并落實(shí)到具體實(shí)現(xiàn)者和完成時(shí)間，即是控制的粒度。當(dāng)前電信方是控制到系統(tǒng)級(jí)和功能級(jí)的粒度，而在菜單級(jí)或按鈕級(jí)上是沒(méi)有控制的，這首先是具體問(wèn)題的引發(fā)無(wú)法有效定位，更核心的是需求變更時(shí)找不到切入點(diǎn)，以至于對(duì)需求變更（包括設(shè)計(jì)開(kāi)發(fā)過(guò)程的變更和系統(tǒng)維護(hù)過(guò)程中的變更）的響應(yīng)度低，反應(yīng)在需求上就是不能很肯定地給予確認(rèn)或否認(rèn)。在設(shè)計(jì)過(guò)程上，細(xì)化到菜單和按鈕，界面和性能都需要一一給出，嚴(yán)格按照標(biāo)準(zhǔn)設(shè)計(jì)文檔要求完成。
2.6測(cè)試驗(yàn)收和維護(hù)的流程和機(jī)制不健全
測(cè)試的無(wú)的放矢、驗(yàn)收的無(wú)根據(jù)、維護(hù)的隨意性，問(wèn)題的根源在于沒(méi)有一定流程和機(jī)制。測(cè)試什么；測(cè)試后的問(wèn)題如何跟蹤；根據(jù)什么驗(yàn)收；驗(yàn)收的標(biāo)準(zhǔn)是什么；誰(shuí)來(lái)做網(wǎng)絡(luò)、平臺(tái)等的維護(hù)；如何響應(yīng)需求變更；回答這些問(wèn)題對(duì)當(dāng)前來(lái)說(shuō)相當(dāng)沉重，往往隨機(jī)而定，推搪工作責(zé)任便因此而產(chǎn)生。
關(guān)于維護(hù)流程有個(gè)不得不提到的誤區(qū)就是當(dāng)前流程或約定的慣性做法，就是故障維護(hù)（包括網(wǎng)絡(luò)、服務(wù)器、平臺(tái)、軟件、終端）由技術(shù)人員（不明白這個(gè)“技術(shù)”定義的范圍，是懂軟件、懂網(wǎng)絡(luò)、懂平臺(tái)、懂終端還是要懂什么，反正逮個(gè)知道IT概念的就是技術(shù)人員）來(lái)負(fù)責(zé)響應(yīng)，而需求變更則由客戶經(jīng)理（始終不明白是做什么的，但非技術(shù)人員是可以肯定的）來(lái)響應(yīng)。這樣的誤區(qū)是源于一個(gè)傳統(tǒng)思維，那就是故障是關(guān)于技術(shù)方面，而需求是關(guān)于業(yè)務(wù)方面的，理所當(dāng)然故障就是技術(shù)人員來(lái)響應(yīng)，而需求變更則是客戶經(jīng)理的職責(zé)范圍。
實(shí)際上需求是真正的技術(shù)活，在軟件工程里，系統(tǒng)分析師是負(fù)責(zé)需求階段工作，而系統(tǒng)分析師是在軟件工程領(lǐng)域是最高級(jí)別的工程師。很簡(jiǎn)單的一個(gè)道理，面對(duì)一個(gè)需求，要回答能不能實(shí)現(xiàn)和多大變動(dòng)以及工作量等（這些關(guān)涉到上文提到的需求變更切入點(diǎn)問(wèn)題），客戶經(jīng)理是回答不了的，只有對(duì)之前軟件設(shè)計(jì)有充分掌握并且具備相當(dāng)高設(shè)計(jì)開(kāi)發(fā)技術(shù)的系統(tǒng)分析師才能回答，而通過(guò)客戶經(jīng)理轉(zhuǎn)述的需求就表現(xiàn)出需求傳遞過(guò)程的折扣，而且需要與客戶幾個(gè)回合的確認(rèn)。信息的傳遞每經(jīng)過(guò)一個(gè)環(huán)節(jié)，就被當(dāng)事人用自己的理解方式和思維能力加工一次；需求變更的響應(yīng)要做技術(shù)風(fēng)險(xiǎn)和技術(shù)實(shí)現(xiàn)評(píng)估，一旦需求誤解導(dǎo)致的軟件返工在時(shí)間和成本上都是難以想象的。對(duì)于故障維護(hù)的響應(yīng)，則沒(méi)有多大的技術(shù)活，只要知道這個(gè)軟件的功能，描述下故障情景則相當(dāng)容易，這對(duì)于客戶經(jīng)理來(lái)說(shuō)勝任是可以肯定的，除非客戶經(jīng)理對(duì)客戶的軟件是零認(rèn)識(shí)。
這里要做一個(gè)概念區(qū)分：故障維護(hù)的響應(yīng)和解決故障維護(hù)是兩個(gè)層面的問(wèn)題，需求變更的響應(yīng)和需求變更的實(shí)現(xiàn)也是如此。故障的響應(yīng)需要的就是把問(wèn)題描述清楚，然后轉(zhuǎn)給維護(hù)人員解決，并沒(méi)有技術(shù)含量，解決故障才需要技術(shù)含量，所以故障的響應(yīng)并不一定非要技術(shù)人員；需求變更的響應(yīng)則一定需要技術(shù)人員，而且非得是系統(tǒng)分析師級(jí)才能定位需求，并作技術(shù)風(fēng)險(xiǎn)和技術(shù)實(shí)現(xiàn)的評(píng)估。建立其故障和需求變更的響應(yīng)流程的機(jī)制是迫切的，而對(duì)于后面支撐的故障維護(hù)和需求實(shí)現(xiàn)同樣如此。
3.快速原型模型簡(jiǎn)介
軟件開(kāi)發(fā)模型（Software Development Model）是指軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，包括需求、設(shè)計(jì)、編碼和測(cè)試等階段，有時(shí)也包括維護(hù)階段。早期的瀑布模型采用線性過(guò)程來(lái)開(kāi)發(fā)軟件，存在軟件需求不明確帶來(lái)的開(kāi)發(fā)風(fēng)險(xiǎn)，快速原型模型則克服該缺點(diǎn)，其本質(zhì)上是迭代的。
快速原型的思想核心是原型概念，在獲得基本需求后，快速建立一個(gè)可以運(yùn)行的軟件原型，通過(guò)原型反饋，加深對(duì)系統(tǒng)理解，使用戶在試用過(guò)程中受到啟發(fā)，對(duì)需求說(shuō)明進(jìn)行補(bǔ)充和精確化，消除不協(xié)調(diào)的系統(tǒng)需求，逐步確定各種需求，從而獲得合理、協(xié)調(diào)一致、無(wú)歧義的、完整的、現(xiàn)實(shí)可行的需求說(shuō)明。通過(guò)建立原型并反饋原型，可以達(dá)到理解需求，在開(kāi)發(fā)團(tuán)隊(duì)和用戶業(yè)務(wù)需求上達(dá)成共識(shí)。
快速原型模型允許在需求分析階段對(duì)軟件的需求進(jìn)行初步而非完全的分析和定義，快速設(shè)計(jì)開(kāi)發(fā)出軟件系統(tǒng)的原型，該原型向用戶展示待開(kāi)發(fā)軟件的全部或部分功能和性能；用戶對(duì)該原型進(jìn)行測(cè)試評(píng)定，給出具體改進(jìn)意見(jiàn)以豐富細(xì)化軟件需求；開(kāi)發(fā)人員據(jù)此對(duì)軟件進(jìn)行修改完善，直至用戶滿意認(rèn)可之后，進(jìn)行軟件的完整實(shí)現(xiàn)及測(cè)試、維護(hù)。
快速原型模型的兩個(gè)關(guān)鍵思想：一是原型的原理；二是快速的思想。經(jīng)過(guò)對(duì)基本需求的快速分析，快速搭建一個(gè)原型模型，通過(guò)對(duì)原型的不斷試用、評(píng)價(jià)、反饋、改進(jìn)以提高軟件質(zhì)量，并交付最終滿足用戶需求并真正實(shí)現(xiàn)了用戶需求的產(chǎn)品。快速原型從迭代的角度，可從圖3-1 快速原型的迭代表示圖；結(jié)合軟件開(kāi)發(fā)全過(guò)程，可從圖3-2 快速原型模型圖中切入快速原型的需求分析階段。
原型開(kāi)發(fā)步驟：
1）快速分析
在分析人員與用戶密切配合下，迅速確定系統(tǒng)的基本需求，根據(jù)原型所要體現(xiàn)的特征描述基本需求以滿足開(kāi)發(fā)原型的需要。
?2）構(gòu)造原型
在快速分析的基礎(chǔ)上，根據(jù)基本需求說(shuō)明盡快實(shí)現(xiàn)一個(gè)可行的系統(tǒng)。這里要求具有強(qiáng)有力的軟件工具的支持，并忽略最終系統(tǒng)在某些細(xì)節(jié)上的要求，如安全性、堅(jiān)固性、例外處理等等，主要考慮原型系統(tǒng)能夠充分反映所要評(píng)價(jià)的特性，而暫時(shí)刪除一切次要內(nèi)容。
3）運(yùn)行原型。
這是發(fā)現(xiàn)問(wèn)題、消除誤解、開(kāi)發(fā)者與用戶充分協(xié)調(diào)的一個(gè)步驟。
4）評(píng)價(jià)原型
在運(yùn)行的基礎(chǔ)上，考核評(píng)價(jià)原型的特性，分析運(yùn)行效果是否滿足用戶的愿望，糾正過(guò)去交互中的誤解與分析中的錯(cuò)誤，增添新的要求，并滿足因環(huán)境變化或用戶的新想法引起的系統(tǒng)要求變動(dòng)，提出全面的修改意見(jiàn)。
5）修改
根據(jù)評(píng)價(jià)原型的活動(dòng)結(jié)果進(jìn)行修改。若原型未滿足需求說(shuō)明的要求，說(shuō)明對(duì)需求說(shuō)明存在不一致的理解或?qū)崿F(xiàn)方案不夠合理，則根據(jù)明確的要求迅速修改原型。
本文著重于快速原型模型開(kāi)發(fā)過(guò)程中需求分析階段利用原型進(jìn)行若干次迭代，從而有效地獲取和理解用戶需求。在需求分析階段進(jìn)行迭代，其成果就是需求說(shuō)明，有需求說(shuō)明可進(jìn)入設(shè)計(jì)編碼，并作為最后測(cè)試驗(yàn)收依據(jù)。基于原型模型原型的商業(yè)呼叫中心SPOMP正是在快速和原型兩個(gè)核心思想上，強(qiáng)化需求分析階段的工作成果，使外包商的設(shè)計(jì)和開(kāi)發(fā)有出發(fā)點(diǎn)而不偏離需求方向，同時(shí)在各個(gè)開(kāi)發(fā)階段提出相應(yīng)方法集和工具集來(lái)管理軟件外包。利用了快速原型模型的原理，并按照軟件開(kāi)發(fā)生命周期的階段來(lái)給出SPOMP是本文的立足點(diǎn)。
3.商業(yè)呼叫中心SPOMP
軟件項(xiàng)目外包需求階段是關(guān)鍵和核心環(huán)節(jié)，對(duì)于商業(yè)呼叫中心的軟件外包也是如此，如你要把一件事交給起他人完成，總要清楚描述你對(duì)這件事希望達(dá)到的效果。既需求是重要的，那么在建立SPOMP上，關(guān)注需求階段的工作便是核心。快速原型模型的特點(diǎn)就關(guān)注需求階段的工作，同時(shí)從商業(yè)呼叫中心的特點(diǎn)出發(fā)，用快速原型模型實(shí)現(xiàn)建立其SPOMP具有優(yōu)勢(shì)。同時(shí)，呼叫中心外包的業(yè)務(wù)軟件是集成軟件，需求上需要反復(fù)認(rèn)可，也是利用快速原型模型建立SPOMP的出發(fā)點(diǎn)。商業(yè)外包呼叫中心的平臺(tái)和業(yè)務(wù)軟件基礎(chǔ)架構(gòu)是固定的，商業(yè)外包時(shí)根據(jù)行業(yè)和企業(yè)的特定需求開(kāi)發(fā)業(yè)務(wù)應(yīng)用，此時(shí)在快速原型的需求提供上可以利用之前的軟件架構(gòu)和業(yè)務(wù)應(yīng)用作為原型，而不需要再次去搭建原型。
3.1 建立SPOMP的出發(fā)點(diǎn)
建立商業(yè)呼叫中心SPOMP的關(guān)鍵是需求階段的工序和工具，同時(shí)，需要在軟件外包的整個(gè)過(guò)程按照軟件工程的快速原型模型來(lái)監(jiān)控和完成，同樣需要給予一定方法和工具來(lái)配合完成，才能建立完善的SPOMP。這里簡(jiǎn)單總結(jié)下為什么要用快速原型模型來(lái)建立商業(yè)呼叫中心的SPOMP？即基于怎樣的出發(fā)點(diǎn)？
1）商業(yè)呼叫中心軟件外包的現(xiàn)狀決定應(yīng)從軟件生命周期的各階段上加強(qiáng)控制，而商呼叫中心軟件外包中需求分析階段是核心，因此采用快速原型模型來(lái)建立SPOMP；
2）商業(yè)呼叫中心平臺(tái)和軟件基礎(chǔ)架構(gòu)以及商業(yè)外包的性質(zhì)，決定了在快速建立模型上有優(yōu)勢(shì)和低成本；
3）商業(yè)呼叫中心軟件外包貫穿的軟件開(kāi)發(fā)過(guò)程都存在控制問(wèn)題，因此需要在快速原型模型基礎(chǔ)上加強(qiáng)對(duì)軟件開(kāi)發(fā)各階段的控制；
4）借助快速原型模型的原理作好需求分析階段，同時(shí)按照軟件生命周期的開(kāi)發(fā)過(guò)程給出方法集和工具集來(lái)建立SPOMP；
所要建立的商業(yè)呼叫中心SPOMP是基于快速原型模型的快速和原型原理來(lái)控制需求分析階段，同時(shí)快速原型模型本身就是軟件生命周期模型，包含完整的軟件開(kāi)發(fā)過(guò)程，基于軟件外包現(xiàn)狀，在連貫需求分析階段上設(shè)計(jì)一些方法配合工具來(lái)控制軟件外包的設(shè)計(jì)、編碼、測(cè)試過(guò)程，使外包項(xiàng)目在進(jìn)度和成本上得到有效控制。商業(yè)呼叫中心SPOMP就是針對(duì)軟件外包項(xiàng)目，應(yīng)用快速原型模型的原理建立商業(yè)呼叫中心軟件外包過(guò)程的方法集和工具集，給出SPOMP整體軟件生命周期，即工序，同時(shí)為每個(gè)工序制定方法和工具。
3.2 商業(yè)呼叫中心SPOMP
這里先給出基于快速原型模型的軟件項(xiàng)目外包生命周期，后就生命周期各階段給出方法和工具。軟件外包和商業(yè)呼叫中心的商業(yè)外包性質(zhì)決定了需求分析階段的重要性；商業(yè)呼叫中心現(xiàn)狀要求對(duì)軟件外包的生命周期各個(gè)階段加強(qiáng)控制；基于此，應(yīng)用快速原型模型的原理，研究建立一套以快速原型模型為藍(lán)本的適合商業(yè)呼叫中心軟件外包管理的工序流程及相應(yīng)的方法集和工具集，即商業(yè)呼叫中心SPOMP，目的是高效地理解用戶需求和實(shí)現(xiàn)用戶需求。
3.2.1 SPOMP的軟件生命周期模型
以快速原型模型為基礎(chǔ)建立SPOMP的生命周期模型，即工序，給出流程和每個(gè)環(huán)節(jié)需要提交的成果，涉及三方，分別是軟件廠商、商業(yè)呼叫中心和客戶。SPOMP的軟件生命周期模型見(jiàn)圖3-3 SPOMP的軟件生命周期模型圖。
?
1）需求定義
步驟一：需求定義是在商業(yè)呼叫中心和客戶之間進(jìn)行，主要是提取客戶最基本需求，由客戶描述其基本需求，商業(yè)呼叫中心制作出對(duì)應(yīng)的行業(yè)或企業(yè)呼叫中心解決方案。
輸入：客戶基本需求；
輸出：呼叫中心解決方案；
步驟二：應(yīng)用快速原型模型的核心原理：快速、原型。根據(jù)提供給客戶的初步呼叫中心解決方案選擇行業(yè)相同或需求相似的已有客戶呼叫中心軟件作為原型，商業(yè)呼叫中心的商業(yè)外包性質(zhì)在原型建立上就具有這個(gè)優(yōu)勢(shì)，不需要建立原型而是將已有業(yè)務(wù)軟件作為原型。
輸入：初步呼叫中心解決方案；
輸出：行業(yè)相同或需求相似的呼叫中心業(yè)務(wù)軟件作為原型；
如果客戶提出的需求在業(yè)有呼叫中心軟件里都沒(méi)有原型的影子，首先這個(gè)可能性極其低，如果確實(shí)有存在，那么還是可以將這部分保留在呼叫中心解決方案中不作原型評(píng)價(jià)，而大部分需求存在原型的，則繼續(xù)迭代。
步驟三：指導(dǎo)客戶運(yùn)行、評(píng)價(jià)原型，使客戶對(duì)產(chǎn)品有實(shí)際體會(huì)，從而矯正自己的需求描述或提出需求變更和擴(kuò)大需求范圍，對(duì)商業(yè)呼叫中心軟件產(chǎn)品本身也是一種營(yíng)銷(xiāo)。這個(gè)過(guò)程要開(kāi)始應(yīng)用快速原型模型的核心原理：迭代。客戶運(yùn)行后的評(píng)價(jià)結(jié)果，重復(fù)到步驟一，修改和完善呼叫中心解決方案，再到步驟二及步驟三。
輸入：原型；
輸出：原型評(píng)價(jià)結(jié)果；
需求定義應(yīng)用快速原型模型原理完成需求確認(rèn)，最終輸出結(jié)果是客戶的呼叫中心解決方案。
2）需求分析
需求定義的輸出結(jié)果是呼叫中心解決方案，是與客戶按照快速原型模型原理反復(fù)進(jìn)行和確認(rèn)的，需求相對(duì)明確和文檔化。需求分析中，客戶不再需要參與，而在軟件外包廠商與商業(yè)呼叫中心進(jìn)行。
首先商業(yè)呼叫中心交付解決方案予軟件廠商，由軟件廠商進(jìn)行技術(shù)試驗(yàn)和工作量分析，完成需求規(guī)格說(shuō)明書(shū)。技術(shù)試驗(yàn)要針對(duì)解決方案中具有較高難度的進(jìn)行先期試驗(yàn)，如果未能實(shí)現(xiàn)或需要很長(zhǎng)時(shí)間需要與客戶明確，排除風(fēng)險(xiǎn)。技術(shù)試驗(yàn)要給出報(bào)告，同時(shí)加入到需求規(guī)格說(shuō)明書(shū)里作為下個(gè)環(huán)節(jié)的參考。工作量分析在于給出進(jìn)度，利于外包控制。
輸入：呼叫中心解決方案；
輸出：需求規(guī)格說(shuō)明書(shū)、技術(shù)試驗(yàn)報(bào)告、項(xiàng)目進(jìn)度表；
3）設(shè)計(jì)
設(shè)計(jì)階段主要是由軟件廠商完成，商業(yè)呼叫中心控制進(jìn)度和審核工作成果。概要設(shè)計(jì)階段要產(chǎn)生概要設(shè)計(jì)說(shuō)明書(shū)，主要關(guān)注軟件的業(yè)務(wù)架構(gòu)和物理部署，業(yè)務(wù)架構(gòu)看是否滿足呼叫中心平臺(tái)和解決方案以及二次開(kāi)發(fā)；物理部署則要看是否存在硬件資源可節(jié)省之出，如災(zāi)備上不同方案對(duì)硬件資源的需求量是不同的。詳細(xì)設(shè)計(jì)階段的說(shuō)明書(shū)要重點(diǎn)關(guān)注是否進(jìn)行軟件工作量估計(jì)，從而有效地把系統(tǒng)每個(gè)功能塊納入進(jìn)度控制。
輸入：需求規(guī)格說(shuō)明書(shū)、項(xiàng)目進(jìn)度表；
輸出：概要設(shè)計(jì)說(shuō)明書(shū)、詳細(xì)設(shè)計(jì)說(shuō)明書(shū)；
4）編碼
編碼主要是軟件廠商完成，商業(yè)呼叫中心只需要按照詳細(xì)設(shè)計(jì)說(shuō)明書(shū)中給出每個(gè)功能塊進(jìn)度進(jìn)行控制和跟蹤即可。
5）測(cè)試驗(yàn)收
測(cè)試驗(yàn)收要分為兩個(gè)步驟，測(cè)試在商業(yè)呼叫中心和軟件廠商，驗(yàn)收在商業(yè)呼叫中心和客戶。測(cè)試要根據(jù)不同情況來(lái)進(jìn)行，集成系統(tǒng)要建議采用測(cè)試案例來(lái)。
步驟一：測(cè)試要分功能測(cè)試（含UI測(cè)試點(diǎn)）和性能測(cè)試，由軟件廠商根據(jù)詳細(xì)設(shè)計(jì)說(shuō)明書(shū)出功能測(cè)試用例和系統(tǒng)性能測(cè)試用例，商業(yè)呼叫中心根據(jù)測(cè)試用例進(jìn)行測(cè)試，并給出測(cè)試報(bào)告，由軟件廠商根據(jù)測(cè)試修正系統(tǒng)。
輸入：功能測(cè)試用例、系統(tǒng)性能測(cè)試用例；
輸出：測(cè)試報(bào)告；
步驟二：驗(yàn)收要提供功能驗(yàn)收表，由客戶進(jìn)行驗(yàn)收。
輸入：功能驗(yàn)收表；
輸出：軟件產(chǎn)品
6）運(yùn)行維護(hù)
運(yùn)維納入日常商業(yè)呼叫中心外包客戶維護(hù)體系，故障響應(yīng)機(jī)制和處理流程必須有統(tǒng)一的規(guī)劃和執(zhí)行。軟件廠商必須提供用戶操作手冊(cè)和維護(hù)手冊(cè)。
3.2.2 SPOMP的方法集和工具集
SPOMP的軟件生命周期模型給出了流程和階段要出的成果，從工程化角度完成SPOMP的任務(wù)，接下來(lái)需要對(duì)階段成果進(jìn)行標(biāo)準(zhǔn)化，使成果可以在廠商、呼叫中心或客戶之間達(dá)到共識(shí)并理解，要實(shí)現(xiàn)標(biāo)準(zhǔn)化的成果就要有一定方法和工具來(lái)完成。標(biāo)準(zhǔn)化的SPOMP工作成果，需要在軟件工程理論上給出方法，同時(shí)配合工具來(lái)完成。
對(duì)于SPOMP的軟件生命周期，與一般快速原型模型不無(wú)差別，同時(shí)，軟件主要工作在于軟件廠商，因此SPOMP的方法集和工具集主要是為軟件廠商提一個(gè)原則性的思路，要求軟件廠商按照標(biāo)準(zhǔn)化的軟件方法來(lái)完成呼叫中心所需要的軟件工作成果。
1）UML語(yǔ)言
UML既是一種建模方法，作為語(yǔ)言又是工具。在SPOMP上，不管基于怎樣的程序開(kāi)發(fā)語(yǔ)言，還是采用怎樣軟件開(kāi)發(fā)方法，必須用UML來(lái)建模。需求規(guī)格說(shuō)明書(shū)、概要設(shè)計(jì)說(shuō)明、詳細(xì)設(shè)計(jì)說(shuō)明書(shū)都要求以UML的建模圖形來(lái)完成。
無(wú)論對(duì)內(nèi)對(duì)外，或是今后系統(tǒng)升級(jí)或是為其他系統(tǒng)借鑒，用UML建模型所得的成果都具有通用和標(biāo)準(zhǔn)化的意義。要求軟件廠商在需求分析和設(shè)計(jì)階段完成的成果用標(biāo)準(zhǔn)UML建模圖完成。
2）COCOMOⅡ模型
對(duì)于軟件工作量的分析，按照COCOMOⅡ模型來(lái)。軟件工作量估算和技術(shù)試驗(yàn)分析是項(xiàng)目進(jìn)度和軟件成本控制的初始依據(jù)，必須嚴(yán)格要求軟件廠商做到位。COCOMOⅡ模型本身也是方法和工具的集合，要求軟件廠商按照標(biāo)準(zhǔn)來(lái)完成。
除按照UML語(yǔ)言和COCOMOⅡ模型來(lái)進(jìn)行建模和工作量分析以完成標(biāo)準(zhǔn)工作成果，SPOMP還就商業(yè)呼叫中心本身實(shí)際情況對(duì)SPOMP生命周期階段工作成果給出要求。
1）呼叫中心解決方案
針對(duì)不同客戶給出行業(yè)性或企業(yè)獨(dú)特性的呼叫中心解決方案，其內(nèi)容必須包括呼叫中心平臺(tái)組網(wǎng)和業(yè)務(wù)軟件需求定義。業(yè)務(wù)軟件需求定義要在與客戶進(jìn)行溝通不能過(guò)于專(zhuān)業(yè)，采用Visio工具給出流程和功能，或通過(guò)表格展示功能。
2）技術(shù)試驗(yàn)報(bào)告
技術(shù)試驗(yàn)報(bào)告是要求軟件廠商對(duì)需求進(jìn)行技術(shù)上預(yù)估計(jì)，在一些需求難點(diǎn)上先做技術(shù)試驗(yàn)。該報(bào)告含需求點(diǎn)、說(shuō)明難度點(diǎn)和難度值、試驗(yàn)環(huán)境、試驗(yàn)過(guò)程（含代碼）、試驗(yàn)結(jié)果（對(duì)項(xiàng)目及項(xiàng)目進(jìn)度的影響）。報(bào)告本身就是一份含程序代碼清單的技術(shù)說(shuō)明書(shū)，技術(shù)試驗(yàn)報(bào)告是防止軟件外包廠商以某個(gè)需求點(diǎn)有技術(shù)難度來(lái)解釋項(xiàng)目延期原因，另一方面對(duì)于商業(yè)呼叫中心掌握項(xiàng)目技術(shù)主導(dǎo)權(quán)有決定性作用。
3）項(xiàng)目進(jìn)度表
考慮到以往在項(xiàng)目上因?yàn)橐恍┨貏e原因如封網(wǎng)，對(duì)于項(xiàng)目時(shí)間的調(diào)整比較頻繁，因此要求軟件廠商的項(xiàng)目進(jìn)度表按PERT圖來(lái)體現(xiàn)。在項(xiàng)目實(shí)施過(guò)程，可以按照：①繪制網(wǎng)絡(luò)圖；②網(wǎng)絡(luò)計(jì)劃計(jì)算；③求關(guān)鍵路徑；④計(jì)算完工期及其概率；⑤網(wǎng)絡(luò)計(jì)劃優(yōu)化；這五個(gè)步驟來(lái)完成。
項(xiàng)目進(jìn)度表是項(xiàng)目控制的核心，同時(shí)對(duì)于詳細(xì)設(shè)計(jì)階段，進(jìn)行具體代碼塊分析時(shí)，也需要在整體項(xiàng)目進(jìn)度內(nèi)對(duì)編碼階段的各個(gè)代碼塊進(jìn)度給出完成時(shí)間點(diǎn)，尤其在一些里程碑功能點(diǎn)完成上就一定要有控制。 因此，SPOMP要求詳細(xì)設(shè)計(jì)說(shuō)明書(shū)里要給出代碼塊進(jìn)度表，這主要是根據(jù)經(jīng)驗(yàn)上要求的。
4）測(cè)試案例
測(cè)試用例按照軟件測(cè)試方法中標(biāo)準(zhǔn)方法實(shí)現(xiàn)，含輸入、過(guò)程、輸出、結(jié)果等的描述。根據(jù)經(jīng)驗(yàn)測(cè)試用例往往對(duì)難以全面覆蓋，如果軟件廠商有意掩蓋內(nèi)部測(cè)試時(shí)發(fā)現(xiàn)的BUG（項(xiàng)目到期，該BUG無(wú)法及時(shí)修正，只能隱瞞先交付），那么在測(cè)試用例上更無(wú)法有效體現(xiàn)。SPOMP要求軟件廠商提供測(cè)試案例，做仿真測(cè)試。往往由于測(cè)試覆蓋不全面，難以發(fā)現(xiàn)問(wèn)題和不滿足需求處，當(dāng)交付客戶使用后引發(fā)客戶極大不滿。仿真測(cè)試案例上，對(duì)于各個(gè)功能塊或集成系統(tǒng)能夠連成一體測(cè)試，覆蓋性較全面，而且有利于發(fā)現(xiàn)邊界BUG。
SPOMP經(jīng)過(guò)一年的探索，生命周期基本確定，在具體方法和工具有待不斷完善，如關(guān)于軟件作坊的工件化思路和外包業(yè)務(wù)架構(gòu)本人都有專(zhuān)門(mén)闡述。
3.2.3 SPOMP的效應(yīng)
商業(yè)呼叫中心SPOMP的生命周期模型實(shí)現(xiàn)了軟件項(xiàng)目外包的工程化，實(shí)現(xiàn)了工程化的SPOMP對(duì)項(xiàng)目進(jìn)度有清晰和透徹的掌握；同時(shí)其方法集和工具集標(biāo)準(zhǔn)化了軟件項(xiàng)目外包的工作成果，標(biāo)準(zhǔn)化的SPOMP對(duì)項(xiàng)目的工作成果有主導(dǎo)性和決定權(quán)。
1）SPOMP使商業(yè)呼叫中心對(duì)外包的軟件項(xiàng)目具有技術(shù)主導(dǎo)性
擁有技術(shù)主導(dǎo)性就對(duì)軟件廠商提出的項(xiàng)目延期和資源利用上有透徹把握。如軟件廠商提出因某個(gè)需求的實(shí)現(xiàn)而影響了項(xiàng)目開(kāi)發(fā)進(jìn)度，可以從技術(shù)試驗(yàn)報(bào)告或從需求規(guī)格說(shuō)明書(shū)以及詳細(xì)設(shè)計(jì)說(shuō)明書(shū)這些標(biāo)準(zhǔn)工作成果找出是否合乎實(shí)情。再如不同的軟件架構(gòu)可能對(duì)服務(wù)器提出不同的要求，最大化利用服務(wù)器資源可以節(jié)省硬件資源成本，如果概要設(shè)計(jì)軟件部署上，軟件廠商可能為了簡(jiǎn)化軟件開(kāi)發(fā)難度而采用犧牲硬件資源，技術(shù)主導(dǎo)性將遏止這種現(xiàn)象的發(fā)生。
技術(shù)主導(dǎo)性帶來(lái)的效應(yīng)：項(xiàng)目延期的控制；硬件資源成本的控制；項(xiàng)目質(zhì)量的把握。
2）SPOMP使商業(yè)呼叫中心實(shí)現(xiàn)對(duì)項(xiàng)目進(jìn)度的有效控制
項(xiàng)目進(jìn)度和紀(jì)律，這幾乎并無(wú)關(guān)系的兩個(gè)含義，但卻是正相關(guān)。只要按照軟件工程的紀(jì)律來(lái)，項(xiàng)目進(jìn)度才能有效控制。為什么？科學(xué)的理論和深刻的教訓(xùn)都告訴軟件從業(yè)者，按照一定的工序完成標(biāo)準(zhǔn)的工作成果是軟件取得成功的唯一秘訣。
因此，項(xiàng)目進(jìn)度一定要放在SPOMP上去控制，也一定按照SPOMP的工程化和標(biāo)準(zhǔn)化去完成生命周期內(nèi)的工作成果。
3）SPOMP有效地解決了商業(yè)呼叫中心存在的問(wèn)題
SPOMP生命周期應(yīng)用快速原型模型原理有效地解決了需求認(rèn)知折扣和需求界定模糊的問(wèn)題；SPOMP使商業(yè)呼叫中心在項(xiàng)目控制上居于主動(dòng)性地位，解決項(xiàng)目控制錯(cuò)位的問(wèn)題；SPOMP標(biāo)準(zhǔn)化的工作成果避免出現(xiàn)工作成果的零亂問(wèn)題；SPOMP通過(guò)工作成果的標(biāo)準(zhǔn)化來(lái)實(shí)現(xiàn)設(shè)計(jì)和編碼過(guò)程的參與；SPOMP的標(biāo)準(zhǔn)化工作成果有利于健全測(cè)試驗(yàn)收和維護(hù)流程。
結(jié)束語(yǔ)
商業(yè)呼叫中心軟件項(xiàng)目外包的管理是一個(gè)持續(xù)性并需要不斷提升效益生產(chǎn)能力的過(guò)程，需要也必須依賴(lài)一套行之有效的工序流程以及相應(yīng)的方法和工具，謂之平臺(tái)。平臺(tái)是針對(duì)于威權(quán)機(jī)制或說(shuō)是強(qiáng)人體制，目的是保證政策的有機(jī)性和連貫性。把軟件外包的管理寄托在某一優(yōu)秀管理者上，是不切實(shí)際而且無(wú)法保證該管理者永遠(yuǎn)是清晰和正確的，也無(wú)法保證威權(quán)的永恒，一人聽(tīng)斷，安能盡善。善于搭建平臺(tái)來(lái)保證事業(yè)或組織的可持續(xù)性發(fā)展而避免將自己塑造為偶像或強(qiáng)者形象，才是一名優(yōu)秀的管理者。工序?qū)⒆龅礁魉酒渎殹⒏骶推湮?#xff0c;職責(zé)明確，分工明晰；流程將保證工序成果的標(biāo)準(zhǔn)化移交；方法和工具是實(shí)現(xiàn)工序成果的手段；顯然還需要配套的體系，如是，平臺(tái)也。
總結(jié)
以上是生活随笔為你收集整理的基于快速原型模型建立商业呼叫中心SPOMP的应用研究的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： cookie及session
- 下一篇： 浅析IPDCC的地理信息识别和服务