Caven的博客

把項目交給自由職業(yè)者還是軟件公司？

Caven — Fri, 16 Jan 2015 09:52:36 +0000

當(dāng)您打算開展一個軟件項目的時候，會面臨很多問題和選擇，其中之一就是到底把項目交給軟件公司來做呢？還是外包給軟件開發(fā)自由職業(yè)者？最近跟幾個朋友都討論到這個問題，故寫此文，試圖對二者進行一些對比，給您一個參考。

結(jié)論：軟件公司和個人職業(yè)者，沒有絕對的高下，只是相對來說在某些方面各有優(yōu)勢。因此它們都有自己所適合的場景，總體來說，要根據(jù)您所處的情境來選擇：

1）如果您對價格比較敏感，有較多時間來管理自己的項目，同時項目較簡單，技術(shù)風(fēng)險不高，適合于一個人在短期內(nèi)完成，可以更多地考慮自由職業(yè)者；

2）如果您尋找的是長期穩(wěn)固的合作伙伴，而且很可能在將來擴充您的團隊；或者項目存在一定的技術(shù)風(fēng)險，工作量較多較復(fù)雜，需要團隊配合才能完成；又或者是您本人不太擅長管理軟件開發(fā)項目，那么找軟件外包公司應(yīng)該是個更好的選擇。

諾懷博客標簽:

企業(yè)信息化建設(shè)的三大誤區(qū)

Caven — Fri, 16 Jan 2015 08:42:35 +0000

最近有一個哥們很郁悶，找我訴苦：“我們現(xiàn)在軟件做得差不多了，但是實施起來難度很大，員工不愿意用，老板的意思是既然要做軟件，那么軟件就能要求員工必須用。軟件如何去迫使員工必須用呢？?”他夾在中間感覺非常為難，不知道該如何回復(fù)老板。這種情形，我一聽就感同身受，完全能夠理解他的處境，為什么？因為這現(xiàn)象在軟件行業(yè)，尤其是企業(yè)信息化的過程中，相當(dāng)常見。

過程一般是這樣：

1. 公司高層上套新系統(tǒng)，員工卻不愿意用；

2. 于是高層推出行政命令強迫員工必須用；

3. 員工依然不配合，當(dāng)被追究時，說軟件不好用；

4. 公司領(lǐng)導(dǎo)找到倒霉的開發(fā)團隊，說你的軟件必須要解決員工不愿意用的問題，這是你軟件的問題；

大家來評評理，到底是哪里有問題？

之所以會出現(xiàn)這樣的事情，究其原因有很多，然而主要的問題還在于大家對“企業(yè)信息化”的認識不夠到位，缺乏正確的方式方法。為了幫助大家少走些彎路，我這里總結(jié)了下企業(yè)信息化過程中常見的三大誤區(qū)：

誤區(qū)一：所有的問題都是軟件的問題；

這里我必須替勤勞實在的技術(shù)人員說句話，企業(yè)信息化的問題，還真不是僅用軟件就能解決的，這里面還有很多其它的問題，譬如企業(yè)文化的問題、變革的問題。為什么這樣說？因為軟件是為企業(yè)業(yè)務(wù)服務(wù)的，上新系統(tǒng)時，常常會對企業(yè)現(xiàn)有的業(yè)務(wù)流程、工作方式等帶來改變（通常都是企業(yè)管理層想對它們進行一些升級或優(yōu) 化），而這些改變常常會對一線人員帶來一些負擔(dān)（有時候僅僅是讓他做出改變就已經(jīng)是負擔(dān)了）。如何讓基層員工主動來配合或適應(yīng)這些變化，如何消除或降低基層對變革的抵觸，是軟件的問題么？

誤區(qū)二：基層用戶只需要拿到軟件去用即可；

這里我是替企業(yè)基層說句話，請不要忽略他們的需求，他們在工作中也會遇到很多問題，也需要有人能幫他們解決問題，而不是簡單地由外面來強加一套程序要求他用（通常這會增加他的工作內(nèi)容）。很多時候，實際的工作情況并不是遠離一線的企業(yè)高層所想象的那樣，更不是另一家公司的程序員所能理解的。如果他們對一線工作不理解，同時又沒有讓一線人員參與到整個程序的開發(fā)過程中，做出來的東西適用么？

誤區(qū)三：可以靠行政手段實現(xiàn)信息化；

這是長期處于權(quán)力中心的人，最愿意相信的假象。在企業(yè)里，公司高層傾向于認為通過行政命令，以及規(guī)章制度的要求，可以迫使大家接受信息化帶來的改變。然而不要忘了中國的老話“上有政策，下有對策”，在聰明的中國人面前，要讓他接受自己所不認可的東西，那是非常困難的。要么是做做表面功夫應(yīng)付下，要么就是暫時被動接受了，以后你沒盯這么緊了再反彈。無論是哪種情況，都讓企業(yè)無法充分利用信息化帶來的優(yōu)勢，甚至是根本達不到上軟件系統(tǒng)的初衷。

那么問題來了，既然這樣行不通，我們應(yīng)該如何做才好？出路在何方？

其實，引入軟件系統(tǒng)跟引入一套新的管理流程一樣，涉及到企業(yè)變革管理的問題。企業(yè)領(lǐng)導(dǎo)層最好平時就打造一種精益求精、擁抱變化的企業(yè)文化。并且在上系統(tǒng)前，內(nèi)部充分溝通，讓大家了解到上這套系統(tǒng)對公司和他個人的意義，從意識上先讓員工接受這個變化并為之做好準備。同時，還要在系統(tǒng)開發(fā)的過程中，盡量讓員工代表多參與，使軟件能夠體現(xiàn)他們的需要，解決他們的問題（而不僅僅是企業(yè)領(lǐng)導(dǎo)層的），甚至是派員工代表跟軟件團隊一起工作。這樣在系統(tǒng)上線后，要求大家使用時，阻力應(yīng)該會小些。如果依然遇到員工抵觸，不要簡單歸結(jié)為是這個員工的問題（行政處罰）或者是軟件的問題。要深入溝通了解下他為什么不愿意用，到底是什么阻礙了他？是個人的問題就提供幫助（如進行培訓(xùn)），是軟件的問題就要求改正。另外，軟件系統(tǒng)也可以分為幾期逐步完善，小步快跑，不要試圖一步到位，這不但能降低實施的壓力，而且也符合“需求漸進明細”的規(guī)律。

希望這幾點認知，能幫助大家更加順利地實施企業(yè)信息化。?

諾懷博客標簽:

軟件開發(fā)項目管理-凡事預(yù)則立

Caven — Fri, 16 Jan 2015 08:38:42 +0000

近日，某軟件開發(fā)項目完成結(jié)項，在進行總結(jié)時，項目經(jīng)理提出了不少問題。其中大多數(shù)都是些常見的癥狀，并不是這個項目所獨有的，也不是以前沒見過的。于是問題產(chǎn)生了，為什么這些教訓(xùn)在不同的項目中?反復(fù)?發(fā)生？能不能采取些措施，來規(guī)避它們或降低這些問題的負面影響呢？經(jīng)過這么一思考，我發(fā)現(xiàn)在軟件開發(fā)項目的實施過程中，還真有不少問題是可以提前預(yù)見到的，與其被動等待事情發(fā)生后再去應(yīng)對，不如及早采取方案來控制它。正應(yīng)了中國人的一句古話：“凡事預(yù)則立”。

下面對這幾條問題及其對策，簡單進行下分享：

問題1：在項目過程中，客戶對平臺操作不熟，很多問題都來找團隊指導(dǎo)、答疑；而這些導(dǎo)致工作時常中斷，占用不少時間，卻又不在最初的工作范圍中，沒有報價；
問題2：客戶經(jīng)常出差，而且不通知團隊，項目組經(jīng)常聯(lián)系不上客戶；問題得不到及時反饋，影響項目進展；
問題3：客戶看到系統(tǒng)后，在測試過程中提出很多不在最初需求內(nèi)的改動；而這些改動所對應(yīng)的工作量又在最初沒有報價，同時客戶追加預(yù)算又很困難；
問題4：幫助客戶部署時，遇到很多問題，比如:服務(wù)器里面沒有安裝任何軟件，服務(wù)器太差，時不時的死機；導(dǎo)致工作量大大超出最初預(yù)期；

如果是做軟件的同行，這些問題看著都不陌生吧？是不是每個項目都有可能遇到？如果一件事情我們能預(yù)見到它很可能發(fā)生，而且又會對項目帶來不利影響，那么我們就應(yīng)該對其進行風(fēng)險管理，不是么？其實解決這幾個問題的對策也都很簡單，就是提前預(yù)案下而已：

對策1：既然每個客戶在項目過程中，都需要或多或少的技術(shù)支持；那么制定項目計劃時，團隊直接跟客戶溝通所需要的支持內(nèi)容；或者根據(jù)客戶背景來判斷所需支持程度的大??；并且把這部分工作內(nèi)容放入計劃中；
對策2：每個項目都需要客戶的參與和配合，都是在跟客戶互動的過程中完成的。那么，團隊能否一開始就跟客戶確認好其參與方式和參與程度？或者把項目需要客戶參與的地方先明確告知？如果開始有這么一個溝通，就能發(fā)現(xiàn)“客戶可能會經(jīng)常出差”，這樣就可以在項目安排上做出對應(yīng)的調(diào)整。譬如項目早期需求溝通更深入一些，減少執(zhí)行過程中對客戶的依賴；或者把工期拉長以配合客戶行程，etc.；
對策3：需求的變化是必然的，目前為止，還沒有聽說過需求不發(fā)生變化的軟件項目。而且，在客戶看到系統(tǒng)的那一刻，會產(chǎn)生幾十個上百個新的想法，都很正常。問題在于，這些變化可能導(dǎo)致工期延長、費用增加的事實，雙方如何應(yīng)對？如果一開始大家沒說清楚，當(dāng)變更發(fā)生時，各持一詞，就很容易演變成討價還價和扯皮，如果一開始雙方達成了共識，那么屆時都有準備，按照流程處理即可，皆大歡喜；這只需要在項目啟動之初，雙方溝通確認下需求變更處理流程，“預(yù)”一下；
對策4：大多數(shù)軟件項目，都需要幫助客戶部署；而每個部署，都必然涉及到部署環(huán)境和服務(wù)器配置的問題；團隊事先向客戶了解下其部署環(huán)境和服務(wù)器配置，再進行相應(yīng)的工作量估計，自然可以規(guī)避；

總之，這些問題不難提前想到，對策也并不復(fù)雜，只需要項目經(jīng)理們多“預(yù)一預(yù)”就可以規(guī)避不少風(fēng)險。項目上諸如此類的問題有不少，身為項目經(jīng)理，除了關(guān)注項目的任務(wù)，還應(yīng)該多注意下跟客戶配合互動這個層面。雖然每個項目都存在其獨特性，但項目中經(jīng)常遇到的一些問題也是有共性的，好的項目管理就是要能事先預(yù)見到這些容易出現(xiàn)的“坑”，并準備好對應(yīng)的"蘿卜"，才不至于臨陣磨槍。

諾懷博客標簽:

如何確?？蛻鬌emo的成功

Caven — Fri, 16 Jan 2015 08:26:47 +0000

前兩天有個項目，客戶要求在3月17號前要完成第一期工作，因為他在3月17號安排了一個重要的演示（Demonstrate），團隊根據(jù)客戶的要求，制定了在3月14號給客戶提交版本的計劃。3月14號當(dāng)天，由于工作整合時發(fā)現(xiàn)有較多問題，未能成功交付，于是整個團隊在3月15號（周六）主動加了一天班，終于在3月15號完成提交。3月17號（周一）來上班時，發(fā)現(xiàn)客戶對交付物進行了驗收，并且提了一些需要修改的Bug，要求盡量在當(dāng)天改完。當(dāng)天經(jīng)過團隊的努力，修改好了客戶反饋的Bug，并且再次提交。晚上，客戶發(fā)郵件說程序無法工作，未能成功演示，郵件中充斥著不滿的情緒。為什么團隊成員的努力工作，卻未能換來客戶的肯定和滿意？到底是哪里出了問題？如何才能避免這樣的場景呢？

仔細分析下這個案例，不難發(fā)現(xiàn)下面這幾個事實：

A - 項目交付之后，客戶總是需要一些時間來驗收，團隊也需要一些時間來修改Bug，程序才能達到穩(wěn)定狀態(tài)；

B - 總是會出現(xiàn)些預(yù)料之外的事情，譬如整合時的問題，譬如提交后客戶無法運行的問題等，這些預(yù)料之外的事件會消耗掉不少時間和精力；

C - 上述兩個問題是可以提前預(yù)見的，因而可提前規(guī)劃對策，這樣會將其負面影響降到最低；

對此，總結(jié)出來的經(jīng)驗教訓(xùn)是：

團隊向客戶提交的日期（Deliver Day）比客戶的演示日期（Demo Day），至少要提前三個工作日；這段時間將用于客戶驗收測試、修改Bug、配置和部署演示環(huán)境、預(yù)演、以及應(yīng)對預(yù)料外的事情；
如果中途情況發(fā)生變化，無法準時提交，需要盡早更新計劃，并且及時跟客戶協(xié)商對策；譬如Cut掉一兩個功能、加班趕工、或是延后演示日期等；
建議客戶提前一天進行一場預(yù)演；
1. 調(diào)試好演示時要使用的環(huán)境和設(shè)備；
2. 準備好演示時要用到的數(shù)據(jù)；
3. 過一遍演示時將展示的功能；
提前獲取客戶的演示清單，包括將演示的功能列表、操作順序等；團隊內(nèi)部根據(jù)演示清單測試，盡量保持與客戶操作的一致性；
提前了解演示現(xiàn)場的環(huán)境，包括網(wǎng)絡(luò)環(huán)境、設(shè)備、操作系統(tǒng)、瀏覽器等；

諾懷博客標簽:

軟件開發(fā)金科玉律之-不要重復(fù)發(fā)明輪子!

Caven — Thu, 17 Apr 2014 08:29:05 +0000

?? ? 以前有個小朋友，特別有好奇心，也喜歡動手搗騰。有一天，他做出來了一個圓圓的，會滾動的東西，感到特別興奮，到處去向別人展示自己的"新發(fā)明"。結(jié)果他發(fā)現(xiàn)別人一點都不稀奇，原來這個東西叫做“輪子”，早在幾千年前就有了，現(xiàn)在已經(jīng)發(fā)展出了上百種的不同規(guī)格、材質(zhì)、樣式，自己的這個相比之下太不完善了，根本不能算是什么發(fā)明。這個小朋友，現(xiàn)在就藏在我們的心里，尤其是經(jīng)驗不夠豐富的程序員身上。

??? 幾年前我曾經(jīng)做過一個項目，經(jīng)過長時間的掙扎之后，項目依然失敗了。主要的原因之一，就是我們重復(fù)發(fā)明了太多的輪子。事情是這樣的，時任項目核心開發(fā)人員的同事很有鉆研精神，也相當(dāng)自信，當(dāng)時客戶提出的一些基本功能，譬如用戶管理、輸入驗證、內(nèi)容管理等，雖然市面上隨處可見現(xiàn)成的模塊和控件，可他總是覺得那些做得不夠好，說不如自己重新做一個方便，而且重新做更能符合客戶的特殊需求。我當(dāng)時作為PM，雖然對此略有質(zhì)疑，但看他自信滿滿很有激情，而項目時間也很寬松，就同意了。后來僅僅輸入驗證這個功能就推翻重來了三次，最終還是選用了一個現(xiàn)成的控件直接用，因為他做出來的太不具備通用性，十分難以維護；同時，用戶管理模塊也做得千瘡百孔，極不穩(wěn)定，出現(xiàn)了很多Bug和考慮不周全的地方，最后也不得不去找現(xiàn)有的成熟的組件替換。結(jié)果，這些“重復(fù)發(fā)明輪子”的開發(fā)工作，不但耗費了大量的時間、金錢和精力，而且也沒能發(fā)揮預(yù) 期的效用。事實證明，現(xiàn)成的控件“輪子”（開源的或收費的），經(jīng)歷過時間的檢測和眾人的改進，總比自己重新?lián)v騰出來的要更成熟、更穩(wěn)定，同時也更加省事、好用。我們在這個項目中花費了這么多時間、金錢、心血，終于證明了“不要重復(fù)發(fā)明輪子”這句話是很有道理的，這個慘痛的教訓(xùn)讓我迄今記憶猶新。

??? 雖然此事已經(jīng)時過境遷，但近些年來我發(fā)現(xiàn)有很多人都在“重復(fù)發(fā)明輪子”，尤其是在我們軟件開發(fā)這個圈子里面，年輕的小伙伴們充滿了發(fā)明輪子的欲望和激情，就好像那個可愛的小朋友一樣。因為他們覺得這樣做會讓自己學(xué)到很多東西，如果做出來了也會很有成就感。確實，成長和成就的確是他們所需要的東西?？扇绻闶?客戶，你會愿意為此承擔(dān)更高的費用和風(fēng)險么？如果你是項目經(jīng)理呢，在成員練手跟項目成功交付之間，哪個更重要？

??? 我覺得如果出于練兵的目的，重新?lián)v騰一個輪子出來當(dāng)然是個好方法，就好像比賽開始前反復(fù)練習(xí)投籃一樣正常。可如果你已經(jīng)上戰(zhàn)場了，已經(jīng)開始比賽了，已經(jīng)去幫客戶做項目了，這時候才來練習(xí)是非常不合適的。因為你很可能會因此而輸?shù)舯荣悺G掉客戶，而且因為你極其不專業(yè)的表現(xiàn)，會影響你的職業(yè)生涯。所以在公司里面，應(yīng) 該明確區(qū)分什么時候是練兵，什么時候是上陣，一定要杜絕上陣后才練兵的不專業(yè)表現(xiàn)。換句話說，工作中不要重復(fù)發(fā)明輪子，要練習(xí)投籃下場后自己慢慢練去，不要輕易浪費在賽場上的出手機會，just beprofessional.

諾懷博客標簽:

誠信：八千美金的一堂課

Caven — Fri, 21 Mar 2014 05:38:50 +0000

?? 最近丟了個價值8000美金的項目，剛開始不到一周就被客戶叫停，以前從未發(fā)生這樣的事情，被上了非常昂貴的一堂課。為了讓這堂成本8000美金的課程價值最大化，我覺得有必要把從中得到的經(jīng)驗教訓(xùn)分享出來，希望能警醒更多的項目經(jīng)理，幫助更多的人少走彎路。

?? 事情是這樣的：上周五有一個項目啟動了，這是個老客戶轉(zhuǎn)交過來的新項目，要得比較急，因而客戶也特別關(guān)注項目的進度。通過最初的溝通，我們應(yīng)允客戶每天給他發(fā)日報反饋項目進展，但由于人員受其它項目影響，未能及時到位，直到本周三項目都未能投入多少時間，因而項目經(jīng)理也一直未發(fā)日報。到了周四，客戶要求Skype溝通，并且在溝通中又特別強調(diào)了需要日報反饋項目進度的問題，同時團隊也答應(yīng)周四晚上向客戶提交2個功能點。而到了周四的晚上，客戶卻發(fā)郵件來強烈表示不滿，要中斷項目，原因是團隊當(dāng)天并沒有按照約定發(fā)報告給他反饋項目進展，承諾的2個功能也未能如期交付。更要命的是，與此同時團隊沒有給客戶任何說明和解釋。客戶說，他對這個項目的進展非常非常擔(dān)心，對整個團隊能否按時交付項目完全沒有任何信心。而團隊這邊卻認為雖然前期投入較少，但通過后面的努力，項目總體上是能夠按時完成的，只是當(dāng)天因為一些緊急問題影響了功能的提交和報告的發(fā)送，本打算第二天補上的，還未來得及補上，客戶就發(fā)飆了，似乎有點太小題大做了。這個案例里面存在哪些問題？大家可以慢慢分析，我想就把其中的誠信問題拿出來說下。

??? 所謂誠信，簡單點理解就是說到做到，答應(yīng)的事情要兌現(xiàn)。往小里說這是獲得客戶信任的基礎(chǔ)，往大了說這是做人的根本。譬如一個人你跟他合作，他答應(yīng)了你的事情總是跳票，不兌現(xiàn)，你還會選擇繼續(xù)跟他合作么？換位思考下，這個事情就是這么個簡單的道理。你答應(yīng)了客戶一些事情，雖然事情較小，但你若不兌現(xiàn)，就會很快失去客戶有限的耐心和信任。

??? 既然誠信如此重要，那我們要如何才能做到誠信？從這個事情中，我想能吸取如下教訓(xùn)：

??? 慎重承諾：一個事情如果做不到，就不要答應(yīng)，寧肯拒絕；答應(yīng)了卻做不到，兌不了現(xiàn)，這比你不答應(yīng)或少承諾一些，傷害力要大得多；
??? 如果答應(yīng)了，就要想盡辦法去兌現(xiàn)，盡自己最大的努力；
??? 如果盡了最大的努力，依然是無法做到，此時至少應(yīng)該及時反饋，第一時間告訴對方；并主動向?qū)Ψ奖磉_你的歉意，解釋你無法做到的原因；這樣能來得及再想其它辦法，也更能獲得諒解；

??? 總之，千萬不要像我們前面例子中這個團隊那樣，答應(yīng)了做不到的事情，并且沒做到時也沒有主動反饋和解釋，這樣是很糟糕的處理。中國古人講修齊治平，說明做項目跟做人，道理都是相通的。一個公司因為一次不誠信行為，會損失一個項目或一個客戶，如果這樣的行為在公司里面擴散開來呢？或者長期積累起來呢？一個人因為一次不誠信行為，會損失一個機會或一個朋友，如果這樣的行為在他周圍擴散開來呢？或者在他身上持續(xù)累積起來呢？所以誠信無小事，要從自我做起，要從點滴做起。

諾懷博客標簽:

從某軟件開發(fā)項目一期工作中學(xué)到的經(jīng)驗

Caven — Fri, 21 Mar 2014 03:45:58 +0000

1. 明確范圍

如果說要把整個項目（假設(shè)持續(xù)2個月，分為4次迭代）的范圍，在一開始就明確下來，對我們、對客戶都很困難，因而這個期望不太現(xiàn)實；更可行的辦法是把范圍的明確，也拆分成更小的單位，譬如按照每個迭代（每兩周）來明確；我們雙方只要保證，對這兩周要提交的內(nèi)容，有明確的共同認識即可；然后不斷循環(huán)；
明確下來的范圍，要有個Task List或者Plan來作為以后判斷是否發(fā)生范圍改變的依據(jù)；

2. 范圍變更

如上所述，如果每兩周一個迭代，每次迭代都有明確的Task List或Plan；那么在這個過程中，任何不在這個List和Plan中的任務(wù)，都可以視為需求變更、范圍變化；
這種變更，需要在客戶剛提出來時，就進行評估，明確告訴客戶這個改變所需要的額外時間，必要時，要協(xié)商延后當(dāng)前版本的提交日期Timeline；
同時，在平時要注意把這類小變更記錄起來，免得以后說不清楚哪些是變更，哪些是初始的要求；

3. 提交版本

如果跟客戶約定在每個迭代結(jié)束時提交版本，那就相當(dāng)于每次提交都跟客戶商量了一個明確的提交日期；這樣就不會太被動；當(dāng)然如果客戶覺得這個頻率有問題，也可以改為每周提交一次或者每周兩次提交；無論是哪種情況，都可以事先商量好，做好對應(yīng)的計劃和時間安排；這樣就可以避免倉促提交的現(xiàn)象；
提交版本之前，內(nèi)部一定要留些時間，譬如1天2天做為內(nèi)部測試和修改Bug的時間；必須內(nèi)部通過了才提交給客戶；這個是最基本的質(zhì)量保證流程；

4. 質(zhì)量

開發(fā)人員自測是最基礎(chǔ)的；如果測試人員得到的版本是不可測的，一看就有很多明顯的Bug；通常會要求測試人員直接打回給開發(fā)人員重測；只有過了自己這一關(guān)，下一個環(huán)節(jié)的工作才有意義；
如果開發(fā)人員的自測實在不知道如何才能改進，那么可以讓測試人員跟其結(jié)對，一起測試；這樣就能學(xué)到一些測試人員的測試方法和技術(shù)；幫助開發(fā)人員提高自測水平，在后期也可以節(jié)省整個團隊的時間；
對于經(jīng)常出現(xiàn)的Bug，開發(fā)人員一定要進行分析總結(jié)，看看哪類Bug是自己最常犯的錯誤，得到經(jīng)驗以后采取措施避免；

諾懷博客標簽:

固定總價合同 vs 工料合同

Caven — Fri, 20 Dec 2013 04:00:58 +0000

??? 今天下午公司幾個同事一起討論了下如何跟客戶的合作模式以及如何選用合同類型的問題，我也有不少思考，就借機整理下自己在這方面的看法，希望能拋磚引玉。

??? 在項目實踐中，我們跟客戶有很多種不同的合作方式，這些不同的合作方式通常也對應(yīng)著不同的合同類型。無論起什么名字，采取什么形式，從根本上來，就是兩種合同類型，一種是開口合同，一種是閉口的合同。在我們公司，開口合同以單價合同為代表（PMP中叫成本補償合同、工料合同），閉口合同以固定總價合同為典型。我想總結(jié)下這兩種合同各自的特點和適用場景。

??? 要回答的問題是：當(dāng)一個客戶或項目過來時，應(yīng)該如何選擇合同類型？最簡單合理的答案，就是看采用哪種類型的合同對項目最有利。那該如何判斷哪種合同對項目最有利呢？這就不得不先搞清楚這兩種合同類型各自的特點，要先對他們做個對比，然后再根據(jù)項目本身的特點去選擇。

項目	固定總價合同	單價合同
總價格	總價明確	單價明確，總價浮動
單位價格	相對較高	相對較低
啟動周期	前期準備，長	立刻啟動，短
項目范圍	非常明確	較為模糊
響應(yīng)變化	嚴格控制，較弱	靈活應(yīng)變，很強
發(fā)包方風(fēng)險	較低	較高
項目規(guī)模	中、小	大、中、小
投資控制	總預(yù)算明確，強	月預(yù)算明確，弱
發(fā)包方要求	需要明確需求，高	不需詳盡文檔，低

??? 顧名思義，固定總價合同的特點是有個明確的總價格。譬如雙方達成一致，說這個項目總價是100萬，這個價格會事先定好，寫在合同中，一般不發(fā)生變化。通常伴隨這個價格的，還有工期、質(zhì)量等方面的明確要求。說到這，有人就會產(chǎn)生疑問了，你這個100萬的價格，是如何給出的呢？這是個好問題。對固定總價項目來說，要給出一個明確的總報價，是有前提的。它最大的前提就是項目（產(chǎn)品或服務(wù)）的范圍能夠事先清晰地界定，就是說要做哪些事情，不做哪些事情，要提供哪些東西，不提供哪些東西，這些都要事先說清楚。舉個最簡單的例子，拿軟件項目來說，系統(tǒng)要不要跨平臺，是否需要部署和培訓(xùn)服務(wù)，要支持哪些瀏覽器，甚至是一個界面應(yīng)該如何布局，這些都會對工作量和價格產(chǎn)生不同的影響，事先不說清楚就難以確定總價格。如果范圍不先界定清楚就把價格定下來了，這非常容易造成后期的扯皮，對一個任務(wù)雙方往往各持一詞，一方說這個工作是不包含在最初報價中的因而要額外收費，另一方說這個是固定總價合同，要包干，所有的任務(wù)都不會額外付費，如此這般糾纏不清，不利于項目順利開展。由此可見，在固定總價合同中，是承包方承擔(dān)了較多的風(fēng)險，需求變更，意外事件等都會導(dǎo)致他們成本增加，但收入?yún)s是事先固定的。承包方也不傻，為了應(yīng)對這個風(fēng)險，通常會在固定總價合同中，增加一筆風(fēng)險儲備金，這也容易理解，因為所有的項目都或多或少存在一些不確定性，總有一些意料之外的事情發(fā)生。而人們也都能接受給承擔(dān)更高的風(fēng)險一方以更高的回報。這一來，如果換算成單價的話，固定總價合同的平均單價，通常會比較高，這是它的另一個特點。伴隨著固定總價格而來的，還有一個特性，就是對變更的抗拒，因為對于承包方來說，變更就意味著更多的工作，就意味著成本的增加，意味著風(fēng)險。所以通常在固定總價模式下，承包方會對變更有一種天然的抵制，嚴格地控制變更，即便不得不接受變更，也要走一個復(fù)雜的流程，先對變更的影響進行仔細的評估，再談清楚費用和工期的變化，待互相確認達成一致后才會去處理。這樣的一個過程往往是比較耗時的，而且也會有不少討價還價在其中，幾輪之后，最終是合同雙方都會希望盡量減少變更。

?? 總之，采用固定總價合同的項目，基本上圍繞著項目范圍能夠在事先被清晰定義這一假設(shè)進行，這導(dǎo)致前期準備工作相對較多，項目啟動周期長。價格的固定也導(dǎo)致賣方承擔(dān)風(fēng)險多，因而單價較貴。并且在合同執(zhí)行過程中對變更比較抗拒，可能無法靈活應(yīng)對變化。最大的好處是對投資和成本控制有利，能夠事先確定預(yù)算。

??? 遺憾的是，世事無常，常見的情況恰恰是很多事情都無法提前預(yù)料，人們的預(yù)知能力非常有限，越長遠的未來，現(xiàn)在能夠預(yù)見的就越少。所以項目規(guī)模越大，持續(xù)時間越長，不確定性就越高，就越難以在一開始就把范圍清晰界定，變更發(fā)生的可能性也越大。越是這種類型的項目，在使用固定總價合作模式時，越會遇到更多的問題。在這種情況下，開口合同就正式出場了。因為它的核心思想是根據(jù)工作量來計費，發(fā)生了多少工作就付多少費用，不管持續(xù)時間長短，也不管項目范圍是否清晰，也不管變更發(fā)生得有多頻繁，只要工作發(fā)生了就算數(shù)。這種合作模式的好處是靈活性非常大，只要雙方對工作量單價達成共識，可以很快啟動項目，不需要一個漫長的前期準備過程，即便項目范圍很不明確，也可以先開始做，邊做邊明確。同時，因為按照實際發(fā)生的工作計費，這種模式對任何變更都是包容的，發(fā)包方可以隨時變更工作內(nèi)容，這也意味著承包方的風(fēng)險較低，因而在資源單價上面，會比固定總價合同更加優(yōu)惠。可惜魚和熊掌不可兼得，開口合同在帶來這些優(yōu)勢的同時，也帶來了一些風(fēng)險，那就是無法在項目初期明確總成本，也難以精確評估項目期限，這對于預(yù)算驅(qū)動型、凡事都要提前明確下來的公司來說，往往是一個大問題。總之，這兩種類型的合同，各有各的特點，各自適用于不同的場景，并無絕對的優(yōu)劣。

??? 最后，回到我們最初的問題上去，對一個項目，應(yīng)該如何判斷它適用哪種合同類型呢？個人認為首要的考慮要素是看它能夠明確的東西有多少，或者反過來看它的不確定性有多高。不確定性越高的，可能用開口合同就越合適。反之，確定性越高的，用固定總價合同就更可靠。在實踐中，雙方的信任度也會對合同模式的選擇產(chǎn)生較大影響，在沒有建立起信任的時候，發(fā)包方往往會傾向于固定總價，在信任度較高的時候，更易于采取開口合同。

??? 以上淺見，歡迎大家點評。值得一提的是，這些認知主要來自軟件開發(fā)這個領(lǐng)域的體會，可能其它領(lǐng)域的情況并非如此。

諾懷博客標簽:

總價格

開口協(xié)議