泛架構(gòu)之于外包IT工程

立項(xiàng)性的IT工程在多數(shù)企業(yè)實(shí)際生產(chǎn)中是比較常見的，同時也面臨諸多問題，而問題的核心都指向如何管理外包工程。如何管理涉及兩點(diǎn)：誰來管理和管理什么。回答這兩個問題需要把外包IT工程作一個簡單分類，分類的標(biāo)準(zhǔn)是作為實(shí)際需求方的項(xiàng)目人員在工程實(shí)施過程中的參與度，如是分為：技術(shù)性參與和業(yè)務(wù)性參與。技術(shù)性參與更多強(qiáng)調(diào)在工程設(shè)計(jì)和實(shí)施過程中提出或要求如何實(shí)現(xiàn)；而業(yè)務(wù)性參與則重在前期需求的定義和后期的驗(yàn)收上線。根據(jù)企業(yè)性質(zhì)、工程性質(zhì)、項(xiàng)目人員等擇取一類來管理IT工程項(xiàng)目。這種分類在項(xiàng)目管理上并無嚴(yán)格的區(qū)分意義，只是作為本文切入架構(gòu)于項(xiàng)目管理意義的輔助而已。要回答“誰來管理以及管理什么”就需要在技術(shù)性參與和業(yè)務(wù)性參與上取各自偏好，而本文這里則傾向技術(shù)性參與下外包IT工程項(xiàng)目管理中架構(gòu)的意義。

要回答在技術(shù)性參與外包IT工程下的項(xiàng)目管理兩要點(diǎn)：誰來管理和管理什么，需要首先從項(xiàng)目管理中發(fā)現(xiàn)的問題入手。本文即從所參與的外包IT工程項(xiàng)目中覺察出的問題出發(fā)，論述從架構(gòu)的角度來解決，從而回答項(xiàng)目管理兩要點(diǎn)。誰來管理，這其中一個重要角色無疑是項(xiàng)目經(jīng)理，選擇一個怎么樣的項(xiàng)目經(jīng)理對項(xiàng)目的意義眾所周知；而評價一個項(xiàng)目經(jīng)理，個人覺得最簡單的莫過于這個項(xiàng)目經(jīng)理能否深入淺出的在沒有接觸或?qū)?xiàng)目零知識的受眾前介紹項(xiàng)目，能做到通俗化技術(shù)、簡單化原理的解釋則表明項(xiàng)目經(jīng)理成功融入了這個項(xiàng)目中。管理什么呢？項(xiàng)目經(jīng)理是管理一個平臺，而項(xiàng)目成員則應(yīng)當(dāng)關(guān)注進(jìn)度、內(nèi)容兩者。項(xiàng)目經(jīng)理，平臺提供者，如同政府在市場交易中的角色，技術(shù)性裁決和資源提供。

到此，本文的基調(diào)即確立，從問題的發(fā)現(xiàn)到架構(gòu)的解決，再通過平臺來回答項(xiàng)目管理兩要點(diǎn)。實(shí)際上，要完全把項(xiàng)目管理的一些精髓拿出來論述，何異于自尋煩惱。但若干要點(diǎn)確值得一說，三個：工程化思維、架構(gòu)把握、細(xì)節(jié)透徹。社會領(lǐng)域，肯定一個社會的進(jìn)步，最核心的在于平等的意識是否貫徹到公民的人格之中。平等的人格意識是這個社會中僅是口號而無依附，而作為項(xiàng)目管理靈魂核心的工程化思維在實(shí)際項(xiàng)目中往往也是口惠而實(shí)不在。關(guān)于工程化思維在項(xiàng)目管理中的一些方法和心得，筆者在工作流方面另有所著；而在細(xì)節(jié)透徹上也別有案例分析，此處不做深入關(guān)涉；本文重點(diǎn)談架構(gòu)把握，有針對性地作為解決問題的方法。

項(xiàng)目管理普遍遇到的兩類問題：一是需求范圍界定的經(jīng)驗(yàn)性和需求變更的不可控性，集中起來就是應(yīng)用解決方案也就是業(yè)務(wù)架構(gòu)是失敗的；二是資源引導(dǎo)和平衡上全部由外包集成商來決定，反應(yīng)出技術(shù)解決方案上的失敗。

需求范圍界定的經(jīng)驗(yàn)性是指由需求方根據(jù)行業(yè)既定的需求范圍直接給出需求標(biāo)書，然后外包商根據(jù)標(biāo)書制作軟件需求規(guī)格說明書，這個過程中外包商并沒有作需求調(diào)研，也就是沒有完成自己的需求范圍定義而直接就根據(jù)行業(yè)經(jīng)驗(yàn)把標(biāo)書的內(nèi)容作為需求的最根本依據(jù)，導(dǎo)致的后果就是外包商在一些具體需求上沒有完全領(lǐng)會，從而在項(xiàng)目設(shè)計(jì)中沒有充分考慮到需求變化的因素，最直接體現(xiàn)就是外包商拿著以前的產(chǎn)品來測試驗(yàn)收，從這點(diǎn)上我們認(rèn)為非常而且絕對有必要的要求外包商完成自己的需求調(diào)研，避免項(xiàng)目所交付產(chǎn)品不符合預(yù)期所導(dǎo)致的風(fēng)險，不單是軟件工程，在網(wǎng)絡(luò)工程中同樣。

需求變更的不可控性，一方面是衍生于需求范圍界定的經(jīng)驗(yàn)性而產(chǎn)生的問題，因?yàn)樾枨蠓秶鷽]有界定明確，導(dǎo)致實(shí)施過程甚至到產(chǎn)品交付時都出現(xiàn)需求變更，而這種變更由于在設(shè)計(jì)中沒有充分考慮導(dǎo)致需求的技術(shù)實(shí)現(xiàn)在一定程度上或在項(xiàng)目可控風(fēng)險上變成不可接受；另一方面則源于需求階段沒有一致認(rèn)可的階段性成果出來，導(dǎo)致之后一些需求的變更無法有效性體現(xiàn)出來，最明顯的就是需求變更該歸入到那個子系統(tǒng)或子功能范疇，這方面則重在需求管理工具上沒有到位。比如出現(xiàn)之前多次討論的需求改進(jìn)，沒有任何成文跟蹤，導(dǎo)致最后不了了之，而驗(yàn)收突然想到提出來，外包商只做無奈狀。

這一類問題歸結(jié)為業(yè)務(wù)應(yīng)用解決方案上，即業(yè)務(wù)架構(gòu)。從這點(diǎn)出發(fā)對項(xiàng)目管理者的要求就是必須熟悉業(yè)務(wù)的需求范圍并確立業(yè)務(wù)應(yīng)用解決方案，從業(yè)務(wù)應(yīng)用解決方案上糾正和認(rèn)同與外包商的需求定義。項(xiàng)目管理人員必須知道這個項(xiàng)目想要解決的問題是什么，需求即問題，應(yīng)用解決方案就是給出問題的解決方案。為什么要建立這個工程？如何解決呢？這都要體現(xiàn)在需求階段的業(yè)務(wù)應(yīng)用解決方案。如在呼叫中心中，服務(wù)人員需要有效快速獲取某些業(yè)務(wù)知識才能更好回復(fù)客戶，這是一個問題，如何解決呢？知識庫，在知識庫中存儲業(yè)務(wù)知識方便服務(wù)人員搜索出來作為回復(fù)客戶的答案，這就對知識庫知識條目的管理（達(dá)到共享）有一定的需求定義，需要在業(yè)務(wù)架構(gòu)上給出解決方案。需求范圍的界定和需求變更的控制是屬于業(yè)務(wù)架構(gòu)上的能力，統(tǒng)歸于應(yīng)用解決方案的提供。在項(xiàng)目管理上要求項(xiàng)目經(jīng)理具備業(yè)務(wù)架構(gòu)的能力或在業(yè)務(wù)需求上有明確的自我定義，管理應(yīng)用解決方案中的需求在變更或迭代時的統(tǒng)一性和持續(xù)性，同時評估好風(fēng)險，更應(yīng)協(xié)同進(jìn)度，善于使用需求管理工具來管控，避免經(jīng)驗(yàn)性和隨意性的方案。

對于需求階段的業(yè)務(wù)架構(gòu)除了要防范外包商在應(yīng)用解決方案上的經(jīng)驗(yàn)性，也要注意自身單位在需求上的控制，涉及到一個長期探討的話題——需求的無限擴(kuò)大化。缺少一個成熟的項(xiàng)目管理平臺（合適的人用合適的工具在進(jìn)行合適的事），其結(jié)果就是一群人在圍繞著一個大方向作了長時間的努力，最后發(fā)現(xiàn)實(shí)際需求要做無休止的更改，項(xiàng)目延期自然是難免了。維護(hù)和建立一個成熟的項(xiàng)目管理平臺，不僅僅是一個項(xiàng)目的事，還應(yīng)該是一個單位長久致力的核心。為了解決一個問題，設(shè)定一個目標(biāo)，迅速建立起合適人選的項(xiàng)目管理團(tuán)隊(duì)，并配合一個熟悉的工具環(huán)境，進(jìn)行著需求明確的項(xiàng)目工作。項(xiàng)目經(jīng)理無疑是這個平臺的關(guān)鍵角色，其本身就有在需求管理的統(tǒng)一裁決權(quán)利，但同時具備抑制和權(quán)衡需求無限擴(kuò)大化的能力。

什么是需求無限擴(kuò)大化，這里有個例子比較形象。在介紹例子前，必須再明確一個概念：軟件或IT只是一種工具，具有可替代性。曾于某地參與收割地瓜，基本程序是先用鐮刀把上面的莖葉割掉并收走，然后用鋤頭把地瓜挖出來，兩個工具鐮刀和鋤頭。這樣的一個流程和工具使用居然完美的包含分工這樣的一個概念，分工體現(xiàn)在分別使用鐮刀和鋤頭的人可以分工高效地完成自己份內(nèi)工作，在不同的階段用不同的工具做不同的事，工程化思維。當(dāng)時有人提出為什么不用鐮刀或鋤頭直接完成整個地瓜的收割工作呢？這從工具的角度上對收割工作提出了不同的看法，但實(shí)際效果是速度沒有鐮刀和鋤頭分開用快，因?yàn)殓牭哆m合割不適合挖，而鋤頭適合挖不適合割。當(dāng)時還有人提出每人都拿鐮刀和鋤頭，用鐮刀割完莖葉而后直接用鋤頭挖地瓜，而不只是完成割或挖的工作，這是在流程上提出不同的看法，當(dāng)然也不盡人如意。

如果有一種工具能夠綜合鐮刀和鋤頭的用法，那不是都滿足了嗎？這個就是對工具的新需求了，于是總有人覺得這肯定是個創(chuàng)新的想法，實(shí)際上每個工具的產(chǎn)生都源于實(shí)際生活的某一個特定需求，把需求混合起來去制造新的工具不見得就是效率，相反通過流程革新和分工合作使用不同的工具完成一個需求也是可以的。確立的主題是：一個特定需求對應(yīng)一種工具，如鐮刀是割水稻的、鋤頭是鋤草的；而收割地瓜這個需求要需要使用兩種工具并按照一定流程來完成，先鐮刀后鋤頭。這個時候需求無限擴(kuò)大化就會出現(xiàn)，就是上面提到的改造鐮刀或鋤頭使其既能割也能挖，應(yīng)景到軟件里就是改造軟件功能來滿足新需求。無限擴(kuò)大化的意思就在這里，根據(jù)一個新需求（收割地瓜）一定要在已存在的軟件（工具）提出新的功能，讓軟件似是而非（鐮刀和鋤頭的綜合物），這種對軟件（工具）的需求就是一種偏離實(shí)際生產(chǎn)情況提出而且存在無限擴(kuò)大化的趨勢。業(yè)務(wù)上曼妙的需求一定要在軟件（工具）上達(dá)到完美的體現(xiàn)是這種需求存在的原因。有時候不一定要在工具改造下心思，而在流程和分工同樣能達(dá)到效果。軟件是替代現(xiàn)實(shí)工作中的一個工具，其功能是適應(yīng)一定需求的，泛功能化的軟件意義不存在的。那么從業(yè)務(wù)架構(gòu)上，對項(xiàng)目管理來說，控制需求對軟件的擴(kuò)大化要求盡管不是一項(xiàng)必須和核心工作，但在某種程度上是對項(xiàng)目正常進(jìn)行必須注意的事項(xiàng)。項(xiàng)目管理人員往往會陷入這種需求的提出而不自覺。

業(yè)務(wù)架構(gòu)上的問題側(cè)重在需求上，而技術(shù)架構(gòu)則在實(shí)施上重點(diǎn)在設(shè)計(jì)上。資源的引導(dǎo)和平衡應(yīng)該是由需求方根據(jù)自己現(xiàn)狀對外包商在設(shè)計(jì)和實(shí)施上提出要求的，但如果項(xiàng)目管理人員沒有配合IT方面的專業(yè)人員參與設(shè)計(jì)則可能導(dǎo)致這項(xiàng)工作由外包商決定。什么資源呢？服務(wù)器、中繼數(shù)、寬帶等，顯然一臺服務(wù)器的硬件資源能夠滿足軟件運(yùn)行需要，為什么一定要兩臺呢？而這種情況在軟件設(shè)計(jì)或部署上卻是有存在，換句話就是在硬件和軟件資源上找平衡點(diǎn)，把部分軟件該完成的功能轉(zhuǎn)嫁到硬件服務(wù)器去完成，如果在同等效用情況下，當(dāng)然期望盡量在軟件上予以解決。當(dāng)需求階段完成業(yè)務(wù)架構(gòu)后，在進(jìn)行技術(shù)架構(gòu)上應(yīng)該參與以避免資源上被外包商所引導(dǎo)，要求項(xiàng)目管理人員具備技術(shù)架構(gòu)的能力，還有更深的要求則在于具體實(shí)現(xiàn)上采用具體技術(shù)的考慮。技術(shù)架構(gòu)包括設(shè)計(jì)和實(shí)現(xiàn)兩方面，實(shí)現(xiàn)上如在具體語言上采用什么樣的方法提高效率，比如在Win32下用C/C++開發(fā)，那么什么情況下應(yīng)該用Win32的API函數(shù)什么情況下用C/C++類庫的函數(shù)是有講究的，在效率上有很大區(qū)別，比如從數(shù)據(jù)庫提取數(shù)據(jù)進(jìn)行排序，不同的算法設(shè)計(jì)速度是有很大區(qū)別，這要求項(xiàng)目管理人員在工程關(guān)鍵點(diǎn)上給予關(guān)注，而本文這里重點(diǎn)要強(qiáng)調(diào)設(shè)計(jì)上技術(shù)架構(gòu)的能力。

技術(shù)架構(gòu)的能力在解決上面問題可以通過下面例子來體現(xiàn)。如多租戶的需求，需求很明顯就是每個用戶進(jìn)去后直接隸屬于某個租戶，但在實(shí)際軟件設(shè)計(jì)和部署上可以有兩方面實(shí)現(xiàn)。一個是軟件上直接對用戶的隸屬關(guān)系進(jìn)行區(qū)分，包括數(shù)據(jù)庫設(shè)計(jì)上也滿足，這對軟件的整體架構(gòu)設(shè)計(jì)有統(tǒng)一權(quán)衡的要求；另一方面就是一個租戶就部署一套軟件，數(shù)據(jù)庫也是區(qū)分開的。現(xiàn)在假設(shè)有兩個租戶，每個租戶Web最大并發(fā)數(shù)為50，一臺服務(wù)器一臺數(shù)據(jù)庫服務(wù)器，部署的web服務(wù)器可滿足100的并發(fā)數(shù)。如果在軟件層面實(shí)現(xiàn)多租戶，那么只要一個數(shù)據(jù)庫服務(wù)器建立一個實(shí)例，一臺服務(wù)器上部署一個web服務(wù)器就可以滿足，web服務(wù)器能支持100的并發(fā)數(shù)就可以，數(shù)據(jù)庫這個實(shí)例同樣滿足兩個租戶數(shù)據(jù)未來擴(kuò)展的需求；但如果在部署上實(shí)現(xiàn)多租戶，也就是一套軟件對一個租戶，那么就需要數(shù)據(jù)庫服務(wù)器建立兩個實(shí)例，一臺服務(wù)器上部署兩個web服務(wù)器，那么數(shù)據(jù)庫就要承擔(dān)兩個實(shí)例的表空間需求，同樣服務(wù)器要跑兩個web服務(wù)器，而每個web服務(wù)器利用率只有50%，一方面消耗服務(wù)器硬件資源，一方面卻又閑置并發(fā)數(shù)資源。顯然如果采用在物理部署上實(shí)現(xiàn)多租戶，對硬件資源有更多需求，而且資源利用率不是很高，當(dāng)然也有其優(yōu)點(diǎn)，比如更優(yōu)的獨(dú)立方案。那么從資源引導(dǎo)和平衡這個角度上，如何抉擇呢？就需要項(xiàng)目管理者從技術(shù)架構(gòu)和業(yè)務(wù)需求兩方面著手來確定。物理部署上實(shí)現(xiàn)多租戶對軟件功能肯定是減少了，但要提供更多資源，是讓軟件來完成還是讓硬件來完成，一定要專業(yè)性權(quán)衡。

技術(shù)架構(gòu)上的參與目的是引導(dǎo)外包商充分利用和節(jié)省資源，并根據(jù)業(yè)務(wù)需求和項(xiàng)目進(jìn)度平衡資源（如在軟件和硬件功能承接上進(jìn)行分?jǐn)?#xff09;。泛架構(gòu)具體在業(yè)務(wù)架構(gòu)（業(yè)務(wù)應(yīng)用解決方案）和技術(shù)架構(gòu)（技術(shù)實(shí)現(xiàn)解決方案）分別可對應(yīng)于系統(tǒng)分析師和系統(tǒng)架構(gòu)師兩種角色，外包IT工程的項(xiàng)目管理團(tuán)隊(duì)?wèi)?yīng)當(dāng)有相應(yīng)的角色。架構(gòu)所產(chǎn)生的風(fēng)險對于IT工程來說不單是推遲時間的問題，而是軟件整體的重新規(guī)劃，其后果難以預(yù)知，這也是如今軟件業(yè)不斷創(chuàng)新出靈活性、通用性的架構(gòu)，而設(shè)計(jì)模式從一定程序上也都源于架構(gòu)變更的困擾。

架構(gòu)上把握對于解決外包IT工程的項(xiàng)目管理問題僅是一個方向，更多還有工程化、細(xì)節(jié)等，工具與方法的配合等，切不應(yīng)在人的管理上下工夫，重視什么領(lǐng)導(dǎo)能力，這是錯誤的方向。不能在錯誤的方向上尋找項(xiàng)目管理問題的解決方法，更不要把項(xiàng)目中出現(xiàn)的問題歸結(jié)為自己領(lǐng)導(dǎo)能力和溝通不到，那是管本位推卸責(zé)任的手段，根本問題在于技術(shù)性管理手段和方法缺失，換言之，專業(yè)能力有問題。一個成熟的技術(shù)性管理和專業(yè)平臺是項(xiàng)目成功的必要，管理是要專業(yè)實(shí)力做基礎(chǔ)，技術(shù)性手段做輔助的。

????????????????????? 如非 2008-12-19

總結(jié)

以上是生活随笔為你收集整理的泛架构之于外包IT工程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。