企業業務軟體工程專案和商業軟體產品專案上專案需求管理的不同(轉)

ger8發表於2007-08-15
企業業務軟體工程專案和商業軟體產品專案上專案無論是需求重點,實現方式,專案管理等方面都有極大不同。現在的軟體工程有關研究並沒有關注此中的區別,實際上,其中絕大部分還集中在較簡單的產品專案上。對於需求變動要大得多的企業軟體專案來說,對需求進行分級管理是非常必要的,也是生死悠關的。


企業化軟體專案和商業軟體的(承包開發)還是有很大的不一樣的,最大的區別就在於專案需求的重點不一樣,以致於這兩種同樣稱為軟體工程,就其專案過程管理是幾乎完全不一樣的。商業軟體的開發最大的特點是就是基本功能非常明確,只在細節上有多種選擇,所以商業軟體開發的專案管理重在原始碼管理和演算法的最佳化,以及測試嚴格,就測試要求的強度上單純軟體程式碼的質量來說,要強於企業資訊化的軟體工程專案。

企業資訊工程專案一般來源於企業某一特定的業務軟體需求,象要上一個倉庫管理系統,從進貨到定期定標出倉平衡責任追蹤等;或者是一個生產流程配料系統,象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來實現,其餘的,升級再說了。

這樣一個專案就有可能最終完成了。
[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-960331/,如需轉載,請註明出處,否則將追究法律責任。

相關文章