中國大陸的電子商務網站(linux+jsp)的計費收費系統平台設計規劃

電子商務網站中的收費繳費框架主要使用客戶預存款的形式，客戶通過繳費途徑把錢存入電子商務網站絡有限公司客戶名下，並由計費框架主進行用款帳目和明細的 管理；向客戶提供帳單結算。客戶可以通過個人控制中心審查自已的預存余額，曆史帳單；現行定單；凍結金額；並可以要求發票和帳單投遞（投遞費可以假定作? 一項服務扣費），當然也可以客戶自行到網站公司營業部打印帳單。
一、繳費框架；

* 使用充值卡繳費：例子，超聲讀書卡；方法是相對簡單；如果收費框架功能到位，可以把客戶未用完的余額退回。
* 客戶銀行轉帳：通過一卡通等銀行轉帳手段，客戶直接在網上按指定帳號向電子商務網站彙款，這個方法需要與銀行的協同工作還不太清楚；
* 人工彙款；人工彙款是最古老的方式之一，缺點是太麻煩的話客戶會放棄在電子商務網站上消費的欲望；
* 短信收費：這個方式目前有點臭名昭著，是象信息台一樣通過電信（移動）高額收取短信費用；缺點是成本高（固定成本每月2000，浮動成本每條兩毛錢），而 且不太受消費者歡迎；這類有償信息發布短信的營利案例好象沒有聽說過。另外，稱動似乎正在壓縮夢網短信平台，原因是投訴太多。所以這個方式不宜作?基本業 務的收費途徑。
* 其他：還有什?，歡迎提議；

繳費框架需要一個客戶繳費項目的跟蹤系統。最簡單的情況下，是由電子商務網站後台工作人員輸入帳單，但仍需要讓客戶有可能從個人控制中心追蹤到自已的帳單。如果使用上述第一，第二套方式，可以減少工作人員的工作，但需要相應開發客戶的繳費系統；

二、計費框架

* 客戶計費主要通過申請服務後的逐項扣減客戶充值額進行。每當客戶申請一項電子商務網站有償服務時，就會檢查客戶余額是否足以支付該項服務內容；如果足以支 付，就凍結相應的金額，直到客戶取消該項訂單?止；每當客戶接受一項收費服務，就從凍結額中扣除相應的款項；直到凍結金額用完。凍結金額不是客戶的充值 額，這個概念一定要搞清楚。
* 客戶可以在個人中心中審查本人的余額，以及已經凍結的金額和相應的服務；以及本人曆史交易記錄。
* 客戶可以要求退回充值額（可以鼓勵客戶多存放心存），?覽帳單，可以要求打印帳單並郵寄發票。

三、系統要求：

繳費收費的要求比信息類的系統要求要高，主要體現在事務安全性和訪問安全性；因此要求使用支持事條的數據庫，以及使用安全性連接，並且，客戶密碼應該作進 一步的加密，以及避免使用明文傳輸，包括認證碼安全等。因此，這意味著整個系統檔次的提升。需要開發的相應組件和系統管理項目包括：
1、開?PQ數據庫和更嚴格的自動備份；(盡可能不使用Oracle/DB2,原因是資源耗用太大,同時必須保證多台服務器形成的工作組同時工作;?此, 備份服務器也要隨之升級和熱備,系統管理成本就會直線上升,保守估計是十倍以上).
2、開?網站安全證書和安全鏈接；
3、開發實時隨機認證碼；
4、開發java applet的密碼認證插件；
5、全部用戶記錄轉移到PQ數據庫；
6、全部用戶密戶進一步使用隨機數和散列加密——那意味著即使是網站管理員/數據庫庫管理員也無法查探用戶密碼，只能采用恢複處理。
7、現階段不打算申請VeriSign公鑰（可以讓IE在轉向安全鏈接時不詢問用戶"是否接受該站證書"，有必要嗎？45000美元一年噢）。

以上六項不是計費收費框架的所需要的工作本身，而是開通計費收費功能的基礎。

四、計費收費框架中的可見的必要模塊

* 個人繳費平台；如第一點所述
* 個人訂單平台；訂單跟蹤，事實上每一項收費服務都需要自已的訂單系統；
* 個人帳單平台：這本質上相當于ERP中的報表系統，原則上要求可以使用打印機輸出；這?包括個人交易日志；
* 交易日志；如果說對于其他服務內容日志是有用的話；對于收費業務來說就是必須，這是解決業務潛在爭端和交易中止事故恢複的關鍵記錄；日志要求能夠實現他機同步記錄；
* 交易扣費接口；要求所有收費項目都實現一個統一的凍結和費用扣除接口，並且所有的費用應該可以直觀明了的地進行修改和調整。
* 還有什?嗎？歡迎提示。
http://blog.csdn.net/zwwwxy/archive/2005/05/26/381754.aspx
http://zwwwxy.blogchina.com/1667114.html

互聯網真正的未來是ASP

互聯網可以是一條低級的數據通道，僅僅是各台獨立的應用主機彼此"hello world"的途徑；也可以成?一條數據總線，讓互聯網本身成?一台計算機，直接向形形色色的客戶提供形形色色的應用需求功能。?什?要不停地花費金錢買 不斷升級的電腦呢??什?要不停地花錢花心思買軟件升級呢？對我們中的絕大多數人來說，我們需要的是功能，不是軟件。這個矛盾的解決，就系在ASP (Application service Provider)的身上，這是一個幾年前出現的，被無知的專家們炒作糟蹋夠了，現在是"始亂終棄"棄子段的名詞。但筆者卻認?，它才是互網網真正的未 來。

ASP（Application service provider，注意與微軟的asp，active server pages動態服務端網頁相區別，兩個完全不同的東西），早在2001年開始就成?IT界的新名詞，一度被許多業內"名人"炒作得大紅大紫；但幾年後的今 天，能夠記起這個名詞的人已經不多了；ASP在那段時間，無非是這批業內"炒作"專家?某些公司挂羊頭賣狗肉圈錢的又一個概念風潮而已，對于互聯網本身並 沒有什?現實的意義。參考這些炒手的文章，可以知道這種炒作消失的一個重要原因就是對ASP的範籌和業務方式並沒有嚴格的限定，居然把主機租憑，軟件租 憑，外工(outsource)開發，咨詢，甚至于互聯網接入（ISP）都當成了ASP，而真正意義上的application provider，應用的提供，反而沒有幾個人加以強調；估計這些紙面上的專家本來就對此不甚了了：基本概念都沒有搞清，也難委他們妙筆生花吹得起來，這 套本事，俺要好好學習才行。

筆者不會吹牛，只能實實在在地從基本概念出發，所以再對ASP中的A,application作一個定義：應用，就是可以提供某種特定功能的軟件。因此 ASP，應用服務提供商，就是專門通過某種軟件向客戶提供實際商業功能的運營商，並收取相應的費用。這?關系到兩個關鍵要點：一，軟件本身的所有權屬于運 營商所有；二，軟件功能可以有償提供給多個客戶。筆者認?，所有概念的精確有效與程序開發中要求定義精確的的意義是一樣的，ASP是大器還是垃圾，能否作 出判斷，取決于它的外延邊界是否是清晰的。因此，我們需要首先把一些接近的行業服務剔除出ASP的範籌。象主機托管不是ASP，企業軟件出租不屬ASP （不能讓多個客戶同時使用同一個軟件），，外工項目不算ASP，當然，接入服務更不算ASP。按這樣一個概念範籌一套下來，當前中國甚于全世界所有聲稱是 ASP的供應商，幾乎統統是挂羊頭賣狗肉濫竽充數之輩，因此全部不在本文討論之列；相反，許多沒有聲稱是ASP的公司，卻是明白無誤的ASP運營商，其中 包括Google,AOL,Ebay和形形色色的遊戲公司等，還有中國的163.net（想不到吧？）。

ASP概念實際上是1995年互聯網出現後，IT技術兩大發展方向在互聯網上的體現。這兩個方向，一個是以微軟?代表的以肥胖客戶機?主要基礎的桌面運算 派；而另一方則是以SUN和網景公司主張的網絡計算派。顯然，以公司競爭而語，SUN和網景已經落敗；但如果據此認?網絡計算派就此敗給桌面計算派，就太 不慎重了。從近幾年來微軟業務發展的緩慢，和GOOGLE等網絡公司的異軍突起，反而說明，網絡計算派正在逐漸贏得優勢地位。

ASP存在的意義，實際上是對IT技術發展到今天的所面臨的困境的一種總結性調整。首先，桌面電腦能夠滿足人們的需要的能力有效，以Windows而言， 作?一個桌面它已經接近于盡善盡美，從windows95開始，windows的發展無非重複著安全性/穩定性/?動快速，以及界面花梢，個性化，多媒體 這類實際上是邊緣性的功能在修修改改，windows不能提供一個象widnows95取代dos和字處理機那樣的革命性的模式更換，是微軟業務模式實際 上已經走向衰退的重要原因，那怕長角(longhorn)吹響，筆者不妨大膽預言，更象是微軟業務的挽歌。其次是大型的綜合性的軟件應用系統對于普通使用 者來說太昂貴了。IBM的大型主機有多貴就不說它了，還不包括?頭的軟件呢！SUN的敗落很大程度是由于它死死不願放棄劫持客戶從設備過分昂貴的價格中賺 取利潤的業務模式。但是假如這兩者通過ASP，應用供應，將同樣成本的應用功能以有償收取使用費用的方式供應給不定量的用戶的話，那?，軟件就不再是一種 商品，而是一種百分百的服務，（中國盜版的"民族工業"就未日來臨了），將在網絡計算和桌面計算中走出一條新路來，這時侯，會是什?樣的光景呢？

這就是ASP的未來。互聯網的技術發展使這種未來清晰無疑地展現在筆者的眼前，毫無疑問，明天，基于桌面軟件的那家巨人，和基于昂貴系統銷售的幾個次巨人都必然會從市場消失，真正贏得市場的將是ASP公司；特別是對中國這種光?子窮蛋成群結隊的國度。

筆者可以用大家都用得最多的電子郵件這種功能來說明ASP取代桌面應用的必然性。筆者曾經考慮以linux?基礎提供郵件服務器，相比于IBM的 Domino，微軟的Exchangerserver，剔除盜版的因素（在中國是不可能的），linux毫無疑問是有競爭力的。但這個設想在大約半年前被 徹底否定了，原因不是郵件服務器技術本身，而在于隨之而來的垃圾郵件和郵件病毒。筆者本身就是一個安全專家，當然有辦法解決郵件服務器上的病毒問題，但是 作?一個完整方案提供給客戶，還要把郵件服務器控制在幾萬元以下，就遠不是這?簡單的問題。病毒與其他東西還不一樣，光從第三層控制是不行的，在服務器端 也不能使用象桌面機那樣的IO流監測手段，在網絡上必須以代理方式停留在第七層才能分解出病毒特征碼。無論那一種方案，不是意味著主機資源成十上百倍的增 加，就是網絡性能成十上百倍地下降。

病毒還算了，垃圾郵件就更麻煩了。垃圾郵件麻煩就在于它是郵件，你不能預先設定只有誰的郵件才能收；而且smtp協議本身就是open relay的，這樣只要願意，一個初級的程序員也能夠從自已的主機上向任何地點以任何名義發任何的郵件。事實上世界上還沒有有效的防垃圾郵件的方法，使用 類似防病毒的特征字符串判斷吧？對于垃圾郵件來說，工作量而大十倍；采用目前的管理員設黑名單吧？實際上發送者可以按詞典每封信都可以來自一個名義地址。 除了SMTP擴展到ESMTP還要再擴展，（我看需要一個發送認證機制，由第三方核准），作?郵件服務器使用者來說，投資也將是直線上升。

這就是問題了：誰願意花上百萬的投資來?公司幾百個，甚至幾十個帳號提供簡單的電子郵件服務呢？有是有，但是市場會很小。舍此，估計許多人如同筆者的郵箱 一樣每天上千封垃圾郵件，還有帶病毒的，只能在知道有用郵件到時遠程先挑起要收的信收下來，然後把其他的統統刪除。某種程度上，電子郵件作?一種互聯網上 最有用的功能，它，已經死了！

但作?提供成百萬上千萬用戶的郵件服務商來說，象163.net來說，它?自已的有限的服務器提供防垃圾郵件，防病毒郵件的可用服務，並提供遠程可疑郵件 由用戶戡別的服務，?你提供一個可用的電子郵件，代價相對來說要小得多，攤到每一個用戶頭上也就一兩元投資，和幾角錢的維護費（或者會請幾百個MM來管理 黑名單）。因此，毫無疑問，被?多免費郵件打垮的郵件服務肯定會重新出現，只不過，千萬不要以?那是免費的。

今天的幾家郵件服務供應商，並沒有滿足這個要求，實際上他們的防病毒防垃圾郵件的能力還比不上一些大公司的IT部門；原因一來是免費嚷喝太久了，沒力氣幹 實事了（沒錢沒實力?），二來是免費提供同樣不能用的郵件商還是不少，三來中國比較落後，沒有幾個人真的離不開電子郵件，自然不願掏那筆錢。但從長遠一點 看，兩三年吧，中國出現象AOL那樣的ASP供應商是必然的，只不過，電訊老總和請信息?業部長打幾場高爾夫球，讓部長大人再按中國特色下一部行業管理辦 法：所有郵件ASP都必須由電訊發放執照規範經營；也肯定電訊會有意無意的統統不放：他自已，或者他的夫人，公子，公主自已來做中國的AOL。

這是無需擺弄易經就可以預言的有中國特色的社會主義ASP前景。
http://blog.csdn.net/zwwwxy/archive/2005/06/13/393671.aspx
://zwwwxy.blogchina.com/611463.html

做軟件需求最重要就是分解用例場景，沒有用例就不是需求

軟件工程這類書要學，不過軟件工程軟件需求最關鍵就是用例場景的合理建立，這條，好象沒有什?大學教科書談到，仿佛中國的大學計算機科學系教師統統沒有做 過軟件項目的，完全沒有這個概念。所謂的軟件需求，如果不是變成走不通的?代碼，就是用不上的美工方案，程序員對此除了幹瞪眼是沒?的。。


其中最大的原因就是從事網站或者類似的軟件需求的許多人都不懂真正的軟件需求是什?東西，包括我處理過的SAP/ERP項目這類都是同樣的問題，盡管那不 是網站；他們犯的一般共同的錯誤就是把網頁表現形式（那其實是美工的工作），以及內容的采排看作是需求，完全沒有一個用例的觀念。

用例，usecase，目前多見于UML下的對面向對象程序中的對象行?的表達；不過，這不是它的源泉；它之所以被看作是這類語言的標准URL描述手段， 是因?面向對象本身就是在虛擬程序中模擬真實世界那樣地工作；而真實世界，就是圍繞著用例展開的。用例的觀念其實也不能算是一個軟件概念，只不過在軟件領 域定義得最?精確而已，今天從每個人的生老病死，婚姻嫁娶，其實都是一個個的用例的描述和實施。用例，顧名思意，就是假如（假設）出現某種情況，采取什? 樣的行動；可能會有什?樣的結果；然後，根據這個結果，再采取什?樣的行動......直到得到希望的某個最終結局。

用例也叫場景，軟件，實際上就是對場景操作過程的描述，而不是一堆版面框架網頁的集成。沒有用例支持就不叫軟件，更加不叫項目——連垃圾都算不上。很多時 侯我們說需求不明確，其實就是說這個用例不清晰；在電子商務網站中，除了人員素質導致對基本概念方法不明白外，最可能的導因就是商業模式不明確，或者不成 立。這個成立與否，實際上可以從上面的假如如何那般的推導中進行初步的可行性推演。所以，程序員實際上有兩個層次，一個是你說什?他做什?，但永遠沒有結 果的。他卻的確實現了你（需求人員）提出的所有要求，但這個項目卻必然是永遠沒有結果的，因?，它本身只是把這個程序員當成網頁編輯用了，項目沒有基本用 例的支持。我想90%的程序員是這類"程序員"，沒有用例明確定義也就沒有軟件能力的評估，因?軟件人員不是美工。另一種程序員則可以從上訴推演中發現整 個項目本身有沒有用例，以及用例是否合理（理論上沒有明顯的邏輯障礙）；雖然程序員一般不應該關心商業模式是否合理，但實際上他有這個能力，常常是第一個 發現商業模式的問題，假如他也關心的話。

可惜大部分用戶需求人員不明白這個道理，反而可能會以?程序員是在推卸責任，或者是刁難需求；也正因?這個原因，需求人員和實現人員的沖突在項目中屢見不 鮮，倒不是個人矛盾的沖突，而是由于雙方沒能有一個基本的立足點。我見過這樣的項目，需求人員建一個大型網站的需求就是一大籮的每個網頁的非常詳細的描 述，到每個字每個連接......直至每個網頁出現的次序，項目經理說一個笑話：萬一他摔一跤，這籮子東西鬼才能再撿回原來的模樣。的確，負責需求的客戶 方副老總和一幫企業需求編輯辛苦做了兩個月，但其實這不是需求，而是使用這個項目軟件的具體編輯排版的安排；根本不是程序員要看的東西。程序員需要的是使 用這個網站時需要有那幾種用例邏輯，然後抽象出其中的對象，根據對象建立存儲方式（象數據庫存儲結構）和內容采摘方式。那大籮東東，實際上什?用處也沒有 的。開發軟件如同建房子，旁觀者可能問一句："建房子啊"就拍手說明白了，但對于開發員來說，如果得不到准確的房子細到磚磚瓦瓦的准確設計（需求定義）； 要知道建小平房和建金茂大夏都是建房子，建賓館還是建?儀館也是建房子，到底客戶要的是什?房子合適，不搞清楚幹下去的程序都是不負責任的，或者是冒牌 貨。

不懂軟件需求的需求人員一般會犯如下錯誤：一是把版面美工形式看作需求，其實程序員看程序如同醫生透過X光看一個人，看到的是骨架，至于是美人還是醜八怪 如果能看出來，那個醫生一定是變態的；在開發過程中都強調實現用例功能實現，而不是首先色彩如何花梢漂亮，後者不但不是主要的，也不是次要的，在開發過程 中什?都不是；一開始把精力放在這?當成需求實現是浪費時間浪費金錢。二是把靜態網頁當成需求，特別是當把靜態網頁當成prototype時更經常犯這個 錯誤；常常說："按prototype做出來不就行了？"實際上prototype本身如果不是看不出清楚的用例邏輯，就是可能有幾種用例解釋；何況真正 變成動態程序，與靜態的東西是不一樣的。我在網上看到的美女明星下了台到眼前成了醜八怪，就是這個道理。而且更遭的是，客戶還同時犯第一個錯誤，看著那? 不順眼就改一改版面還一天三變,不知不覺的基本用例就變成了另外一個東西，原來是賓館現在成了蓋?儀館，原來搞錯了因?不知道躺的人不同叫不同的館（死人 還是活人），試問，如何實現？項目開始和後期看到的同一個版面成?不同的故事絕對是經常出現的故事，軟件上稱?需求變遷，這是項目經常延期的最主要原因。


三是需求人員把定制了解成按客戶所有想法迎合靜態頁面，而不是按客戶的業務用例要求建立相應的程序；還要求程序員也這樣做；實際上，如果不能撥亂反正的 話，任何項目到此?止已經是死路一條：那不是軟件，無非是靜態網頁人員出租！需求人員常犯的另一個錯誤仍是不懂用例，就是把用例的使用方式當成了需求；這 種錯誤有時連初級程序員都會犯，最典型就是把一個菜單欄目當成需求，而程序員無法從菜單中看出明顯的簡潔的用例邏輯——這是一個沒有意義的菜單，天曉得? 頭是什?？同樣地，?頭的要幹的東西還一天三變。事實上，同一種邏輯用例可以用到N個欄目，那是"軟件的使用而不是軟件本身"。

以上的錯誤常見于網站建設，所以網站建設最通常的結局是不了了之，大概占了50%以上，無論設入多少錢多少人花多少時間都是如此的；除非有人能夠撥亂反 正，讓項目需求走上正道。而在ERP/DRP這類項目中，需求人員一般情況下是業務的行家，他們反而很容易理解用例是什?東西，象醫院收費，絕對不會把精 力放在收費界面有沒有脫衣舞女讓收費員提神上，收費這個用例有多少個環節是他們理解的。這種項目需求最易犯的錯誤是讓先進的計算機工具重複原始狀態下的不 合理的流程。最典型的笑話就是：手工審批要蓋五個章，用五天時間；現在電算化效率提高了一百倍，所以可以蓋五百個章（電子簽名呢！），時間嘛，仍然是五 天！在這?，矛盾不是有沒有用例，而是用例是不是合理的，最高效率的。

所以對于需求由于用例的沖突，程序員如果不想不了了之最後責任全部背上身的話，最好就是堅持原則；程序員迎合網頁編寫是沒有意義的，遷就需求也不是沒有意 義的，因?......無法遷就的，越是遷就就越是沒有辦法實現，或者客戶沒有辦法滿意的。軟件其實很簡單的，無非是分析好用例，然後讓計算機一步步實現 而已，用例，是所有軟件實現的前提：不然，軟件到底要幹什?
？好的軟件項目都有一個共同的特點，就是簡單的邏輯，明確用例。最典型的，看google,ebay
http://blog.csdn.net/zwwwxy/archive/2005/06/13/393671.aspx

企業業務軟件工程項目和商業軟件?品項目上項目需求管理的不同

http://blog.csdn.net/zwwwxy/archive/2005/06/13/393666.aspx
http://zwwwxy.blogchina.com/450321.html
企業業務軟件工程項目和商業軟件?品項目上項目無論是需求重點，實現方式，項目管理等方面都有極大不同。現在的軟件工程有關研究並沒有關注此中的區別，實 際上，其中絕大部分還集中在較簡單的?品項目上。對于需求變動要大得多的企業軟件項目來說，對需求進行分級管理是非常必要的，也是生死悠關的。


企業化軟件項目和商業軟件的（承包開發）還是有很大的不一樣的，最大的區別就在于項目需求的重點不一樣，以致于這兩種同樣稱?軟件工程，就其項目過程管理 是幾乎完全不一樣的。商業軟件的開發最大的特點是就是基本功能非常明確，只在細節上有多種選擇，所以商業軟件開發的項目管理重在源代碼管理和算法的優化， 以及測試嚴格，就測試要求的強度上單純軟件代碼的質量來說，要強于企業信息化的軟件工程項目。

企業信息工程項目一般來源于企業某一特定的業務軟件需求，象要上一個倉庫管理系統，從進貨到定期定標出倉平衡責任追蹤等；或者是一個生?流程配料系統，象 MRP2；或者是一個購銷一體計劃系統，象ERP（資源管理），等等。這種軟件有時侯會象國?的那些變相的會計軟件式的ERP一樣當成商業軟件開發，顯 然，這時侯與上述的成形商業軟件沒有太大的區別，但在企業實際上千差萬別的應用需求上，幾乎就是一堆電子垃圾。企業業務軟件是一種必須適應同時能夠優化企 業流程的計算機輔助運營系統，真正起作用的，通常只能是一對一實現定制；這種需求是如此廣泛，以致于大型企業如果不是聘有一兩家軟件咨詢顧問公司就是自建 一個計算機部門專門負責這一方面的工作；最典型的例子就是沃爾瑪特。

正由于企業用的軟件都存在著強烈的需求一對一定制的要求，所以這種項目其一是不便宜；如果一個企業客戶以購買商業成形軟件的理解水平來購買一個"項目"洽 談的話，在他理解什?叫企業項目前，最好不要打算做他的生意。一個企業項目動?數百萬上千萬是不奇怪的，上億也尋常，而一套商業軟件，無論名稱多?好聽， 什?第幾代ERP，都只不過是一萬幾千大洋就可以打發的；實在不願意給錢又不怕給罰盜版的話，還可以花五個銅板上街買一套盜版光盤現裝現用。

?了應付企業業務軟件項目的強烈的定制需求，供應商都提供了廣泛的基礎組件和嵌套工具，以便可以由二三級的程度員可以在現場?用戶一對一的進行定制試用更 改再定制等項目實現。典型如SAP，有朋友問我拿SAP的盜版玩玩，保證不外流。我費了很大的工夫才讓他明白，SAP有的只是基礎組件庫，還很豐富，涉及 到27個項目常用業務場合的組件庫，包括與之配合的數據庫預制定義（表定義），但絕不是象國內那些ERP那樣裝起來可以玩的東東。一個SAP項目要求用戶 按自已需求定購這些組件庫，以及必須的支持軟硬件，數據庫操作系統什?的，最經常的就是ORACLE和SOLARIS了；然後SAP項目組要到企業?蹲 點，聽各個部門講流程故事；然後是寫需求文檔，建原型，讓企業的項目組試用部門流程，基幹流程確定合乎需求了，下一步的工作就是簡單了，找幾個三流的程序 員用ABAP/4這種比javascript還簡單的腳本語言把各個組件的功能連成一個統一的流程。這個工作就完成了一大半了。——可別小看這些三流程序 員，在軟件蠻荒年代他們憑這一招可以拿到每個月兩萬人民幣的工資呢！其實呢，那是一個高中生就可以完成的工作。

由此可見，企業軟件項目的關鍵在于需求管理和流程建模，相反，算法和基本功能以及BUG什?的，那是作?商業軟件開發的組件保證的，那一般以外包的形式由 印度這些公司早早做了出來。企業軟件需求最大的困難就是用戶根本不知道自已要幹什?，最常犯的錯誤就是把現有的落後流程要求電腦重複一遍，拿了機關槍，總 是要求上面沒有裝刺刀，還抱怨不比紅纓槍好用。另一個常見的錯誤就是隨著企業項目主管，（職業最低成是電腦科主任，高點就是一二把手了）知識開始豐富後， 總是把有用沒有用，暫時有用或永遠沒有用的需求要項目組一一實現，反正，每條要求都是振振有詞，仿佛都是非立刻實現不可的。作?承包方的人員是沒有辦法與 之爭業務上有沒有用的，（誰是這一行業的專家啊？人家已經是霸主了才上軟件，你算那們子專家啊？），但如果真的一一跟著他的點子走，就算累死了，這個項目 也是永遠沒有法子完成的。而在商業需求明確的商業軟件開發中就不會碰上這種事情。

這時侯需要對客戶的需求進行分級管理，簡單地說，把需求分成五級：urgent(必須立刻優先實現)，necessary(必須實現,但不一定馬上進 行)，needed(需要的，不過沒有也還湊合)，better(現在似乎也可以，但可以更好一點)，useful（總會有用的）。一個需求等級的確認需 要兩個過程，首先是從正面論證它是不是必須的，是不是好得多；然後從反而論證，不要他是不是可以回避的，天會不會塌下來？這樣，一個軟件需求就可以相當定 一個級別。毫無疑問，如果一個項目各項需求驗證下來只是useful的，不但賺不了多少錢，而且，這個項目未必有必要存在；但如果都是urgent的話， 如果不是大幅度加價的話，就叫神仙來做好了。顯然，無論客戶是如何那般的行業專家，他的需求只能是平均地分配在這五個級別，否則就說明他不是專家，（呵 呵，也算是個邏輯陷阱），在實現時，當然就挑urgent&necessary來實現，其余的，升級再說了。

這樣一個項目就有可能最終完成了。