客戶協作 over 合約談判

客戶協作 Customer collaboration OVER 合約談判 contract negotiation

最近有人和我談起他們的專案管理。他是一個專案經理，負責項目的進度跟蹤和與客戶的溝通。他能夠很好的保持客戶關係。他的團隊中有一個年輕的程式員，工作充滿熱情，喜歡思考，喜歡用新技術，也很勇於指出問題。

有一天，這個年輕的程式員在客戶處外勤，跟客戶交流的時候，討論到了系統某一塊兒的功能。年輕的程式員基於他的工作熱情，向客戶提出，如果這麼這麼 做，那可能會給你帶來更好的功能。客戶聽了挺高興，覺得可行，這小夥說的不錯。於是就反映到了專案經理處，說這小夥乾的不賴，表揚表揚。這專案經理聽到客 戶的表揚，也附和的說，他確實很上進，回頭我再給他當眾表揚一下。

專案經理回到了公司，就把這程式員單獨叫來聊了一下，他說，你給客戶提建議，這樣多思考挺好的，不過，咱們給客戶開發，要一單一單的做。你說的那個 功能我早就想到了，但我沒提，主要是考慮這個功能實現起來很容易，我們可以放在下一期，我們引導客戶一下，讓他們提出，我們再把它說的複雜艱巨點，這樣咱 們很容易就能完成任務，下一期時間更充裕，而且還能收更多的錢。所以以後有想法咱們內部討論，先別跟客戶說。程式員點頭稱是。

這樣的事情在很多公司都很常見。他們把客戶視作敵方陣營，利用自己對IT知識優勢瞭解，努力在一些地方上欺瞞和糊弄客戶。

與客戶成為敵對的關係，就難免要進行談判。客戶希望用低廉的價格買到他希望的功能，或者說，在一定價格內實現更多的功能。而公司希望提高價格，降低成本。兩方表面上達成共識，實際上都在暗地博弈，要在邊邊角角上沾點小便宜。而這種博弈結果，就是雙方都不能達到最好的情況。就像著名的囚徒困境，結局就是納什均衡(Nash equilibrium)，或非合作均衡。

軟體開發的最終目的是要給使用者交付價值，要達到客戶的商業目標，從而完成公司目標。而為了實現客戶和公司的雙贏，諮詢公司採用了加深客戶協作的方式 來達成目標。諮詢師會和客戶一起工作，瞭解和認識客户，提出針對性的建議，協助客戶發現和識別業務價值，改進目前的系統。諮詢師會站在和客戶同一方的陣 營，和客戶一起思考、學習和成長。雖然說起來很粗泛，但我所認識的每個諮詢師確實都在認認真真的為客戶考慮。

另一個會產生非合作均衡現象的是按時收費的單價合約和固定價格固定範圍合約的問題。一般PM書籍上都會講FFP合約對買方的風險比較低，而單價合約對於買方風險可高可低，取決於內容和項目性質。

如果簽訂固定價格合約，通常的，由於價格固定，客戶會傾向於在這個價格內擠入更多的需求，有些人甚至不顧品質而要求更多的特性，反正完成不了都是開 發方的責任。而相對的，開發公司會希望在這裡面減少成本，或者是人，或者是需求範圍，甚至是不惜犧牲品質。最終兩方博弈的結果就是項目出了問題。

這種情況下，更好的辦法是單價合約，或者具體說，就是確定階段時間內的開發力量，但不確定開發範圍的收費方式。按照客戶需求的優先順序來開發，雙方合 作，盡最大的努力，頻繁交付。這種做法的好處是，客戶可以控制項目的長短。可以不停的做下去，也可以立即隨時終止。由於雙方的協作，開發公司也會按照自己 的能力，盡最大可能來保證品質和進度。另一種改進過的單價合約，是基於開發方對項目的理解和估算，報出一個固定價格。在合作共贏的前提下，雙方信任並接受 這個契約。這種情況好像更加適合國內的甲方。

前些天，一個原來的同事電話我，她以前是負責銷售的，現在自己開了家公司。她僱傭了一個公司給她開發軟體，開發了兩個多月了還沒見到是什麼樣子。眼 看就要到交付期限了，她想去看看，就問我應該怎麼樣去中期查驗這軟體。我告訴她，要怎麼怎麼樣才能看出這系統到底能不能做完，怎麼看出到底做的品質如何等 等。

瞧瞧，怎麼樣，客戶也不是很好糊弄的嘛。你糊弄客戶，焉知客戶不會另請人來對付你？所以，在商業的博弈中，合作才能雙贏。這就是為什麼客戶協作 over 合約談判的原因了。