無數(shù)的教訓，為什么要做一個好的甲方？

作者：張海龍，CODING CEO，技術創(chuàng)業(yè)者。CMU計算機碩士，原 Oracle 高級軟件工程師。2010年回國創(chuàng)業(yè)，曾聯(lián)合創(chuàng)辦開源中國社區(qū)，2014年創(chuàng)辦 CODING。

這個世界上有很多的甲方也有很多的乙方，我們在生活和工作中，不是充當甲方角色就是充當乙方角色，往往兩個角色交替著來?？雌饋恚追浇o錢，在交易中應該是主導地位，那為啥軟件外包領域的甲方經(jīng)常在項目交付的過程中狼狽不堪？

我平時常常充當?shù)谌?，看了形形色色的甲方和乙方，也算是看透了：軟件開發(fā)項目要成功，更多的取決于甲方，取決于甲方的能力，態(tài)度，還有期望。項目換乙方不難，但是換甲方，基本就死了。我們常見，公司換一任領導，之前沒完工的項目黃掉的可能性極高。所以，做一個好的甲方很重要，我們來談談為什么，以及如何做一個好的甲方。

沒有人知道你在想什么

這個世界之所以有那么多矛盾，就是因為我們的思想是不透明的（是不是想起了三體人？），沒有人知道你在想什么！你找人幫你做軟件開發(fā)，你得明確的告訴乙方你想做什么，軟件的使用場景是什么，解決什么問題。你在你的領域混了很多年，你覺得有些問題很顯然，但是乙方?jīng)]有。你覺得理所當然的問題，乙方可能完全沒有聽說過。所以，作為甲方，你應該不厭其煩，盡可能詳細的說明白你的需求。很多軟件項目做出來效果不理想，追根究底都是甲方一開始沒說清楚。你不能覺得你的需求很常見，很簡單，所以乙方應該理所當然的做出你想要的東西。如果你要的軟件真的這么常見，那你就不用定制開發(fā)了，直接買現(xiàn)成的。每個需求都是獨特的，所以請不要用這樣的語言來描述需求“做一個跟 xxx 軟件差不多的就行了”。你說你想要一輛車，乙方好不容易做出來了，結(jié)果你說其實你想要的是四驅(qū)的，座椅加熱的，還得是敞篷的。這樣的結(jié)局只有一個，就是加錢，延期，否則乙方不干，但是你不爽，埋下了不歡而散的種子。

由于國內(nèi)的甲方大部分不夠成熟，所以很多國內(nèi)的開發(fā)者和外包團隊都傾向于接國外的單子，包括香港和臺灣的。我參與的海外項目，無一例外，都是非常詳細的需求文檔，并且對接的人非常耐心的跟乙方解釋業(yè)務邏輯。更重要的是，甲方非常清楚，他的責任在哪里。在出現(xiàn)問題的時候，他會判斷這個問題是誰的原因，不會把所有責任往乙方身上推。這是我們值得學習的地方，也是我經(jīng)常跟甲方講的需要改進的地方。

一分價錢，一分貨

大家都知道買東西是一分錢一分貨，憑啥到了軟件開發(fā)就不是了呢？憑啥要求乙方給你免費干活呢？有些甲方意識不到軟件的價值，因為看不見摸不著。所以才有一些廠商把軟件裝到服務器內(nèi)再賣高價的情況，因為服務器是實實在在存在的，掏錢就很樂意。顯然，這是不對的。定制開發(fā)軟件的價值就是人工，雖然很多時候計費是按項目收，但實際上也是按人工時間算的，跟裝修一樣。刷墻看起來是按平米收費的，但實際上也是折算成刷這么多面積的人工來算的。所以你裝修的時候刷墻刷完了發(fā)現(xiàn)顏色不滿意，重刷，不得再給錢么？任何功能的開發(fā)，調(diào)整都是有成本的，你想在有限的預算內(nèi)做很多的功能，那你必須接受的事實就是做的比較粗糙，或者你得接受周期拉長，等乙方安排空閑時間幫你慢慢做。

我記得有一個理論是餐館理論“好吃，便宜，服務好”這三點不可兼得。很有道理，幾乎所有的餐館都不可能兼顧這三點，假如有，那一定會很多人去吃，排隊排死，自然服務也就不好了。這條理論放到其他行業(yè)也一樣，你怎么可能要求軟件開發(fā)做到“質(zhì)量好，便宜，交付快”呢？

我是甲方，我是爺？

現(xiàn)實中的交易有時候會存在一種情況，給錢之前甲方是爺，給錢以后乙方是爺，所以才有了所謂的第三方。軟件開發(fā)由于不是實體產(chǎn)品，很多時候的定義無法完全明確，這樣的情況尤其明顯。但是，一個成功的軟件項目，往往甲乙雙方都不是爺，就是純粹的甲方和乙方，各有各的責任，各有各的義務。乙方作為收錢的一方，對甲方態(tài)度好點，耐心一點是應該的，但是特別要強調(diào)的是：甲方并不凌駕于乙方之上。先來說點不正規(guī)的，還拿裝修說事兒。21世紀都進入第二個十年了，然而我們在裝修的時候不還是得給裝修師傅送香煙么？這是為什么呢？明明給你裝修費用了，為啥還得買煙？這是一種態(tài)度，師傅你工作辛苦了。結(jié)果是，師傅高興了，活兒干的也快了，質(zhì)量也好了，橫平豎直，保證不偷工減料。有的地方看的見，有的地方看不見。軟件開發(fā)也是一樣，你對乙方尊重，乙方自然會有體會，別的不說，同樣的功能，我可以把代碼寫寫好，注釋多寫點以便后期維護。

再來說點正規(guī)的。軟件開發(fā)項目如果完全按照合同來，估計甲方也有很多小尾巴，大家誰都不讓誰事情就很難辦。所以把關系處好是有必要的。還有，軟件項目總有小修小改，如果嚴格按照產(chǎn)品定義來，乙方完全可以不做這些修改，或者要求加錢。但是如果大家相處的好，這些小改動就順手做了。這些都是很現(xiàn)實的狀況。畢竟，軟件開發(fā)還算是門手藝活兒。

這篇文章是寫給甲方看的，所以乙方的問題就不詳細討論了。說一個結(jié)論：如果你覺得乙方不靠譜，或者你給了錢就的聽他的，請盡快更換乙方，后面的錢不要再支付了。雖然前期的投入會讓更換乙方的成本很高，但畢竟比項目爛尾要好。而且多次實踐經(jīng)驗表明，如果乙方前期不靠譜，后期變的靠譜的可能性為零。除非你愿意忍辱負重，湊活把項目做了，否則盡快終止交易，換人。

糾結(jié)還是交付？

所有程序員都知道，程序不可能沒有 Bug，而且 Bug 往往越修越多，然而這在很多甲方那里是不能理解的。我經(jīng)常跟甲方講的是要看主要功能，主要流程是否能走通。除非一些特殊領域的軟件，例如金融，工業(yè)控制等等，其他的軟件，特別是互聯(lián)網(wǎng)領域的，都應該是先上線，然后再完善。我看到的幾乎所有互聯(lián)網(wǎng)產(chǎn)品都是這個路子。所以，在絕大多數(shù)情況下，我們應該選擇盡快交付上線，而不是糾結(jié)于一些小問題。一般的軟件項目都有質(zhì)保期的，所以這些小問題可以在質(zhì)保期慢慢修。這有幾個好處，首先是不用趕時間，做的質(zhì)量會好一些。其次，上線以后有了實際的用戶和運營數(shù)據(jù)，可以更加準確的定位一些問題。

另外就是從心理上來講，大家做一個軟件一般都好幾個月，如果一直拖著不上線勢必會影響士氣。雖然，理論上乙方只是幫你開發(fā)而已，是否上線跟他關系不大，但成就感多少還是有一點的。上線以后，大家修 Bug 的情緒都會不一樣，而且大家都知道已經(jīng)上線了，有問題得及時修?？偠灾?，我建議甲方在交付階段不要糾結(jié)，先交付，然后利用質(zhì)保期完善。

在軟件開發(fā)這件事情上，你可能是甲方，但在你工作的領域你可能是乙方，換位思考一下會讓你成為一個更好的甲方。

最后，如何判斷你是不是一個好的甲方呢？很簡單：乙方是否下次愿意降價 10% 跟你繼續(xù)合作。