地球人都知道，中國的企業(yè)特多，企業(yè)的市場特別大。做好了，不愁吃喝了。但是，很多人都沒想到，企業(yè)實行的是自負(fù)盈虧，用錢是特別謹(jǐn)慎的，不能走高投入高產(chǎn)出的方式，必須走低投入中產(chǎn)出，甚至是走低投入低產(chǎn)出的方式，必須上量。具體到每個公司時，則必須把以前所做的項目中包含的個性化的內(nèi)容歸納出來，提取共性，提高項目中可復(fù)用的程度。終使項目能滿足起百分之七八十的企業(yè)的需求，預(yù)留部分容易修改需求給客戶，滿足客戶所謂個性化需求，定制的愿望。如果根據(jù)提高復(fù)用程度后進(jìn)行的定制項目部門所產(chǎn)生的成本只占應(yīng)收款的40％以下，則證明項目提高復(fù)用程度進(jìn)行得比較成功。提高復(fù)用程度后，又能進(jìn)行大量得定制項目，則項目所產(chǎn)生的累計.利潤，則相當(dāng)客觀。
    但是，要將一定范圍內(nèi)但又包含各式各樣的個性化需求項目做到復(fù)用程度很高，是比較難的。在這里主要從項目管理、公司制度管理的角度進(jìn)行探討，希望達(dá)到拋磚引玉的功效。
    項目復(fù)用很多人在做，但失敗也很多，歸納其原因如下：
1 原因歸納：
1.1 銷售方式上存在的問題：
    現(xiàn)在的模式是：市場的根本不管你開發(fā)的死活，先接了再說，反正有業(yè)績了，也不管能不能做，什么都答應(yīng)下來了，根本不管能否驗收，能否收回所有款額。這樣做好似是：市場出考題，開發(fā)人員做答，客戶作評判。自然，銷售喜歡出怪題，偏題；開發(fā)人員只能根據(jù)考題學(xué)習(xí)新知識，見招拆招，向客戶套答案等等，成本加大；如果客戶關(guān)系到位，要求不嚴(yán)，客戶也沒有現(xiàn)成的答案，一切都過關(guān)；如客戶要求嚴(yán)格，心中有標(biāo)準(zhǔn)答案，會麻煩；
我們是否有能力將現(xiàn)有模式修改為：開發(fā)人員圈定考試范圍，銷售人員出考題，開發(fā)人員隨時作答，客戶作評判，即使是做了，歸納總結(jié)后，出錯的概率會逐漸降低；
1.2 單純以項目為核心的弊端；
    在參與項目的過程中，我發(fā)覺這樣的一種現(xiàn)象：我針對特定的項目提的意見或建議，從通用性的角度去考慮，即使是項目經(jīng)理本人也不會否認(rèn)。但是這些意見和建議是不會落實到特定的項目中。深究其原因，不是項目進(jìn)度緊是覺得沒必要。反正改不改都不會影響項目的驗收。對某個項目的用戶而言，是否存在這種需求是個未知數(shù)。即使存在這種需求，起碼到要到驗收后才發(fā)覺，那是維護(hù)的事情啦，跟項目無關(guān)。反正是抱著僥幸心理，能蒙混過關(guān)行啦。
1.3 開發(fā)人員、部門人員中對用戶的心態(tài)，不是以用戶為本，沒有將用戶當(dāng)人看，至少是把用戶當(dāng)作機(jī)械人。
    這是社會做做項目的一種心態(tài)：從需求分析說明書惡意欺騙，你簽完字東西我給你做了，不符合要求，不要緊，可以做二期嘛，錢我先到手再說!部門的開發(fā)人員或多或少都存在這種想法，我還聽說過，什么操作負(fù)責(zé)一點，繁瑣一點那才好，用戶才會感覺技術(shù)含量高，有成感，用的錢才值。用戶要改的內(nèi)容，是不該，用戶也拿我們沒辦法。
    如果我們的開發(fā)人員天天都使用自己開發(fā)的軟件、方案，那我保證他會“后悔”當(dāng)時的做法。我們現(xiàn)在地做法是，只要能滿足功能上的需求行啦，細(xì)節(jié)問題沒必要考慮啦�，F(xiàn)在，軟件的同質(zhì)化越來越嚴(yán)重，功能都大同小異，區(qū)別的是細(xì)節(jié)的處理的不同。舉個例子，有兩家超市，貨品的檔次、服務(wù)態(tài)度、信譽等都一模一樣，反正是各方面都相同，都能滿足人民購物的需要，但是僅僅是因為一家超市在十字路口，一家離十字路口只有100米的距離。結(jié)果，十字路口的超市比另一家超市的營業(yè)額、利潤多很多。軟件的細(xì)節(jié)相當(dāng)于超市的位置，其重要性可想而知。
    舉個開發(fā)人員“后悔”的例子吧。在某個BS項目中，在后期增加了一個功能，可以讓用戶自行控制權(quán)限點的設(shè)置。當(dāng)時，開發(fā)人員將所有的權(quán)限點列到權(quán)限分配中，當(dāng)然不會去做分類啦。當(dāng)時，我建議，將權(quán)限點進(jìn)行適當(dāng)?shù)姆诸悾�開發(fā)人員覺得沒有這個必要。但在測試過程中，開發(fā)人員必須作配合，進(jìn)行大量的權(quán)限點的分配工作。測試完后，連他自己都覺得有必要改。這是當(dāng)時沒有從用戶的角度考慮問題的后果。
2 改革建議：
2.1 建立一個為使用一定范圍的復(fù)用方案的項目，所有項目都必須以這個項目為核心；
2.1.1 把對復(fù)用項目的貢獻(xiàn)作為項目獎的考核指標(biāo)之一；
    可以在根據(jù)項目調(diào)研確定的需求與通用項目已確定的需要做對比，確定可以從復(fù)用項目提出的內(nèi)容以及項目對復(fù)用項目的貢獻(xiàn)，并確定項目獎的考核指標(biāo)。當(dāng)項目完成后，用一周到兩周的時間，整理出可以對復(fù)用項目貢獻(xiàn)的內(nèi)容。
2.1.2 經(jīng)實踐證明，所作的貢獻(xiàn)能用到后來項目中（3到5個），后來項目應(yīng)根據(jù)所節(jié)約的成本獎勵一定比例到貢獻(xiàn)項目中；
    但其他項目使用復(fù)用項目的模塊節(jié)約了成本時，應(yīng)給予提供者一定的報酬。例如，項目A向通用項目提供了復(fù)用附件，復(fù)用權(quán)限的貢獻(xiàn)。項目B在未使用復(fù)用附件，復(fù)用權(quán)的成本為50人日。但使用了到復(fù)用附件，復(fù)用權(quán)限后降為10人日。那項目B應(yīng)該向項目A提供一定的報酬，40人日中的一個系數(shù)。項目A只能享受3到5個項目的報酬。
2.2 需求的獲得：
    通用項目的需求輪廓的確立應(yīng)該是這樣的：由咨詢工程師根據(jù)以往的項目，盡可能多的施工企業(yè)對業(yè)務(wù)的需求，提出一套盡可能完整的業(yè)務(wù)需求；
2.2.1 項目經(jīng)理：
    根據(jù)具體的項目需求提煉公共部分的需求到復(fù)用項目中，作為項目獎的考核因素之一；
2.2.2 測試、咨詢工程師；
    測試主要是從軟件易用性，人性化的角度提出需求，也可以將在測試過程中遇到的需求整理到復(fù)用項目中；咨詢工程師從業(yè)務(wù)的角度，或者是在實施過程中從用戶中獲得的需求提煉到復(fù)用項目中。獎勵措施，可以是積分制，到年終時，作為年終獎的一部分。
2.2.3 公司一線銷售人員；
    在銷售前期搜集到的需求提煉到復(fù)用項目中，獎勵措施，除需求已在復(fù)用項目中完成時，郵件通知外，可以是積分制，在銷售人員銷售了本方案后進(jìn)行兌現(xiàn)；
2.2.4 用戶需求德搜集；
    鼓勵用戶，特對是老用戶，將自己的需求提出到復(fù)用項目中。這要求每個項目中都必須有一個功能，方便用戶發(fā)送需求道復(fù)用項目中。需求已在復(fù)用項目中完成時，除發(fā)送郵件給用戶外，還應(yīng)發(fā)送到用戶的網(wǎng)絡(luò)管理員及相關(guān)人員中。對工作量不大的修改，應(yīng)免費給用戶進(jìn)行修改；
2.3 項目的建設(shè)
    由于復(fù)用項目建設(shè)周期長，人員流動在所難免，因此必須文檔盡可能規(guī)范，盡可能做到新到員工只通過查閱相關(guān)文檔及代碼，即可快速修改。同時，復(fù)用項目是通過所做的項目所提煉而成的，而不是將幾個項目粘貼在一起的。所以，在提煉項目時，應(yīng)考慮是否與復(fù)用項目融合在一起，復(fù)用項目要拆分時，要怎樣拆分才是迅速的。
2.3.1 先建菜單
    根據(jù)復(fù)用項目的需求，建立相應(yīng)的菜單；
2.3.2 完成頁面
    對已完成的頁面，分兩部分處理，一部分為演示用的，只滿足用戶的基本需求的頁面；另一部分為銷售人員用的，哪些需求是已完成的，哪些需求是可以定制的，用戶必較關(guān)注的需求等，可以作為銷售指導(dǎo)；
2.3.3 未完需求
    連接一個公用頁面，顯示“本需求真正建設(shè)中。。。。。。”，并顯示本需求的作用，對應(yīng)施工單位的業(yè)務(wù)用例；
2.3.4 添加需求頁面
    本頁面主要是方便添加需求；
2.4 公司制度的改變
2.4.1 需求的評審：
    應(yīng)有專人負(fù)責(zé)管理復(fù)用項目中的需求管理，到需求數(shù)量達(dá)到一定程度時或在某個時間范圍內(nèi)（3個月到6個），開會確定需求添加到復(fù)用項目的需求；
2.4.2 項目與復(fù)用項目共享的確定：
    項目經(jīng)理在項目需求確定后，通過和復(fù)用項目需求的對比，然后通過評審確定項目要實現(xiàn)的復(fù)用項目的需求；
2.4.3 項目提煉到復(fù)用項目中：
    項目驗收后，通過項目的總結(jié)，將公用部分提煉到復(fù)用項目中，對提煉到的內(nèi)容作簡單的驗收，并對復(fù)用項目中已完的需求狀態(tài)作修改；
2.4.4 復(fù)用項目的拆分：
    在項目提煉到通用項目后或者是某個子模塊比較成熟時，對復(fù)用項目進(jìn)行拆分，以便其他項目能快速采用；
3 對銷售的引導(dǎo)
    主要有：項目是以復(fù)用項目已確定的模塊或需求為主的，可以適當(dāng)獎勵，我們的目標(biāo)是“質(zhì)量優(yōu)先”，因為這對我們的復(fù)用項目的用貢獻(xiàn)的，而且追求“質(zhì)量優(yōu)先”對成本增加不大。而項目不是以復(fù)用項目已確定的模塊或需求為主的，建議不做，如利潤是相當(dāng)高的，則也是以“成本優(yōu)先”的原則進(jìn)行開發(fā)。