本文是項目經理的商務指南系列中的第一篇。(之一:序言及項目本質,之二:認識責任,之三:認識客戶,之四:認識談判,之五:認識項目進展,之六:認識回款,之七:將項目推向不敗之地)編程
編程語言的逐漸高層化致使了需求分析與架構設計的逐漸合併,敏捷開發等更加扁平的開發方法論致使了項目團隊將直接與客戶的業務流程以及業務人員打交道。在這種變革中,項目經理將愈來愈須要掌握一些商務知識,而不是固守原來課本上對進度、質量、成本的認識。架構
本系列博文將涉及這一內容。編程語言
項目經理的眼中,項目經常是與客戶進行博弈和對抗的戰場。ide
在一家國際頂級企業的演講者在被問及他們如何處理頻繁的變動時,回答是「咱們在簽定合同時順便會簽定一個很繁瑣的變動流程,每一個變動的流程有40個環節,時間可長達一個月,所以多數客戶都放棄了沒有必要的變動。」而在提到敏捷開發的「擁抱變化」時,被最常問到的問題就是:「若是客戶需求不斷變化,致使項目延期超支怎麼辦」。架構設計
甲方緣何投入數以萬億計的資金,乙方緣何投入成百上千的人員,來打造一個博弈和對抗的戰場呢?這固然不是當年的本意。設計
如下的內容,須要開發人員能站在甲方角度作一些基本的設想。最簡單的方法,是假設本身要裝修房子,能比較快速地入戲。項目管理
其實與咱們採購物品相同,項目的基本屬性就是交易,咱們把本身擅長的、多餘的東西,來換取對方擅長的、多餘的東西;在整個過程完成後,雙方都會得利;不管「價格買高了仍是買低了」,交易後的狀態總歸是優於交易前的狀態。開發
有了這個基本認識後,對某些現象就能創建正確的認識。產品
好比「客戶不加錢卻提出大量變動」,就不該該被認爲是「客戶故意提出大量變動,而後又不加錢,從而想佔咱們的便宜」,而是應該被理解爲「因爲某些限制,客戶須要得到更多利益,又沒法爲咱們爭取利益。」it
這二者有何區別呢?前者無解,後者有解。有句俗話叫作不怕沒好事,就怕沒好人。前者就是沒好人,然後者不過是沒好事而已。
至於怎麼解,之後的章節會提到。
這是什麼意思呢?舉個例子。
兩家軟件公司,人數相同,開發徹底相同的東西,一家100個銷售+100個開發人員,另一家則是隻有200個開發人員。剛開始頭一年會如何?應該是有銷售的公司厲害一些,由於他們能把100塊錢的東西,賣到200塊錢,賺100塊;而沒有銷售的公司,儘管人多,造出來的軟件值兩倍,也就是200塊錢,但他們只能賣到210,賺10塊。
可是10年以後,軟件的價值差距就出來了,前者的軟件已經值1000塊錢了,銷售人員也能把它賣到2000塊錢,賺1000。可是後者的軟件值2000,只賣2100,賺100。誰的客戶多?固然是後者,由於時間長了,兩家的產品差異這麼大,價格又接近,客戶不可能熟視無睹的。
後者的客戶會直線上升,軟件有個特色,只賣一個的時候,成本很高,得按2000算,但賣兩個的時候,成本就幾乎歸零了,第二個2100整個都是淨利,馬上就超過了第一家公司。
那第一家公司有銷售人員,和客戶關係好,會不會得到市場呢?會,可是不會不少。客戶的決策者,也不是靠購買關係在甲方立足的,他們也早晚會倒向提供價值更多的乙方。
這對咱們有什麼啓示?那就是任什麼時候候,所謂商務、談判、博弈……這些活動,都只是項目管理活動的附屬品;正常最後贏得客戶乃至乙方利益的,是向甲方交付價值豐厚的產品。所以切勿本末倒置。
由此獲得的一個推論,是商務、談判、博弈的核心目的,是保證雙方的利益都最大化,不可持有零和心態。
掌握好這兩種主要本質,就能在下面所說的過程當中保持正確的心態。