如何判斷您的企業(yè)是否需要SOA管理SOA管理是我經(jīng)常談論的一個話題，得到的反饋也是好壞參半，這是因為對愿意以及方式缺乏了解。不管你的組織開始SOA多長時間，SOA管理都是需要多加注意的。我將首先解釋一下SOA管理需要注意的原因，而后再談一下需要注意的方面。但在我開始之前，我首先要澄清SOA管理與SOA治理的區(qū)別。對于我來說，SOA管理是SOA治理的一部分。SOA治理是由流程、標準以及政策來治理SOA實施的。一個完整的SOA治理解決方案設計注冊表、存儲、管理變革、服務控制、服務質量、安全等等。在此我將只談SOA管理，對于多數(shù)廠商來說是服務控制、安全、業(yè)務流程可見度以及異常事件處理。首先，讓我們看看傳統(tǒng)的智慧。組織通常認為他們不需要SOA管理的原因在于沒有足夠的業(yè)務動力?；蛘哒f：“在我們的SOA架構還沒建立起來的時候就需要SOA管理呢？”這種想法正確嗎？你可以在讀完這篇文章之后做出自己的決定。我早前曾經(jīng)提到過SOA實施像一場旅行，你的組織要達到一定的SOA成熟度是需要時間的。在SOA實施的某一個時間點，SOA管理就會牽涉進來，原因有兩點：1. 你的SOA架構將單個的應用程序和筒倉型業(yè)務功能變成了分布式服務。隨著靈活性和靈敏度的增加，安全和訪問控制的復雜性也隨之提高。這就需要管理工具上的新想法。2. 即使是在基礎的SOA環(huán)境中，你的組織也將需要SOA架構的可見度?？梢姸鹊囊蟀I(yè)務流程、服務使用、性能瓶頸等等。隨著你的環(huán)境變得越來越分散，使用原有的管理工具就會逐漸喪失可見度。因此，當SOA促進你的業(yè)務時，你需要SOA促進你的管理環(huán)境去超越傳統(tǒng)系統(tǒng)管理。這是SOA發(fā)展的適當時機嗎？那么，什么時候才是考慮SOA管理的適當時機呢？這個時間應該早于還是晚于你的SOA部署期呢？決定因素有以下幾點：1 訪問權控制和安全是SOA管理提出的關鍵問題。因此，SOA管理應該是你的SOA基礎架構整體中不可分割的一部分，而不是隨后加入。從實際出發(fā)，你需要在SOA項目早期考慮安全和控制。2 有了妥善的規(guī)劃，SOA管理將降低SOA項目的成本實施時間。人們普遍認識到項目周期早期發(fā)生的改變/修復相較于晚期來說影響更小。換句話說，你越晚決定對SOA管理提出的問題進行解決，對你之前所做決策的影響就會越大，而代價往往是巨大的。3 組織往往只有在出現(xiàn)問題的時候才會想到管理。我們很難去量化由于基礎架構中累贅服務或安全破壞所造成的干擾帶來的成本。你要做的不是去尋找救火措施，而是利用SOA管理工具主動的控制和監(jiān)控業(yè)務。4 業(yè)務流程管理（BPM）是亞洲企業(yè)中的一大主題。SOA實施則是另外一個主題。SOA管理工具是BPM很好的補足解決方案。在使用BPM的時候，多數(shù)企業(yè)都想如何利用BPM工具建立并管控其業(yè)務流程。但是，我需要提出以下幾個問題以供考慮：1 是不是所有的業(yè)務流程都能用BPM解決方案來定義？2 如果不是，那么你要如何處理那些沒有被BPM工具定義的業(yè)務流程？3 這些業(yè)務流程是遵循最初設計構想來運作的嗎？換句話說，你要如何發(fā)現(xiàn)你的業(yè)務流程正導致一些始料未及的后果？我認為大多數(shù)企業(yè)都無法通過BPM解決方案為所有的業(yè)務流程建模。如果你的業(yè)務存在已久，那么就可能會比你想象中還要多的未定義業(yè)務流程。一些SOA管理工具，帶有自動發(fā)現(xiàn)功能，能彌補這一空白。這些工具能夠“看到”并告知你基礎架構中正在發(fā)生的問題。所以不要以你認為有效的方式模擬業(yè)務流程，而讓你的 SOA管理工具來告訴你真正發(fā)生的問題。這不僅僅有利于IT針對應用和瓶頸下功夫，還有利于分析師看到實時的業(yè)務流程。目前，我們已經(jīng)討論了進行SOA管理的原因，如果你認為你真正需要SOA管理，以下幾點是在挑選解決方案時需要注意的：注意事項：1 性能：所有的管理和監(jiān)控工具會帶來一些開銷，你需要確定你的系統(tǒng)性能不會受到太大的影響。2 標準支持：你的業(yè)務是在異構的應用程序、服務和標準中運行的，你的管理解決方案也需要如此。如果你需要改變基礎架構投資以服務SOA管理，那么你有可能在尋找錯誤的解決方案。3 跨功能支持。你的SOA基礎架構可以跨越多個功能或應用解決問題，同樣，你的SOA管理方案也是如此。千萬確保你所制定出的解決方案能夠真正的滿足IT部門的需要，同時也能滿足業(yè)務分析人員，甚至可能會是保安人員的需要。就如同整個企業(yè)架構體系中的其他資產(chǎn)一樣，如果你能確切的知道SOA管理解決方案存在的意義以及如何使用將會讓你獲得更加明顯的競爭優(yōu)勢。那么，你是否真的需要SOA管理？這個決定是由你選擇的。中小企業(yè)信息化：資金與需求該如何權衡小企業(yè)信息化考驗IT人的能力什么是小企業(yè)?在我看來，小企業(yè)是特指那些已經(jīng)度過了生存期、銷售額在1億到10億元范圍內、在特定細分行業(yè)或者區(qū)域內有獨到之處的核心能力，看起來能夠迅速發(fā)展的企業(yè)。小企業(yè)的信息化矛盾體在經(jīng)濟發(fā)達的地區(qū)，這樣的小企業(yè)很多，造就了眾多的億萬富翁。同時，這樣的企業(yè)在發(fā)展上則是上上下下、起起伏伏，絕大多數(shù)無法持續(xù)發(fā)展成為更大的規(guī)?；F(xiàn)代企業(yè)。企業(yè)成功的獨特優(yōu)勢受到挑戰(zhàn)，與通用成熟的現(xiàn)代企業(yè)管理方法有嚴重的甚至根本的沖突，規(guī)模和區(qū)域擴展后外部環(huán)境的壓力和復雜度超出想像和承受能力。在這種情況下，信息化到底能夠為小企業(yè)提供什么價值?這個問題是一直困擾著信息經(jīng)理或者信息總監(jiān)或者CIO的一個事情。我們知道，信息化是以系統(tǒng)化的體系和工具規(guī)范企業(yè)的運營方法和流程，讓企業(yè)在一定的戰(zhàn)略方向上持續(xù)穩(wěn)定經(jīng)營。從管理不成熟的角度看，小企業(yè)確實不是做信息化的最好時期;但是，從企業(yè)發(fā)展的角度看，信息化又是小企業(yè)做強做大必不可少的工具。這樣的矛盾狀態(tài)，使得小企業(yè)的信息化成為考驗IT人殘酷的熔爐。小企業(yè)信息化“四核心”“尊重環(huán)境，量力而行，保障基礎，突出優(yōu)勢”似乎是小企業(yè)信息化的核心要義。“尊重環(huán)境”是要根據(jù)企業(yè)文化、企業(yè)的管理風格、管理體系這個大環(huán)境，選擇信息系統(tǒng)中能夠有效體現(xiàn)這些特征的流程進行實施，在總體保證整體連續(xù)的業(yè)務流程的情況下，突出具有共識的重點環(huán)節(jié)，舍棄有爭議的環(huán)節(jié)，在流程的基本面上保持“信息系統(tǒng)風格就是企業(yè)文化的反映”。“量力而行”的重點不是投資上的量力而行。通常情況下企業(yè)如果效益良好，投資不是問題。這個“力”是指企業(yè)的“管理能力”或者是“管理成熟度”，以及企業(yè)的學習速度或者對系統(tǒng)化、規(guī)范化操作的學習能力。一般情況下，企業(yè)通常高估自己的學習能力，低估過去的習慣勢力，或者對信息系統(tǒng)給予太高的期望。在實施信息系統(tǒng)的時候要么過低地估計使用系統(tǒng)對業(yè)務的改變，要么過高地估計自己的適應或者學習能力，或者相反。這樣會形成眾多的沖突，截然相反的評估或者意見經(jīng)常同時出現(xiàn)。所以，對“能力”要做好充分的評估?！氨Ｕ匣A”則是要保持信息系統(tǒng)的流程完整性，特別是供應鏈、資金鏈的流程，重點要放在使整個鏈條通暢，不必有太多花哨的功能。開始是基本的核心流程，再在使用的過程中逐步優(yōu)化、細化每步操作。這樣可以達到“麻雀雖小五臟俱全”，符合小企業(yè)使用大系統(tǒng)的基本規(guī)律，對未來的發(fā)展具備良好的擴充和支持能力，也為未來規(guī)范的組織發(fā)展奠定系統(tǒng)基礎?！巴怀鰞?yōu)勢”是小企業(yè)信息化的特征價值。由于小企業(yè)一般會具備某些特殊或者特有的管理方法、業(yè)務流程讓企業(yè)引以為豪，那就要特別關注這些特征，在信息系統(tǒng)中重點突出這些優(yōu)勢，固化在系統(tǒng)中繼承下去。這樣的信息系統(tǒng)也才能夠充分體現(xiàn)企業(yè)的文化和管理特征，得到廣泛的認可。總體來講，由于小企業(yè)的管理尚未成熟，運營體系尚未職業(yè)化、標準化和系統(tǒng)化，企業(yè)發(fā)展速度和組織變動速度快，進行小企業(yè)信息化的時候要充分考慮這些因素。無論是選擇重型的ERP系統(tǒng)還是輕量級的專用系統(tǒng)，都需要在企業(yè)特征優(yōu)勢方面具有傳承的作用，在規(guī)?；鸵?guī)范化方面具有充分的空間，在流程上要注重核心流程的重點環(huán)節(jié)和保留未來優(yōu)化的彈性空間，這樣實現(xiàn)的信息系統(tǒng)就會十分切合小企業(yè)多方面的需求，也能夠體現(xiàn)信息化在推動企業(yè)發(fā)展上的價值。制作網(wǎng)頁需要學習哪些技術HTML 4.01HTML是Web的語言，每一個Web開發(fā)者都需要對它擁有基本的了解。HTML 4.01是重要的Web標準，它與HTML 3.2的差異非常之大。當類似font的標簽和color屬性被添加到HTML 3.2后，它就逐漸成為開發(fā)人員們的一場噩夢。開發(fā)那些必須把字體信息加入每個單獨頁面的網(wǎng)站，其過程成為了一種漫長而昂貴的折磨。通過HTML 4.01，所有的格式化信息可以被移出HTML文檔，轉而放入一個獨立的樣式表中。HTML 4.01之所以重要，另外一個原因是由于XHTML 1.0，這個最新的HTML標準是作為一種XML應用被重新表達的HTML 4.01。在您的頁面中使用HTML 4.01可以確保在未來將HTML輕松升級到XHTML。請確保您使用了最新的HTML 4.01標準。層疊樣式表(Cascading Style Sheets - CSS)樣式可定義HTML元素如何被顯示，類似font標簽在HTML 3.2中所起到的作用。樣式通常被保存在HTML文檔之外的文件中。外部樣式表使您有能力僅僅通過編輯一個簡單的CSS文檔來改變網(wǎng)站內所有頁面的外觀和布局。如果您曾經(jīng)嘗試過進行某些改變，比如同時改變站內所有網(wǎng)頁標題的字體或顏色，您就會明白CSS如何能夠達到事半功倍的效果。XHTML - HTML的未來XHTML指可擴展超文本標記語言(Extensible HyperText Markup Language)。XHTML 1.0是源自W3C的最新的HTML標準。它于2000年1月26日成為正式的推薦標準(Recommendation)。W3C Recommendation意味著其規(guī)范的穩(wěn)定性，同時其規(guī)范目前已成為一種Web標準。XHTML是一種使用XML進行重構的HTML 4.01，并可以通過遵循一些簡單的指導方針立即在現(xiàn)有的瀏覽器中投入使用。XML - 用于描述數(shù)據(jù)的工具擴展標記語言(XML)并不是HTML的替代品。在未來的web開發(fā)中，XML會被用來描述和存儲數(shù)據(jù)，而HTML會被用來顯示數(shù)據(jù)。我們對XML最合適的描述是，一個跨平臺的、獨立與軟硬件的，信息存儲和傳輸工具。我們相信XML的重要性不亞于HTML對于web的基礎性地位，并且XML將會成為最重要的數(shù)據(jù)處理和傳輸工具。XSLT - 用戶轉換數(shù)據(jù)的工具XSLT(可擴展的樣式表語言轉換，Extensible Stylesheet Language Transformations)，是用于轉換XML的語言。未來的網(wǎng)站將不得不向不同的瀏覽器并向其他web服務器以不同的格式傳遞數(shù)據(jù)。而XSLT則是一種將XML數(shù)據(jù)轉換為不同格式的新的W3C標準。XSLT可以把XML文件轉換為瀏覽器可識別的格式，比如HTML，或者WML - 一種用于許多手持設備的標記語言。XSLT還可以添加元素，并對元素進行刪除、重新排列及排序，測試并確定顯示哪些元素，等等?？蛻舳四_本客戶端腳本腳本是一種有關因特網(wǎng)瀏覽器行為的編程。您應該學習JavaScript，這樣才能有能力傳遞更多的動態(tài)網(wǎng)站內容：JavaScript是為HTML設計者提供的一種的編程工具HTML的創(chuàng)作者通常都不是程序員，但是JavaScript是一種語法非常簡單的腳本語言!幾乎任何人都能夠把某些JavaScript的代碼片斷放入他們的HTML頁面中。JavaScript可以在HTML頁面中放入動態(tài)的文本像這樣的一條JavaScript語言可以在HTML頁面中寫入可變的文本：document.write(h1 + name + /h1)JavaScript能夠對事件進行反應可以把JavaScript設置為在某事件執(zhí)行時發(fā)生，比如當頁面加載完畢或當用戶點擊某個HTML元素時。JavaScript可讀取并修改HTML元素JavaScript能夠讀取并修改HTML元素的內容JavaScript可被用來驗證數(shù)據(jù)可使用JavaScript在表單被提交到服務器前對表單數(shù)據(jù)進行驗證，這樣可確保服務器進行正確的數(shù)據(jù)處理。服務器端腳本服務器端腳本和因特網(wǎng)服務器編程有關。您應該學習服務器端腳本，這樣才能有能力傳遞更多的動態(tài)網(wǎng)站內容。通過服務器端的編程，你可以：動態(tài)地編輯、修改或添加網(wǎng)頁內容對用戶從HTML提交的查詢或數(shù)據(jù)進行響應訪問數(shù)據(jù)或數(shù)據(jù)庫，并把結果返回瀏覽器訪問文件或XML數(shù)據(jù)，并把結果返回瀏覽器把XML轉換為HTML，并把結果返回到瀏覽器為不同的用戶定制頁面，提高頁面的可用性對不同的網(wǎng)頁提供安全和訪問控制為不同類型的瀏覽器設計不同的輸出最小化網(wǎng)絡流量使用SQL管理數(shù)據(jù)結構化查詢語言(SQL)是對諸如下列數(shù)據(jù)庫進行訪問的通用標準：SQL Server、Oracle、Sybase以及Access。對于那些希望從數(shù)據(jù)庫存儲和提取數(shù)據(jù)的人們來說，有關SQL的知識是極具價值的。任何web管理員都應當明白，SQL對于web上的數(shù)據(jù)庫來說，是一種真正切合的引擎。站在別人的肩上:項目管理的規(guī)則美國著名軟件工程專家勃姆（B.W.Boehm）在總結軟件工程準則和信條的基礎上，于1983年提出軟件工程的7條基本原則，也是軟件項目管理應該遵循原則。勃姆認為，這7條原則是確保軟件產(chǎn)品質量和開發(fā)效率的原理的最小集合，相互獨立但結合得相當完備。1.用分階段的生命周期計劃嚴格管理。統(tǒng)計表明，不成功的軟件項目中約有一半左右源自計劃不周。本原則意味著，應該把軟件生命周期劃分成若干階段，相應地制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發(fā)與維護工作進行管理。勃姆認為，在軟件的整個生命周期中應該制定并嚴格執(zhí)行6類計劃，即項目概要計劃、里程碑計劃、項目控制計劃、產(chǎn)品控制計劃、驗證計劃、運行維護計劃。不同層次的管理人員必須嚴格按照計劃各盡其職地管理軟件開發(fā)與維護工作，絕不能受顧客或上級人員的影響而擅自背離預定計劃。2.堅持進行階段評審。軟件的質量保證工作不能等到編碼階段結束之后再加以實施，其理由為：第一，大部分錯誤始于編碼之前；第二，錯誤的發(fā)現(xiàn)與修改時間越晚，需要付出的代價就越高。因此，本原則意味著，在軟件開發(fā)的每個階段應該進行嚴格的評審，以便盡早發(fā)現(xiàn)軟件開發(fā)過程中的錯誤。3.實行嚴格的產(chǎn)品控制。軟件開發(fā)過程中不應隨意改變需求，因為改變一項需求往往需要付出較高的代價；但是軟件開發(fā)過程中改變需求又在所難免，基于外部環(huán)境的變化而出現(xiàn)改變用戶需求的情況是一種客觀需要，而且迅速應對客戶的需求變更是顧客本位的內涵之一。在這種情況下，只能依靠科學的產(chǎn)品控制技術來順應這種要求。當改變需求時，為了保持軟件各個配置成分的一致性，必須實行嚴格的產(chǎn)品控制，其中主要是實行基準配置管理。所謂基準配置又稱基線配置，它們是經(jīng)過階段評審后的軟件配置成分（各個階段產(chǎn)生的文檔或程序代碼）?；鶞逝渲霉芾硪卜Q為變更控制：一切有關修改軟件的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規(guī)程進行評審，獲得批準以后才能實施修改。避免開發(fā)人員對軟件隨意進行修改。4.采用現(xiàn)代程序設計技術。從提出軟件工程的概念開始，人們一直把主要精力用于研究各種新的程序設計技術。從60年代末提出的結構程序設計技術到最近的面向對象技術，人們不斷創(chuàng)造先進的程序設計技術。實踐表明，采用先進的技術既可提高軟件開發(fā)的效率，又可提高軟件維護的效率。5.結果應能清楚地審查。與其他有形產(chǎn)品不同，軟件是看不見摸不著的邏輯產(chǎn)品。軟件開發(fā)人員的工作進展情況可見性差，難以準確度量，從而使得軟件產(chǎn)品的開發(fā)過程比一般產(chǎn)品的開發(fā)過程更難以評價和管理。為了提高軟件開發(fā)過程的可見性，更好地進行管理，應該根據(jù)軟件開發(fā)項目的總目標及完成期限，規(guī)定開發(fā)組織的責任和產(chǎn)品標準，從而使得所得到的結果能夠清楚地審查。6.開發(fā)小組的人員應該少而精。該原則意味著，軟件開發(fā)項目的組成人員的素質應該好，而人數(shù)則不宜過多。開發(fā)小組人員的素質和數(shù)量是影響軟件產(chǎn)品質量和開發(fā)效率的重要因素。素質高的人員的開發(fā)效率比素質低的人員的開發(fā)效率可能高幾倍至幾十倍，而且素質高的人員所開發(fā)的軟件中的錯誤明顯少于素質低的人員所開發(fā)的軟件。此外，隨著開發(fā)小組人員數(shù)目的增加，因為交流問題而造成的溝通成本也急劇增加。因此，構建和維持少而精的開發(fā)團隊甚至標桿團隊是軟件工程的一條基本原理。7.承認不斷改進軟件工程實踐的必要性。遵循上述6條基本原則，就能夠按照當代軟件工程基本原理實現(xiàn)軟件的工程化生產(chǎn)，但是，僅遵循上述6條原則并不能保證軟件開發(fā)與維護的過程能趕上時代前進的步伐，能跟上技術的不斷進步。因此，勃姆提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第七條基本原則。按照這條原理，不僅要積極主動地采納新的軟件技術，而且要注意不斷總結經(jīng)驗。威格的成功軟件項目管理秘訣過程影響（Process Impact）公司的首席咨詢顧問卡爾。威格（Karl E.Wiegers）在其成功項目管理秘訣（Secrets of Successful ProjectManagement）一文中總結了成功項目管理的20條秘訣：構筑基礎1.定義項目成功標準；2.識別項目的驅動、約束和自由度；3.定義產(chǎn)品發(fā)布標準；4.協(xié)商承諾。規(guī)劃工作5.制作計劃書；6.將任務分解成較小的里程碑；7.為共通的大任務開發(fā)計劃工作表；8.計劃在質量控制活動后實施修改；9.為過程改進安排時間；10.管理項目的風險。估算項目11.根據(jù)工作量而不是日歷估算；12.不要為項目人員安排超過其80的時間；13.將培訓時間納入計劃中；14.記錄估算以及如何達致估算；15.利用估算工具；16.尊重學習曲線；17.考慮意外事件的緩沖。追蹤進展18.記錄實績與估算；19.只有當任務百分之百完成時，才認為該任務結束；20.公開而誠實地跟蹤項目狀態(tài)。麥克康奈爾的成功軟件項目十大要決史蒂夫。麥克康奈爾（SteveMcConnell）在成功軟件項目的十大要決（10 Keys to Successful SoftwareProjects）中闡述了成功軟件項目的十大要決：1.清晰的愿景；2.穩(wěn)定的、完整的、書面的需求；3.詳細的用戶界面原型；4.有效的項目管理；5.精確的估算；6.兩階段預算；7.注重質量；8.聽取技術專家的意見；9.積極的風險管理；10.記住：軟件來源于人。在組織間跨項目組加強推廣學習優(yōu)秀經(jīng)驗以往對項目總結的認識不夠，很多時候也就是寫寫PPT或者開個會，很多經(jīng)驗沒有能被辨識出來成為案例，也就不能給大家分享。特別是很多教訓，人性的問題，沒有被說出來，畢竟說出自己的不是不是每個人都能做到。導致教訓庫不能不斷豐富，因此前人吃虧，后人無法繼承到有效的經(jīng)驗。前段時間進行2008年度總結的時候，業(yè)主提出接觸我們這么多項目，我們每個項目經(jīng)理的風格都不一樣，項目的成功與否太依賴于項目經(jīng)理個人的能力。我想我們不是要讓每個人都沒有自己的風格，項目經(jīng)理當然有能力水平的高低，當然有不同的價值體現(xiàn)。業(yè)主其實就是在說我們的項目實踐必須積累。在之前的博文業(yè)主的改進意識讓我驚訝，我們應該更加積極地看待和推進CMMi的改進！中講到，一個業(yè)主的項目經(jīng)理對口我們幾個項目經(jīng)理，A項目經(jīng)理做得好的，業(yè)主方項目經(jīng)理肯定會將A做得好的地方來要求公司的另一個項目經(jīng)理B。如果我們自己不傳授這種經(jīng)驗，那才是傻子。使用即將推行的CMMi的規(guī)程，重新Review一下2008年的各個項目，從中去分析各個項目組的強處以及弱項，從規(guī)程中掃漏洞，審視項目組的那些活動執(zhí)行的力度和弱項之間的關系，對于來年指導項目建設是非常有幫助的。今天在內審會議總結上，同事WN說得好，我們現(xiàn)在的項目經(jīng)理花了很多時間在做事，其實缺少了時間思考如何去做事！管理不僅是規(guī)范、監(jiān)督，還有教練一職。故事一則：在組織間跨項目組加強推廣學習優(yōu)秀經(jīng)驗，除了會議交流、專題培訓，還可以去現(xiàn)場實地體驗加強感性認識（呵呵，共產(chǎn)黨宣傳的那一套都要學習用上）。上次說到項目O和項目C整合上線，整個上線持續(xù)了近三天時間，有很多地方值得總結。今天剛好有項目T正在組織部署上線，項目T的技術經(jīng)理CC做為培訓講師以往培訓過兩次有關部署的工作，項目C的經(jīng)理C當時也聽過CC的課程，在沒有和CC打招呼的前提，帶上項目O和項目C的兩位同事L和C到現(xiàn)場去抽查觀摩，能夠更加有感觸其他同事的優(yōu)秀實踐。到了現(xiàn)場，才知道項目T晚上6點才開始部署，因此安排兩個項目的項目經(jīng)理/技術經(jīng)理進行現(xiàn)場的交流。在簡單介紹了此行的目的后，CC首先發(fā)言，詢問C上次部署的過程中計劃和實際工作最大的出入在那些地方？通過近一個小時的訪談，同事C和L認識他們有不少改進的問題，這里講最重點一點：項目組C和項目組O在系統(tǒng)的正式部署前，缺少完整的演練。雖然有部分的演練，但是沒有通過演練將可能的問題辨識出來。也因為如此，吃虧最多的遷移方案中的校驗問題，沒有能夠提前暴露。涉及到新舊兩個系統(tǒng)的遷移，數(shù)據(jù)需要從系統(tǒng)O遷移到系統(tǒng)C，采用的方案是C直接訪問O的數(shù)據(jù)方式，表面看這種方式最簡單最直接，但是編寫遷移和校驗程序的同事都必須必須清晰了解C系統(tǒng)和系統(tǒng)O的業(yè)務邏輯，而實際由于邏輯覆蓋不全面，導致校驗的工作不完整，只使用抽樣的方式即花了大量的人力（校驗一個抽樣數(shù)據(jù)，需要花20分鐘人力），也導致有大量的遷移漏洞需要補救。同事CC告訴C，應該采用接口交互表的方式，約定好規(guī)格，系統(tǒng)O的同事熟悉O的業(yè)務邏輯，負責將數(shù)據(jù)遷移到接口表，再由他們進行業(yè)務邏輯的檢查，因為他們熟悉舊系統(tǒng)的邏輯啊！檢查完畢后，才由C負責從接口交互表中提取數(shù)據(jù)，C了解新系統(tǒng)的新業(yè)務邏輯，對接口交互表進行邏輯檢查后，提取數(shù)據(jù)轉換到新的系統(tǒng)。采用兩階段的遷移，由熟悉舊系統(tǒng)的同事做應該做的事，讓新系統(tǒng)的同事做他該做的事、熟練的事，看似復雜反而簡單！我在旁邊插了話，其實如果舊系統(tǒng)是其他公司承建的，可能同事們就能想到兩階段遷移的接口交互表方式，可是我們兩個系統(tǒng)由于是同一個部門承建，我們把部門邊界和系統(tǒng)邊界給混淆了，反而欲速而不達。在網(wǎng)頁中用JS函數(shù)控制Flash動畫播放 一、介紹與Flash動畫控制有關的javascript函數(shù)：函數(shù)名使用作用play()wgzc.play()播放Flash動畫stopplay()wgzc.stopplay()停止播放Flash動畫rewind()wgzc.rewind()停止播放Flash動畫并返回第一幀totalframes()wgzc.totalframes()返回Flash動畫總幀數(shù)gotoframe(int num)wgzc.gotoframe(int num)轉到指定幀 二、程序代碼： function init() document.changeframe.totalfrm.value=document.wgzc.totalframes 控制Flash動畫 Flash動畫幀數(shù): 輸入第幀,再點擊指定幀。 播放 停止 停止返回第一幀 指定幀 以WBS為主線的集成項目管理任何流程或業(yè)務在我們學習的過程中始終都有一個主線，比如說知識管理的基礎或主線是知識庫和知識地圖，ERP的數(shù)據(jù)基礎是ITEM和BOM，主線是需求訂單-MRP-生產(chǎn)計劃和采購計劃。對于產(chǎn)品數(shù)據(jù)管理PDM的主線是產(chǎn)品結構，對于CRM客戶關系管理的主線是營銷-市場策劃-銷售計劃-預測-項目-合同。而對于項目管理其基礎是WBS工作結構分解，其主線是項目結構-項目-WBS-工作包-活動-任務。這條主線涉及到PMBOK里面的范圍管理和進度管理兩方面的內容。對于范圍管理最終的輸出就是范圍說明書和WBS，而對于進度管理則輸入是WBS，需要進行活動定義分解和排序，最終得到的進度表。在項目的執(zhí)行過程中我們是按照具體的活動任務在執(zhí)行，在執(zhí)行的過程中會產(chǎn)生使用資源，消耗成本，產(chǎn)生文檔和各種輸出，進行設計開發(fā)，集成，評審和質量控制。我們活動分解的單位是到了具體的任務，但是我們產(chǎn)品的最終集成，我們的成本核算和掙值管理是不能到活動任務的。因此WBS在整個項目管理中就起到了重要作用，其作用不僅僅在前期確定項目范圍和制定項目的進度計劃，更多的是后期的掙值管理和更高層次的項目監(jiān)控。如果沒有完善的WBS分解，我們就很難做到這一步，我們的整個項目管理執(zhí)行過程中的產(chǎn)出就是凌亂的，沒有一個主線串起來。感興趣的可以再去翻看下PMBOK各個過程域中各個過程組的IPPO，可以發(fā)現(xiàn)很多過程的輸入都有WBS，足以見WBS在整個項目管理中的基礎和核心作用。在這個圖中還強調了下在CMMI三級中我們強調的生命周期模型定義過程裁剪，在組織級我們可以根據(jù)項目的不同特點將項目進行分類制定不同的項目生命周期模板，這樣在有實際的項目來的時候，只需要根據(jù)項目的特點對模板內容進行自定義和裁剪，輸入具體的需求項，即可以自動產(chǎn)生相應的WBS。(該點后續(xù)單獨在發(fā)文闡述)，這樣自動生成的WBS不僅僅實現(xiàn)了后續(xù)的主線跟蹤，還實現(xiàn)了我們在CMMI二級中需要的需求追蹤。一流軟件領導的10個特征特征一：敢于設想他們是在不確定性上發(fā)展起來的技術空想家。軟件領導者們必須生活于剃刀邊緣。1987年，在驅車沿法蘭克福到沃爾多夫從一家IBM代理商那兒回家時，SAP的創(chuàng)立者普拉特納、霍普和特奇拉決定為他們最暢銷SAP R2企業(yè)解決方案軟件創(chuàng)造一個新版本。新的R/3將利用一個可塑性強得多的設計。但是新產(chǎn)品應該運行于哪些系統(tǒng)之上呢？當時，許多大學剛剛開始使用Unix，這是一個新的操作系統(tǒng)，允許在不同廠家的計算機之間構建網(wǎng)絡，從而有可能創(chuàng)造一個新的系統(tǒng)結構: 客戶/服務器模型。雖然有這些優(yōu)點，它卻相當不穩(wěn)定，沒有達到企業(yè)解決方案應用所需的表現(xiàn)水平。因此，盡管它提供了許多超過大型計算機的專業(yè)優(yōu)勢，許多從業(yè)者認為它永遠不會取代那時的大型機。但普拉特納不同意。他鼓吹為新的R3系統(tǒng)采用Unix，從而指出了一種當時看上去高度投機和冒險的方向。他立刻在自己公司內陷入阻力之中。但是他相信他的遠見于是運用他作為一個大股東的影響力，得到了董事會的同意。4年之后，1991年，SAP向全世界推出了R3，安裝在一個小的HP Unix工作站。人們被震驚了。“它幾乎是可笑的，”普拉特納回憶道，“他們在說：這個小機器，帶著一些存儲器就是偉大的 SAP？”但是，這個小機器為SAP在ERP市場的主導地位奠定了基礎?；赨nix的 R3向大群的 Windows PC用戶開放了SAP，用一個“漂亮的前端吹走了“綠色顯示屏之爭”，正如理查森波士頓的高等制造業(yè)研究公司的一位顧問所描述的。此外，基于Unix的R3的表現(xiàn)要比基于大型機的R2更好。R3在全球EPR市場成了一個王牌產(chǎn)品。從1992年到1998年，單在美國，SAP的收入就從4500萬美元上升到20億美元。是普拉特納深入技術內部的洞察和他對未來發(fā)展的預見，使這一設想成為可能，也說明了軟件領導者必須生活于剃刀邊緣。軟件業(yè)已經(jīng)產(chǎn)生了許多其他的幻想家，他們在全球范圍內改變了這個行業(yè)，從庫比（他在很久以前就相信軟件可以與硬件分開銷售）和基恩（他于1965年在一家汽車輪胎鋪里創(chuàng)立了他的軟件服務公司），一直到比爾蓋茨、埃里森和其他人。特征二：敢于冒險他們承受巨大的風險并希望有高額的回報。在夢想成真的路上，軟件領導者們必須能夠面對無數(shù)次風險。麥肯錫的調查顯示，成功軟件產(chǎn)品公司的領導者做出重要戰(zhàn)略決定所花的時間平均要少25，其原因并不主要是他們有更好的信息或市場研究，更多的來自他們的冒險精神。以萊曼特為例，他從學校退學，并在1989年建立了以得克薩斯州奧斯汀為所在地的Trilogy軟件公司，一家專門從事前臺辦公室銷售和營銷軟件的公司。對萊曼特來說，決定冒險是很自然的。他告訴我們: “我想我不得不退學以抓住市場機遇?！睕]有一個風險資本家想資助他，所以萊曼特靠賒欠度日。不過創(chuàng)立Trilogy兩年后，萊曼特從他冒險的愿望中得到了回報。他終于做成了與惠普的一筆350萬美元的合同。其他有名的客戶，像波音和朗訊也接踵而來。到1996年，萊曼特進入了福布斯400名富豪榜并成了其中最年輕的自力更生者，擁有估計5億美元的凈資產(chǎn)。在1998年，他有850名員工，銷售額超過1億美元。萊曼特及其公司并非孤立的個案。安德烈森在他合作創(chuàng)立網(wǎng)景并開發(fā)因特網(wǎng)瀏覽器軟件時只有22歲。比爾蓋茨、巴爾默或SAP的普拉特納同樣都是冒險家，而且他們全都通過冒險而成了億萬富翁。特征三：多樣選擇他們在多個選擇上押注，來為所有不確定性做準備。微軟并不單單押注于它的 Windows PC操作系統(tǒng)的成功，而是與IBM一起共同開發(fā)一個與之競爭的操作系統(tǒng)OS2。SAP是另一個例子。它沒有去“塑造”這個行業(yè)，而是寧愿適應領先者的標準，同時在幾個標準上花錢。作為SAP的總裁和CEO，卡格曼評述說， SAP可以從第二排看到表演不斷發(fā)展。專業(yè)軟件公司的領導人同樣通過選擇權處理不確定性。西姆斯是劍橋技術伙伴公司的 CEO，該公司是波士頓一家6億美元的軟件服務公司。他確保劍橋連續(xù)投資幾個新興公司，它們可能會開發(fā)出一個新的技術標準?！拔覀兣c新技術一直保持接觸，”西姆斯說，“我們希望資助的這些公司之一有一天會成功。”但是，在通往成功的路上，軟件領導者們必須接受不時的失敗。事實上，失敗并非是例外，而是慣例即使在成功的軟件領導者之中。特征四：敢于嘗試他們寧愿“迅速失敗”而不是避免錯誤。“寧可做6個正確決定和4個錯的，而不要等得太久，”SAP的霍普評述道?！癙latinum技術公司的CTO波佩克同意這個說法。“快速移動是很重要的，”他說，“這常常會導致錯誤，但錯誤是可以改正的?！笨纯搓愗Ш暝谒麆?chuàng)立了BroadVision之后是如何反應的。盡管這名企業(yè)家在電子商務解決方案上押對了賭注，他卻在選擇交互式電視（它看起來像是“未來的潮流”）作為其產(chǎn)品的平臺上犯了錯誤。事實上，當陳丕宏第一次看見因特網(wǎng)的時候，他的電視產(chǎn)品幾乎已經(jīng)完成了。特征五：強調速度陳丕宏幾乎一夜之間就將BroadVision轉變成了一家因特網(wǎng)公司。“對我來說非常清楚，我們錯了，而且如果我們不迅速改弦易轍的話，我們就會失去一切。”陳丕宏回憶道。陳丕宏沒有做長時間的討論，而是幾乎一夜之間就將公司轉變成了一家因特網(wǎng)公司不顧他的經(jīng)理們的反對?！拔?guī)缀醪坏貌唤夤驼麄€高層管理隊伍，因為他們對變革沒有信心?！彼f。他的敏捷行動獲得了結果，到1998年底，BroadVision的市值超過了7億美元。特征六：目標遠大軟件領導者們同樣設定了非常高的期望。當菲利波夫斯基于1987年創(chuàng)立 Platinum時，他決定在10年之內將其建成一個10億美元收入的公司。菲利波夫斯基覺得他不得不動作迅速，因為他看到軟件業(yè)正在迅速轉向成熟。他同樣明白在軟件產(chǎn)品行業(yè)，只有領先者才能真正成功。“對我來說，迅速壯大是件生死攸關的事?！彼忉尩馈７评ǚ蛩够]有完全實現(xiàn)他的想法，“這花了我們11年，而不是10年。”他有些不好意思的承認。但是他的窘迫是可以忍受的，比爾蓋茨花了15年才使微軟達到10億美元，英特爾、Oracle和SAP達到這個目標全都花了10年以上。只有思科的莫格里奇和錢伯斯擊敗了菲利波夫斯基，他們在10年里做到了這點。在麥肯錫的全球性調查中，發(fā)現(xiàn)高期望水平與公司的成功之間有非常強的相關性。在成功企業(yè)之中，93都有一個清晰、明確的遠見，而在不成功企業(yè)中只有25%有這樣的雄心壯志。特征七：敢于變革他們是高度動態(tài)的組織的建立者。1995年12月7日，比爾蓋茨在微軟的會議上宣布了一個突然的變革。他回顧歷史，引用了日本海軍上將山本五十六在日本進攻美國時所做的評論：“我擔心我們驚醒了一個沉睡的巨人。”在這兒，這個巨人就是蓋茨的公司，而進攻者是網(wǎng)景和因特網(wǎng)時代。蓋茨清楚地看到進攻者們正在來臨。在其存在的20個月里，網(wǎng)景已經(jīng)將其Navigator萬維網(wǎng)瀏覽器推到了全世界的領先位置。該公司也進行了一次最為成功的公開上市。同一時間在微軟，“我們確實有些錯過了因特網(wǎng)航船，”微軟德國公司總經(jīng)理羅伊這樣承認。特征八：反應迅速他們都是看準趨勢迅速行動的人?！斑@就是要改變的?！闭驹趲装倜绦蚍治鰡T和記者面前，蓋茨宣布他將重新調整每個項目和每個產(chǎn)品以迎接因特網(wǎng)的挑戰(zhàn)。確實，整個微軟的管理人員倉促地停止了幾個數(shù)百萬美元的項目并在數(shù)小時內啟動了因特網(wǎng)項目。這些經(jīng)理之一的路德維希走進一間滿是程序員的屋子，命令道：“清除你們機器里的源代碼，今天起就開始用 Java工作?！睘橐蛱鼐W(wǎng)瀏覽器工作的程序員的數(shù)目迅速從8人增長到800人。9個月后，在1996年8月13日，微軟的IE30，新的具有競爭力的瀏覽器發(fā)布了。它在每個方面都趕上網(wǎng)景的Navigator。在第一個星期，超過100萬用戶下載了這個免費軟件。盡管兩個公司之間的戰(zhàn)斗1998年仍在進行，有一點已經(jīng)十分清楚：微軟已經(jīng)在6個月略多一點的時間內成功地改變了一個龐大的有2萬名員工的組織。要做到這點，需要從高層領導者那兒來的對巨大變革的極強的信心以及清晰、可交流的信息。讓整個組織對這種劇烈變動做好準備是一項長期的任務。英特爾的格羅夫在談到高技術公司中的管理時說：“你需要像一個救火部門那樣做計劃：它不能預計下一場火出現(xiàn)在哪兒，所以它不得不塑造一支富有活力和有效率的隊伍，能像處理普通事務一樣對突發(fā)事件做出反應。”特征九：善于管理他們建立十分平坦的、以團隊為基礎的組織。SAP在1996年擁有2萬名員工和50億美元收入，它有一個3個層次的平坦的組織形態(tài)。在公司位于德國沃爾多夫的總部，咖啡機旁的墻上掛著總裁霍普講演中的一段話。他說：“對所有公司的新員工來說，在SAP這兒，我們是沒有官僚主義并鼓勵主動性的?！彼€說：“這要求每個人有時得為往往不在正常工作任務之中的事情負責?！痹趯I(yè)軟件服務中，構建以團隊為基礎的組織也是一個關鍵的領導任務。“在專業(yè)服務中，獲勝的是團隊，”基恩解釋說，“但正因為如此，領導者也就成了專業(yè)服務里的關鍵。在產(chǎn)品行業(yè)，產(chǎn)品在整個公司范圍內被聚合起來，而領導者們創(chuàng)造并代表它。在服務業(yè)，領導者得和諧安排和構建一支經(jīng)過授權的隊伍?！蔽④浀氖紫癄I運官赫伯德，過去曾是消費品行業(yè)巨人寶潔的營銷主管，在財經(jīng)時代的一次采訪中說，軟件業(yè)的團隊結構和平坦的等級制度是他對這個行業(yè)印象最深的?！霸趯殱?，大多數(shù)的交流是手寫的。它只能上下一個層次，與這個行業(yè)相比，它是相對遲緩的。所以你可能要花4個輪次的交流才能明白自己實際上弄亂了什么事情。在微軟，我們以直接接觸主題而自豪?！逼渌袠I(yè)的管理者們也同意這一說法?！跋馩racle和Sun這樣的軟件公司都非常重視以團隊為基礎，我們喜歡仿效它們，”Texaco的石油勘探顯示中心經(jīng)理蔡特林說，“中層管理人員有權做決定。他們可以自行其是。這種文化感染了我。”特征十：創(chuàng)造文化他們創(chuàng)造了一種文化，它吸引和留住人才。當我們在芝加哥郊區(qū)訪問Platinum公司時，我們問各個管理人員他們的公司給他們印象最深的是什么。從公司數(shù)據(jù)中心經(jīng)理韋伯、營銷執(zhí)行副總裁馬修斯和開發(fā)人員德莫特那兒，我們得到了同一個答案：菲利。他們說，CEO菲利波夫斯基那與眾不同的風格產(chǎn)生了巨大的影響。甚至菲利波夫斯基的辦公室也與眾不同，有數(shù)百個印度玩偶排列在墻上，一架大電視從天花板上吊下來，不停地播出因特網(wǎng)新聞服務。在另一個角落，供應的軟飲料有6英尺高。“初次來訪的人總是感到驚訝。菲利確實是個十分特別的人，”一名經(jīng)理助理說。在她向我們展示菲利波夫斯基的辦公室時，她的臉上閃過一絲微笑。她并非惟一一個：幾乎每一個我們與之交談的人在解釋他們?yōu)槭裁催M入這家公司和為什么喜歡在這兒工作時，都提到Platinum的這位領導者和他創(chuàng)造的文化。創(chuàng)造一種吸引人才的文化對軟件領導者們是必不可少的，而且實際上，是他們最重要的挑戰(zhàn)之一。需求管理的必要性及控制需求漸變的方法本文介紹了需求管理的必要性，并介紹了控制需求漸變的一些方法。軟件需求是整個軟件項目的最關鍵的一個輸入，和傳統(tǒng)的生產(chǎn)企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，他不像生產(chǎn)汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的，軟件需求是軟件項目最難把握的問題，他的復雜性體現(xiàn)在以下方面：需求的描述問題一個已經(jīng)進入了編碼后期階段的項目，該項目已經(jīng)換過2次項目經(jīng)理了，這是第3次更換項目經(jīng)理，用戶方的IT部經(jīng)理找抱怨：我已經(jīng)是第3次來給你們講補貨申請的處理規(guī)則了!。我只能表示抱歉，因為我無法找到原來的需求描述，這是一個變更的需求，前任的項目經(jīng)理講他只是將當時與用戶交流的需求記到2頁草稿紙上，不幸的是，那2頁珍貴的手稿現(xiàn)在已經(jīng)找不到了!更不幸的是，該IT部經(jīng)理是在轉述業(yè)務部門的需求，當軟件開發(fā)完畢后，業(yè)務部門講這不是我們最初給IT部反映的需求，我們說的不是這樣的!。缺少正式的完整的需求文檔浪費了大量的人力物力，但是有了需求文檔又出現(xiàn)了新的問題。曾經(jīng)有多個項目經(jīng)理抱怨，在用戶方進行的需求評審會完全是走形式，因為用戶根本不去聽他讀那上百頁的需求文檔。不同層次的客戶(用戶)關心的問題是不一樣的，想要每個客戶都成為需求專家是不現(xiàn)實的。需求的完備程度問題需求如何做到?jīng)]有遺漏?如何準確劃定系統(tǒng)的范圍?這確實是一個兩難問題，稍微大一點的系統(tǒng)要想窮舉需求幾乎是不可能的，每次開需求評審會時，總會冒出新的需求，以至于系統(tǒng)沒有一