網站 就是軟件

1998年，互聯網火了，新鮮出爐的網蟲在網上發郵件、上BBS，立刻成了新潮一派； 

1999年，個人主頁火了，啃幾行HTML、扒弄點圖片，搗鼓出個人站點就成“大蝦”了； 

2000年，Dotcom火了，門戶、聊天、游戲、社區花樣百出，混個斑竹網管當當，頓時風光無限； 

2001年，網絡應用火了，買賣東西、拉拉客戶、管管財務，有點技術的家伙開始牛啦； 

2002年，企業應用解決方案，.net平臺看起來又要火了… 

現在該怎么干？？？



A鏡頭：你被老板安排負責信息化建設，是不是像老虎咬刺猬一樣無從下口？ 

B鏡頭：你希望請別人設計一個網站，他們是不是會敷衍了事，蒙你一把？ 

C鏡頭：有一個誘人的項目擺在面前，到最后是不是搞得一團糟，反而倒貼老本？ 

到底該怎么辦？？？ 

從現在開始，一起出發去找我們的新奶酪吧。這個奶酪的名字叫“網站項目管理”。






    網站項目：即以Web服務器為主體、瀏覽器為客戶端作為基本架構的項目。這樣的架構項目中包含Web 服務器、瀏覽器和網絡三個關鍵主體。網站項目可能是一個網站，也可能是各種Web應用程序，例如網上商店、虛擬郵局、網絡辦公管理系統、客戶關系管理系統等等。 


    網站項目管理：是圍繞著網站項目運用知識、技術、技能、工具和方法進行組織管理。其共同特征是： 

    ● 管理由人實現，而非機器； 

    ● 項目具有時間周期，包括啟動時間和結束時間； 

    ● 項目受資源限制，包括人員、資金、場地、設備等； 

    ● 需要計劃、實施和控制； 



     文章開頭的A鏡頭、B鏡頭和C鏡頭，都可以納入網站項目管理的范疇。以下是網站項目管理的幾個重要概念： 

    （1）角色：是指項目人員在管理過程中，在特定環境下參與設計的行為代表。 

例如項目經理、數據庫工程師、界面設計師、文檔工程師等等。對于網站項目管理，最關鍵的角色是：項目經理，業務流程分析師，用戶界面工程師，系統分析員，編碼人員（程序員），質量控制工程師。根據項目的規模和開發的深度，由項目經理進行角色劃分。假如嚴格細分，一個大型項目的角色可能達到50個以上，以確保每個細節都有專業的人員進行負責和管理。 


    需要注意的是：角色不等于人。一個人可能充當多個角色，一個角色也可能由許多人組成。比如既是系統分析員，也是測試工程師，或者既是用戶界面工程師，又擔任文檔編寫和管理，一個項目管理小組可能只有三五個人，也可能三五百號人，項目組可大可小，但是項目管理流程需要細致的角色分工。 


    （2） 流程：在項目過程中執行的工作序列。 

     每個角色在流程中獲得和輸出相應的工作結果。例如在需求分析流程中，需要有客戶代表、業務員、業務流程分析師、用戶界面工程師等角色參與，業務員從客戶代表那里獲得需求，并形成需求報告；業務流程分析員從業務員那里獲得需求報告，分析生成項目模型報告；界面工程師得到項目模型后設計制作相應的模板和用戶界面原型，最終由客戶代表確認。 


    （3）業務主角：指與系統交互的各種不同角色。 

例如一個網上商店系統，業務主角有普通訪客、下定單會員、管理會員及定單的業務員、網站的商品信息發布人員、商品供應廠家的業務管理人員，物流配送管理員等等。 




    不管面對多么復雜的網站項目，當我們開始接手時，都可以按照一定的規范和流程進行展開。 

    網站項目涉及的領域很多，狹義地講包括了網頁制作、美工設計、程序編碼、系統及網絡管理等專業技術，廣義上又包含了企業管理、市場營銷、心理學、廣告學等更多領域的知識，在項目進行過程中還涉及到項目管理工具、文檔和設計開發管理規范、開發及測試環境部署等特殊領域的問題，這對一個項目經理和小組來說是個嚴峻的考驗。 


    網站設計發展經歷了靜態網站、交互式網站、商業應用、特殊應用的過程，隨著企業對網絡應用的理解和認識，對網站的功能要求越來越復雜，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟件工程，越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，“網站即軟件！”，借鑒軟件工程的思想并可從中尋找出網站項目管理的規律和方法。 


    網站項目管理分成以下六個階段進行： 

    一) 需求分析及變更管理； 

    二) 項目模型及業務流程分析； 

    三) 系統分析及軟件建模； 

    四) 界面設計、交互設計及程序開發； 

    五) 系統測試、部署和文檔編寫； 

    六) 客戶培訓、技術支持和售后服務。 

    在每個階段，都必須建立“里程碑”，代表當前工作的階段性成果，并以此作為進入下一階段的標準，實現對項目質量的控制和管理。 






    第一階段：需求分析及變更管理 

    假如病人上醫院看病，醫生需要“望、聞、問、切”，耐心仔細地了解完情況后，確定病因后才敢開藥方。而我們在接手一個網站項目的時候，是否真的弄清楚客戶的“病因”？又有多少回等到項目做到一半的時候才發現客戶的需求根本不是這樣的？！ 


項目本來是為滿足客戶需求目標而進行的，然而結果往往并非如此，因為：“客戶也不知道自己的需求是什么！”在所有不成功的案例中，這句話也許是我們聽的最多的。事實的確如此，這很令人沮喪。慶幸的是網站項目和建筑工程最大的區別在于：大樓建到一半的時候，不可能重新澆注地基，只好推倒重來，但網站項目卻經常在頁面制作、交互設計已經完成的時候還可以更改核心，甚至重新架構。 


做好需求分析并建立變更管理機制是保證項目順利完成的原始基礎。 

    ● 重要角色：項目經理，業務員，客戶代表。 

    ● 獲取文檔：通過與客戶的討論等各種渠道獲得需求。 

    ● 里 程 碑：《需求分析報告》 

    ● 注意事項： 

        ☆ 技術是為客戶服務的，采用對用戶最有效和經濟的設計方法才是最好的，而非采用了最好的技術和配置就能設計出最好的方案。所謂最好的技術附帶的潛臺詞往往就是高昂的成本、漫長的開發周期和潛在的不穩定，切忌將客戶當作技術的試驗田。 


        ☆ 記住“需求是一定會變的”，同時不要害怕客戶提需求。如果因為害怕看見大象的全貌而只摸摸大象的腿，怎么也不可能設計出客戶所需要的系統。 


        ☆ 鎖定需求，學會放棄。對超出計劃和目標的需求可以通過制定升級計劃或二期工程，從當前的項目中轉移出去，否則系統可能永遠都在設計開發中，不斷修改和增加，則始終沒有可以發布的版本。 


        ☆ 《需求分析報告》應得到客戶和全體項目小組的共同認同，切忌公說公的理，婆說婆的理，只有所有成員都對目標有清晰一致的認知后，才能最大地提高工作效率。 


    ● 技巧和方法： 

        ☆ 仔細聆聽，羅列客戶的所有要求； 

        ☆ 將需求進行分析，確認可操作的系統模型； 

        ☆ 利用最自然的語言對系統進行描述，使每個開發人員不會產生歧義； 


        ☆ 迅速確定系統的業務主角； 

        ☆ 分析確定每個角色的權限及可操作的功能； 

        ☆ 制作流程圖和示意圖將需求表現出來； 

        ☆ 讓客戶參與到示意圖的設計中，及時正確地反應出需求變更； 


        ☆ 制作需求變更日志，保留升級版本，通過版本控制進行需求管理； 


        ☆ 通過《需求分析報告》使每個參與人員看到共同的努力目標。 




    在這個階段，我們通過需求分析對項目得到一個初步的認識，并通過編寫《需求分析報告》得到一份客觀的可參照的重要文檔，這是個很好的起點。 


    客戶的需求基本清楚了，但是客戶并沒有教我們該怎么做。當客戶把球拋給了項目小組，看你如何把球接起來呢。 

    好吧，下面讓我們繼續…… 





    第二階段：項目模型及業務流程分析 

    我們需要業務流程分析人員將客戶需求分解和優化，網絡技術的應用所產生的電子流程工作方式既不能徹底更改傳統的工作流程，也不是對傳統工作流程的簡單復制，而是需要對傳統的工作流程進行合理的優化、改進和重組。 


    用戶提出的需求通常是凌亂的、不完整的，甚至是不正確的，而且，更準確更精細的需求經常是在項目開發進行中才被挖掘發現的。缺乏經驗的項目人員往往在接受任務后迫不及待地進行系統分析和開發，而不愿意多一點時間在和客戶反復推敲項目需求和模型，開發過程中想當然地憑空為客戶做很多假想，只能是費了九牛二虎之力之后吃力不討好。 


    業務流程分析員重點需要協助客戶將需求進行歸納分析，查找出所有的業務主角，確定業務主角后，將每個主角的相關活動及流程清晰地制定出來，最終設計出業務邏輯圖。 


    為了使用戶更好地理解系統設計方案，在時間條件許可的情況下，為系統制作用戶界面原型圖是非常有效的辦法。在尚未進行開發之前，客戶就能對今后要完成的系統能夠直觀地看到效果，并能根據需要進行調整，將大大提高項目成功的可能性，同時可減設計過程中的更改工作量。 


    ● 重要角色：業務流程分析師，用戶界面工程師，系統分析師。 

    ● 獲取文檔：《需求分析報告》。 

    ● 里 程 碑：《項目模型報告》、《用戶界面原型》、《設計開發計劃書》。 

    ● 注意事項： 

        ☆ 業務流程應符合客戶偏好和習慣，以客戶的環境和技能水平設計系統，切忌以項目小組的喜好隨意設計； 


        ☆ 請客戶和用戶模擬操作，找出盲點和分歧點，問題越早發現越容易處理，損失越??； 


        ☆ 制定性能和功能指標，作為下一階段測試工程師的工作依據?？蛻魧δ艿男枨笙鄬碚f比較敏感和直觀，但是對性能的需求很難提出具體的要求，這就需要系統分析師在這個階段進行明確，并作為系統設計的依據之一。 


    ● 技巧方法： 

        ☆ 真正以用戶為中心的設計，到客戶的實際工作環境中觀察和記錄； 


        ☆ 仔細查找各種業務主角，并描述不同主角的各種操作流程與步驟； 


        ☆ 簡化需求，將客戶的需求歸納整理，抓住核心問題； 

        ☆ 細化需求，針對核心問題，模擬用戶角色，進一步確認流程和規范； 


        ☆ 認真制定設計計劃書，為下階段的工作打好基礎； 

    在這個階段，我們將客戶的需求轉換成一個切實可行的設計方案，并為客戶重新進行業務優化和組合，定出項目目標。 


    現在我們總算找到方向了，剩下的就是開始攻堅。向下一個階段進發…… 





    第三階段：系統分析及軟件建模 

    如果說前面兩個階段是設計大樓藍圖，那么，我們現在要開始打地基了。 

    系統分析和建模是項目開發的核心工作，對于一個有經驗的開發人員來說，客戶的需求有很多方式可以實現，但是不同的構架對系統今后的維護、升級和擴展具有天差地別的影響，一個不合理的結構用不了多久就得完全拋棄，重新開發。 


    如果眼光僅僅放在滿足客戶眼下的需求，當問題出現時再不斷修補，頭痛醫頭，腳痛醫腳，甚至系統構架需要不斷調整或重新設計，那么，很快就會陷入代碼泥潭或墜入系統重復開發的無底深淵，項目完成時的成就感將被無止境的沮喪所代替。系統分析決定系統開發的成敗，軟件建模使系統開發走向成熟。 


    客戶的需求一定會變，服務器和客戶端環境也不斷在變，考慮到不同的操作平臺、不同的應用服務器、不同的數據庫、不同的編程語言、不同的傳輸介質等等所帶來的影響，系統分析員面臨著艱難的選擇，任何人都不可能掌握甚至說精通全部的技術，孰優孰劣，何去何從？我們仿佛走到了迷宮的中央，四處都是通道，卻不知道哪里才是最快的出口。 


    “采用面向對象的開發模式并使用UML（統一建模語言）對系統建模！”，網站即軟件，軟件開發方法同樣適用于網站項目開發，這給系統分析員指出了方向。 


    建模并不等同于程序編碼，利用同樣的UML模型可以生成不同語言的框架代碼，而且可以通過反向生成，在編寫代碼過程中及時更新UML模型，這對系統分析員和項目管理人員來說是夢寐以求的。只要能夠仔細地把握客戶的需求，不斷改進軟件模型，那么采用什么樣的語言開發已經成了次要，大量的需求積累和分析工作能在客戶需求變化時得到高度的復用，即使系統采用新的語言重新開發，需要的也僅僅是編碼部分的工作。 


    ● 重要角色：系統分析師，構架設計師，數據庫工程師，業務流程分析師。 

    ● 獲取文檔：《需求分析報告》、《項目模型報告》、《用戶界面原型》、《設計開發計劃書》。 

    ● 里 程 碑：《系統分析報告》、《設計及編碼規范》、《系統模型工件》。 

    ● 注意事項： 

        ☆ 客戶比較關注的是功能實現，但是不意味著客戶不在乎系統的性能，成功的項目開發不會僅僅為表面上達到客戶的需求而忽視系統的缺陷和瑕疵，網站項目同樣需要有”精品”意識，樹立一個品牌將為自己贏得更多的機會和更豐厚的回報。 


        ☆ 客戶的初期需求或許很簡單，但開發人員不能不為客戶潛在的巨大需求打下堅實的基礎。 


        ☆ 也許是因為項目周期過短、開發人員技能達不到等因素，在小型項目開發中難以采用進行規范的系統分析設計和建模，此時，應盡可能采用模塊化設計、爭取代碼最大限度的復用。 


    ● 技巧方法： 

        ☆ 補充完善上一階段可能欠缺的系統性能需求； 

        ☆ 系統分析員需要站在全局出發，設計合理可行的系統方案； 


        ☆ 在需求不明的情況下設計多種解決方案，供客戶選擇； 

        ☆ 使用UML建模方式，將客戶變化的需求映射到模型中，大大提高系統的擴展性和開發效率。 


    走到這一步，最難的骨頭被啃了下來，當一個合理可靠的系統核心被設計出來時，客戶會很詫異地問他為什么看不到一行的代碼，但成熟的系統分析員已經成竹在胸。 


    下面讓我們一起看看整個系統是如何構建起來的…… 





    第四階段：界面設計、交互設計及程序開發 

    在網站項目開發過程中，這個階段也叫做構建階段，是工作量最大、最艱苦、最難以控制的階段。不管一座大樓藍圖設計得多宏偉，若沒有管道工、泥瓦匠、水電工等各種工匠一磚一瓦地艱辛積累，密切協作，這座大樓始終是空中樓閣、海市蜃樓。 




    如果客戶此時參觀項目小組的工作，他可以看到： 

    ● 美工設計師在根據用戶界面原型進行美工設計，準確地將系統的形象進行定位； 

    ● 交互設計師將美工的作品根據業務流程進行網頁的編輯，為用戶體貼地設計著交互程序； 

    ● 程序員根據系統分析員分配的模塊編寫代碼，一行行代碼將系統澆注起來，一個個模塊開始活起來； 

    ● 測試工程師不斷地檢驗著每個人的工作，單元測試、集成測試、負荷測試； 

    ● 文檔工程師開始收集、管理各種開發文檔，每天檢查更新記錄和隨時保證重要文檔處于最新版本； 

    ● 系統管理員為每個開發人員部署開發環境，并保證著最佳的工作狀態； 

    項目小組在項目經理的帶領下緊張而有序地進行著，全速開動。系統構建階段，控制開發質量，保證進度是項目經理最關注的焦點，通過合理地分配資源和任務、建立小組成員間的有效溝通和采用相關管理軟件控制能夠有效地提高開發質量和進度。 


    ● 重要角色：美工分析師、交互設計師、程序員、測試工程師、文檔工程師。 

    ● 獲取文檔：《需求分析報告》、《項目模型報告》、《用戶界面原型》、《設計開發計劃書》、《系統分析報告》、《設計及編碼規范》、《系統模型工件》。 


    ● 里 程 碑：《程序模塊》、《開發文檔》、《按客戶需求開發完成的系統》。 

    ● 注意事項： 

        ☆ 人不是機器。當人成為項目開發流程中一個鏈條的時候，誰也保證不了人可以像機器一樣精確而不知疲倦地工作，因此，項目管理人員要保障小組成員之間有效地溝通和協作。在劃艇比賽中，不是人數越多就劃的越快，當有人喊著號子，大家齊心協力協調行動時，這艘皮艇才能快速地向目標駛近。 


        ☆ 測試是保證質量最直接最有效的方式，只有不斷地測試、測試、再測試，才能使系統達到滿意的質量。把BUG消除在萌芽狀態是最理想的，遺憾的是老虎也有打盹的時候，何況人還會偷懶？系統構建進度最快的時候通常就是BUG產生最多的時候，只有進行反復交叉的測試才能確保質量。 


        ☆ 交互設計師是系統和用戶之間的橋梁，真正從用戶的方便和習慣上下功夫，無論是一個彈出窗口還是站點的導航設計，甚至意外出錯的提示等等，都需要精心設計，反復雕琢。交互設計如果能解除新用戶對系統的恐懼，將會贏得意想不到的奇效。 


        ☆ 程序員在編碼過程中需要和系統分析員保持密切的協作和溝通，在規范的系統開發過程中，隨意的個性化是極其有害的，任何一個自定義函數或字段都可能造成系統崩潰。構建一個系統好比將1000塊磚頭壘成一疊，程序員再往上加一個模塊上去的時候都得想想擺正了沒有，否則壘不到幾十塊的時候，系統就轟然倒塌了。系統就是這么一回事，一點也不好笑。 


    ● 技巧方法： 

        ☆ 利用項目管理工具對項目進行管理，無論是Project還是Starteam，或是其他工具都行； 


        ☆ 建立文檔管理規范，采用相應的文檔管理工具對版本進行控制，PVCS或VSS都是可選擇的工具； 


        ☆ 創建團隊的溝通環境和渠道，利用郵件或者論壇，開會或者遞紙條，一切有利于交流的方式都可以，以保證協作成員之間迅速繞過障礙，奔向目標，人力資源經理的忠告是：溝通是提高團隊凝聚力最有效的辦法； 


        ☆ 建立BUG匯報及處理系統。只要是軟件，就一定有BUG，雖然這是個灰色笑話，但捕捉和消滅BUG是開發人員的天生義務，建立BUG管理系統可以爭取使同樣的錯誤不再犯第二次，當系統日漸完善的時候，那長長的BUG消滅清單就像工程師們的累累戰果。 




    系統的全貌終于露了出來，客戶的心這時候總算踏實了些。 

    不過這時候可不是結束的時候，在軟件開發過程中，剩下的10%工作量都可能會拖延占用項目的90%時間。 





    第五階段：系統測試、部署和文檔編寫 

    意外在網站項目管理中不是個新鮮詞，最大的意外就是沒有意外。 

    系統開發完成后，雖然經過了一次又一次的測試，但是在部署過程中仍然隨時存在著意外。此時，最常聽到開發人員說的一句話就是：“奇怪？！怎么在我這里好好的，放到別人那里就不行了？” 


    ● 測試工程師根據《系統分析報告》和《項目模型報告》模擬測試環境，按照測試指標對系統的功能和性能進行全面的測試，編寫測試報告，并通知項目成員進行修正。 


    ● 部署工程師會同客戶代表進行安排配置和調試，直至正式發布啟用。 

    ● 文檔工程師撰寫各種文檔，包括系統白皮書，用戶使用手冊，管理員手冊，客戶培訓文檔，用戶幫助等等，并總結設計和開發文檔，進行項目總結。 


    中國有句古話：“善始善終?！表椖啃〗M協助客戶快速部署并提供相應文檔，不但能為售后服務節省大量精力和成本，同時能夠大幅度提高客戶滿意度。 


    ● 重要角色：測試工程師、文檔工程師、部署工程師、客戶代表。 

    ● 獲取文檔：《需求分析報告》、《項目模型報告》、《用戶界面原型》、《設計開發計劃書》、《系統分析報告》。 


    ● 里 程 碑：《測試報告》、《技術白皮書》、《用戶使用手冊》、《客戶培訓文檔》、《用戶幫助》。 

    ● 注意事項： 

    ☆ 測試不單包括功能測試，特別需要注意到性能測試和兼容性測試，應盡可能創建不同的模擬環境，取得完整的測試數據，針對測試結果對系統進行改進。 


    ☆ 開發環境和部署環境不同造成實施過程出現“意外”一點也不意外，只有到客戶能夠良好地駕馭系統才算達成目標。 


    ☆ 對照前兩個階段所做的《需求分析報告》和《項目模型報告》，檢查目標是否都已經實現了？馬虎的項目小組也許經過長時間的開發，已經忘記了最早的項目目標，而需求計劃在開發過程中也許經過了大量改動，事實也許就是這樣，等做完了，客戶和你才找到了真正需要的東西。 


    ● 技巧方法： 

        ☆ 根據系統的特性，采用專用測試軟件或編寫測試工具，有助于提高測試的效率、準確性和完整性。 


        ☆ 選擇對系統完全陌生的典型用戶模擬操作，能夠發現大量系統缺陷。 


        ☆ 無論是網頁模板還是程序模塊，養成在源代碼中寫注釋的良好習慣，對開發過程中任務交接、糾錯或今后二次開發都非常重要。 


        ☆ 交給客戶的文檔越規范詳盡，后期的成本越節省。 

    當系統終于如期運轉的時候，該好好祝賀你了，系統開發完畢，對于項目小組來說接近了終點，但是對于客戶來說才是一個起點，項目進入收尾階段就是從客戶培訓開始的。 


    最后讓我們來交鑰匙去吧…… 





    第六階段：客戶培訓、技術支持和售后服務 

    開發一個老客戶的成本遠遠低于拓展一個新客戶，網站項目作為一個特殊產品，對客戶的培訓及技術支持尤其重要，而對于客戶來說，一旦失去了技術保障，系統出現問題或需要擴展和升級的時候，將面臨著怎樣的困境？！ 


    因此，為客戶建立售后支持快速反應體系，不但可能會贏得更多的業務，也能消除客戶的后顧之憂慮。至于客服支持的費用，總能找到雙方可接受的條件。 


    ● 重要角色：培訓工程師、客戶支持工程師、業務員。 

    ● 獲取文檔：《需求分析報告》、《測試報告》、《技術白皮書》、《用戶使用手冊》、《客戶培訓文檔》、《用戶幫助》。 


    ● 里 程 碑：《培訓手冊》、《客戶服務記錄》。 

    ● 注意事項： 

        ☆ 客戶培訓不僅僅是本期項目的一個終點，同時也是開啟新項目的最好契機，認真做好培訓文檔，把接力棒順利交接過去，今后會受益無窮。 


        ☆ 技術支持和服務是網站項目非常重要的環節，它保持雙方的聯系和業務往來，合理控制服務成本，可以增加客戶的忠誠度。 


    ● 技巧方法： 

        ☆ 電話、郵件、網站都是建立客戶支持的良好手段，將相應文檔發布在網站上對客戶來說有時更加方便。 


        ☆ 可按照客戶情況的緊急度確定客戶支持的反應時間和方式，使客戶支持工作更有效率。 


        ☆ 建立客戶服務紀錄，跟蹤客戶運行狀況和變更記錄，為下次的合作建立密切的聯系。 






    歷經千辛萬苦到達這里的時候,好好慶祝吧,將成功的喜悅和經驗仔細回味…… 





    理想和現實總是有距離的，當我們真正開始實施網站項目的時候，卻發現： 

    ☆ 項目的周期太短，寫代碼還來不及，哪有那么多時間寫文檔！ 

    ☆ 人員有限，一個項目只有兩三人干，經驗又不足！ 

    ☆ 掌握項目管理軟件和相應工具的學習成本太高，一個臨時的隊伍沒有培訓時間！ 

    ☆ 項目小組分散在各地，無法集中，進度質量控制不??！ 

    ☆ 沒有人會測試方法，沒有人會建模，沒有人會……怎么辦？ 

    ☆ …… 





    對網站項目來說，存在著各種各樣的問題，本文探討的是一般方法，不是形式，其目標是為將網站項目分階段、分角色進行有效地組織和管理，從而完成網站項目的要求。雖說不管黑貓白貓，能抓老鼠的貓就是好貓，但畢竟會放捕鼠夾的貓更可能會成為一只最出色的貓。 




    最后讓我們來看看網站項目管理成功和失敗的典型特征： 

    失敗網站項目總有這樣那樣的原因： 

    ● 始終弄不清楚客戶的需求，丟三拉四，尤其對變更無法管理； 

    ● 總期望奇跡發生，有英雄出世去完成不可能的任務； 

    ● 誰也說不清楚究竟哪一天能把項目做的完； 

    ● 沒有測試報告和性能分析； 

    ● 程序員成為項目的主宰，萬一程序員走了，項目就無法進行下去； 

    ● 客戶要的是結果，開發文檔寫不寫無關緊要； 

    ● 同樣的錯誤一犯再犯，各自為戰； 

    ● …… 



    成功網站項目管理總有共同的特征： 

    ● 明確的分工和階段控制，每個階段都認真完成“里程碑”； 

    ● 真正以用戶為中心進行設計，進行周密細致的需求分析和業務流程分析； 

    ● 完整規范的文檔管理，文檔成為是系統開發重要的組成部分； 

    ● 有效的團隊溝通和協作，不因為個人因素而嚴重影響系統品質和進度； 

    ● 建立質量控制保障體系，具有標準嚴謹的測試方法和報告； 

    ● 對意外狀況具有快速的反應能力和解決辦法； 

    ● …… 



    網絡象一個巨大的迷宮，有的人看著到處是陷阱，有的人隨時能找到新鮮的奶酪，今天有人丟掉了自己的奶酪，明天又在其他地方發現了新奶酪。把自己武裝起來，將網站項目進行徹底！ 






    附錄：相關管理軟件簡介： 



1.Microsoft Project 2000 

    Microsoft Project 2000是一個國際上享有盛譽的通用項目管理工具軟件，適合各個行業進行項目管理。該軟件凝集了許多成熟的項目管理現代理論和方法，因此能夠高質量地管理各種類型的大、中型項目。 


    Microsoft Project 2000提供了很多重要功能，如 Gantt 圖表（活動時間表）的開發、規劃與實際結果的比較、PERT 
圖表（網絡圖表）的開發、任務的定義、任務之間相關性的定義、對任務的資源分配和資源平衡。 

    比較突出的管理技術如： 

● 時間管理方面：橫道圖，里程碑、關鍵路徑法（CPM）、計劃評審技術(PERT)。 

● 成本管理方面：自下向上估算技術、成本累計曲線（S曲線）、凈得值評價技術。 

● 人力資源管理：目標管理、責任矩陣、資源需求直方圖。 

● 風險管理方面：蒙托卡羅模擬法、基礎統計技術。 

● 溝通管理方面：基于電子郵件和Web的項目協調技術。 



2.Primavera Project Planner 3.0 

    Primavera Project Planner (簡稱P3) 為現代的項目經理提供了一件最具有價值的東西：進度計劃的控制方法。主要用于項目進度計劃、動態控制、資源管理和成本控制。 


    它具有以下特點： 

● 同時計劃、管理和協調多個工程。 

● 多種方案分析比較，按照目標計劃跟蹤管理。 

● 在多用戶環境下可以安全共享工程數據。 

● 利用先進的資源平衡技術對資源進行優化。 

● 通過網絡圖、橫道圖、時標網絡圖和資源強度圖等多種方式反映工程數據。 

● 按照工作分解結構(WBS)、組織機構分解結構(OBS)、分類碼和費用 

● 科目對數據進行分組、排序、篩選和匯總。 

● 通過多種方式和其他軟件進行數據交換。 

● 通過Internet/Intranet進行遠程數據傳輸。 



3.StarTeam 標準版 

    StarTeam的主要功能在于提高當今分布混合式軟件工程開發團隊的工作效率。 

● 使用簡便：Starteam的操作與微軟的Windows Explorer 一樣, 其簡便性曾多次獲獎。 

● 視覺式項目結構管理：Starteam把項目的每一部分用文件夾式,多層縱深式管理。 項目可以從不同角度觀察。 

● 升級式開發模型：通過使用Views and Views Labels, Starteam 允許用戶定義升級狀態和把整個應用結構從開發周期的某一階段移植到另一階段。 


● 主動性變化要求管理：Starteam 對軟件組成部分和其變化采用統一架構, 變化可用多種方式的查詢、分類。 

● 協作式交流： Starteam采用單一界面為隊員提供交流, 使所有隊員可以參與決策過程。 

● 與微軟網絡會議系統兼容：通過Starteam統一界面, 所有隊員可以參與在線討論、展示功能、共享信息。 虛擬會議功能可以通過桌面菜單使用。 

● 任何人在任何地點參與項目：Starteam真正的客戶/服務器結構及對TCP/IP協議的支持, 使得每個團隊成員在世界任何地點享受網絡上的同樣的功能。 


● 與PVCS、微軟Visual SourceSafe兼容：因此, 用戶不必放棄原有的標準來采用Starteam的加強功能。 



4.PVCS 

    PVCS在軟件開發過程中可以完善地管理軟件系統中的多重版本；自動創建完整的文檔，保障軟件的維護；全面記載系統開發的歷史過程，包括誰作了修改，修改了什么，為什么修改；管理和追蹤開發過程中危害軟件質量以及影響開發周期的缺陷和變化；管理需求分析等。 


    PVCS包含多種工具。 

● PVCSVersionManager會完整、詳細地記錄開發過程中出現的變更和修改，并使修訂版本自動升級。 

● PVCSTracker、PVCS Notify會自動地對上述變更和修改進行追蹤。 

● PVCSRequisitePro提供了一個獨特的MicrosoftWord界面和需求數據庫，從而可以使開發機構實時、直觀地對來自于最終用戶的項目需求及需求變更進行追蹤和管理，可有效地避免重復開發，保證開發項目按期、按質、按原有的資金預算交付用戶。 




5. Virsual Source Safe 

    Microsoft Visual Studio企業版包含的版本管理工具。該工具包括一服務器和一通過網絡可以連接服務器的客戶端。VSS提供了基本的認證安全和版本控制機制，包括CheckIn(入庫)、CheckOut(出庫)、Branch(分支)、Label(標定)等功能；能夠對文本，二進制，圖形圖象幾乎任何類型的文件進行控制；提供歷史版本對比；可以集成在Visual 
Studio中。 

    VSS的客戶端既可以連接服務器運行，也可以在本機運行，非常適合于個人程序開發的版本管理。 

原文轉自：http://www.anti-gravitydesign.com