談軟體協作：君子和而不同，小人同而不和

我們知道現在的軟體開發最大的問題就是變化，其實這也不是軟體本身的問題，我更覺得是軟體的特點。因為他不像建築，畫個建築圖，一般不會偏到哪裡去。然而很多需要軟體的人，他可能希望軟體能達到什麼目的，至於具體是什麼樣子，他自己也不知道。大部分都是看到一部分想起一部分，自己也不斷的修正。這也是為什麼最近敏捷大行其道。

我甚至服務過一個客戶，做一個公園系統，為的是送一張免費的VIP卡給業主，最終目的是賣房子。

既然軟體的需求是不固定，也就是不斷變化，所以我們簽合約的時候往往有兩種方式：

1.固定價格

這種就是一開始讓客戶必須把需求定下來，然後估計時間，然後就是報價，我一直不懂這個價格是如何報的，很多就是先去客戶那裡調研一下，其實就是看一下這個客戶好不好蒙，能蒙多少。然後就近可能的往高的報。然後整一份需求說明書，讓客戶簽字，如果客戶改需求，加錢加時間。要不就目前的功能你做了也沒用，雞肋，大部分客戶咬著牙，加吧，誰讓我們給他們分期付款，還付了定金呢，最終不歡而散，兩敗俱傷。

2. 按時間付價格

這種大部分出現在外包的項目中，就是客戶找自己需要的工程師，月付型，一般採用迭代式開發，增量式開發，客戶考察的主要是品質和效率，如果達不到客戶的要求，客戶立即停止。這樣看起來很美，但是效率卻是一個不好衡量的東西，尤其是時間短的項目，很難看到效率，舉個例子，同樣是蓋樓，一個打10米的地基，迅速蓋到了三樓，可是另一個打了30米的地基，為的是蓋30層的高樓，很顯然，10米地基的樓房很快就出現人的眼前。這說明效率有時候有點“亂花漸欲迷人眼”。但這種方式，我們很多人5小時能幹完的，非要8小時幹完，為什麼呢，因為5小時幹完，客戶也不一定提高報價。客戶很難知道什麼是真正的效率，從某種意義上說，抹殺了整個生產力。

兩種方式，看似都有問題，但第二種比第一種對雙方風險稍小。但第二種會抹殺整個行業的創新和積極性。

最近，看《論語》“君子和而不同，小人同而不和”就是說，君子內心所見略同，但其外在表現未必都一樣，比如都為天下謀，有些人出仕做官，有些人則教書育人，這種“不同”可以致“和”；小人雖然嗜好相同，但因為各爭私利，必然互起衝突，這種“同”反而導致了“不和”。

這突然讓我想起軟體項目的合作有何嘗不是如此，很多時候，我們以為有了一份合約就可以，其實合約就是一份擺設。如果都按孔子的這個思想，軟體合約其實就是要完成一件事情，具體要做成什麼樣，價格是否會變化，應該是在過程中不斷協商，不斷合作。如果一開始都說好不變，其實我們自己都知道，一定有一方會吃虧。就像有人說“中國人太多，炸死一半就好了”（此話出自在電梯偶遇某一個看似有文化的中年婦女），我就想難道那一半就一定不包括你？

所以，我們在軟體寫作過程，最好就是想盡一切辦法，讓自己和客戶的合作更緊密一些，合約內容盡量少一些。

胡亂瞎寫，願各位斧正。

註：不希望看到評論只說別人文筆太差，而自己又不願貢獻文章的人。比如，很多專案經理老說別人不行，如果別人都行了，那你就是最不行的，你有別人沒有的東西，這才是你存在的理由。