軟體工程心理學之9—-乙方如何面對甲方2

 (本文同步發布在javaeye.com上,轉載請保留出處)

   在http://www.cnblogs.com/jackyrong/archive/2006/11/08/554694.html中,

     大概談了下如何應對甲方的領導。這次要談的就是很重要的如何應對甲方的資訊項目的負責人了。這其實也是相當重要的一部分，在打通了和甲方領導這
個關卡後，如何處理好跟甲方資訊項目負責人的關係，直接影響到接下來項目的順利高效進行。平時乙方跟甲方打交道最多的，其實也就是跟甲方資訊項目負責人打交道。為方便論述，下文將甲方資訊項目負責人簡稱甲方負責人。
  
     首先，必須簡單歸納下一般來講，甲方負責人的一般身份和組成。一般來說，常見的甲方負責人有如下幾類型，簡單分
分類吧
  
    1) 學術型。這類型的有比如博士，碩士以上的，學院派出來的，理論相當豐富，但實際項目不是很豐富。
    2）技能強型的。這類型的，在企業中，一般帶一些比較多人員的團隊去完成任務，一般這些公司都是
比較大的企業了，有人數不少的Team Dev，但有的東西還是要外包出去。技能型的甲方負責人，是動手
型的，很強的實踐經驗。
    3）學術+技能型。學曆高，實際項目能力高。
    4） 技能一般型的。這類型的甲方負責人，在企業中帶的團隊人數不多，平時也要做一些開發，
    5） 單一管理型。這類型的，在甲方的企業中，一般是懂些技術，但不是太多，但偏向做資訊管理的，
理論多。
    6） 基本啥都不知道型。這類型的很多的，特別在一般的中小企業中，可能之前搞維護，不搞開發，
或者跟IT沾邊的，更多的是臨時老闆抽掉來負責的。

    大致由上面這些。接下來逐一從心理角度分析他們，並簡單羅列一些辦法，讓大家共同探討和參考。
   
    1）學術型的甲方負責人。這類型的，學曆高，理論層次很高，有的甚至是大專院校的教師教授。由於他們的特殊身份，他們自視是很高的（哎，他們認為學曆比其他人高就高一個檔次了），自尊心是相當強的，特別是一些教師教授，說不定還是學術界的牛人呢。對這類人的話，一定要在從開始到最後項目收尾，對他們都要保持一種恭敬崇拜的心態，把他們看做自己的老師。當然，有時遇到的，可能真的是理論多實際經驗少的，這樣的話，還是能忍就忍，不要跟他們去較真去比較。在有的案例中，就曾經有乙方的老大，不爽一些甲方的這類型的人，認為他們只會吹理論，不會實幹，因此經常在某些場合和問題上，想壓一下甲方的氣勢，以求氣順點。其實這是相當錯誤的，因為這類型的人，的確不少是在學術圈裡混，他們心理上 也應該知道，他們不是你們乙方軟體公司，可能技術實際項目上不如你們厲害，但他們就認為自己唯一的優勢就是理論和學曆，地位，他們自己的觀點，往往需要得到別人，特別是你們乙方的讚賞，這樣
他們的心理就很爽舒服了。

        因此，下面是一些很好的在平常交往中跟他們的可以說的和做的，比如。
      A “呵呵，張XXX，我看過你在XXXX雜誌上發表的文章（論文）哦，哎呀，我們真的收益不淺呀，我還給
我的團隊去學習去了（或者說：之前我一直想不通的一個技術問題，看了你的文章好，有很大啟發）。
    
      B  “呵呵，張XXX，聽說你們學校有教學實踐基地哦，剛好我們公司也有這方面的人才培養需求，我們
能否這方面溝通合作一下”
       解析；如果你不是老闆，是乙方老大，其實也可以這樣說，跟他們通過某些聯絡拉上些關係，具體的可以讓
其他人去打交道，但如果你能無意插下柳，又成了陰的話，那樣氣氛就很好了，對乙方的以後工作很有利。  

       C 每次會議，要恭敬地聽他們發完言，不要打斷他們，即使他們的觀點看法不大正確，也不要當場馬上有針對
性地太直接說出來，可以委婉地說出來，如果不是太急表態的話，甚至可以回去研究清楚，有充分證據後，EMAIL或者
其他書面形式表達出來，這樣可以避免當面有時表達得不夠好，從而引起他們反感。

       D 記得如果要遇到爭持不下的問題時，如果你覺得自己有道理的話，你的團隊應該充分論證，有十足的把握，
否則萬一的確是人家的是正確的，你的錯誤，一交鋒，人家會更看不起你們。萬一他們的觀點最後發現是行不通或錯的話，
他們知道後，一般是避免再談的，你們要儘快轉移話題，不要老糾纏著。
    
       E 這類型，要交往中分別下，有的人可能真的很學術，性格自我，不大喜歡客套的，也不大喜歡被你公關，那你們
就不要拚命去公關了，不要認為這類型人就都很喜歡被公關，要分清楚，否則適得其反。
   
       D 遇到這類甲方負責人，多點在項目文檔，PPT等中引用理論，讓他們覺得你這項目是理論充足飽滿的。

 

   2） 技能型人。
        這類型負責人，很能搞技術，帶的人不少。大家最喜歡遇到這樣的人了，可以說是知音了。但也要注意幾點。
      
      A 企業畢竟不是軟體公司，企業要的是系統項目上馬後，最快產生效益，因此甲方領導的壓力都壓在他們這類人的身上了。他們往往有自己的內部項目和其他項目，由於某些需要外包給你們。因此你們首先要最好在事前跟他們溝通好，摸下他們的難處到底在哪裡。就是說，比如探聽下，他們在這個項目中，有否
苦衷？比如會否抱怨甲方領導的處事方法？會否甲方領導需求不明確，資金投入不到位但又趕時間？這些東西，都最好在項目開始初就公關下他們。因為他們從心理上來說，如果他們遇到壓力，由於他們的技術背景，是最容易向你們傾訴的，因此公關時要重點關注這個。

      B 不要小看他們，他們企業由於任務不急，經常有的人是技術牛人來的。對於技術牛人，你們見面不久應該可以察覺出來，對於牛人，你們的團隊更加要注意謹慎。曾經有的案例裡，有的乙方跟甲方負責人打交道N久，最後才發現原來對方是技術牛人，那可真是對今後工作很不利了。要在項目之初，通過聊天，搜尋，第三方打聽等各類方式，如實打談對方的實力水平，查出對方的發表文章，blog等等，要對你的對手了如指掌
       如果發現了對方是牛人大牛了，那更應該多種方法去讚揚對方。在這種情況下，因為對方是牛人，因此可以考慮在項目過程中，在有的問題上，多跟對方討論，甚至討論些跟項目相關乃至其他技術問題。因為他們技術牛，你如果能讓他們感到討論能有利於他的水平提升，經常都有個好的學術氛圍，他們心理上感到是很喜歡的，因為他們喜歡遇到知音。有的時候，要注意即使你知道的問題，也要扮作不大瞭解，多讓對方去告訴你，多讓對方跟你上課，
讓他們這些牛人感到他們就是比你“牛”，他們就是老師，那就應該OK了。

      C  當然，這類型的人是很認真嚴肅的對技術。因此你們要考慮配團隊中精明的人跟對方打交道了，起碼讓對方覺得
你們是有一定力量的。

     D 遇到自己方面的錯誤，一定要儘早補救，有的時候甚至可以主動跟他們說，說我們修補了什麼BUG之類的，沒必要對他們
遮掩，因為如果對他們這些牛人坦誠點的話，他們反而覺得你們是很注重技術的，他們也喜歡。

   3） 學術+技能型。這類型是相當牛的了，理論豐富，實踐能力強，學曆高。他們的應對辦法把以上兩點結合起來考慮就基本
可以了。

  4  技能一般型的。這類型的甲方負責人，在企業中帶的團隊人數不多，平時也要做一些開發，但不是很深入。往往
都是要完成上級完成的任務，平時也很少接觸新技術。對這類型人的話，可以考慮：

      A  讓他們感到，你們的團隊開發出來的項目成果，是能協助他們今後工作的，減輕他們的負擔的，要讓他們從心理
上在項目初期就覺得你們是很厲害，很值得信賴的。
   
      B 這類型人，有的是完成任務型的技術人員，不大喜歡新東西，但求無事型。這樣的話，你們在項目中，就不要老炫耀新技術，老在宣揚自己公司團隊的新東西了，他們只要求穩當完成任務。你們就要在項目開發中，多做些讓他們放心安穩的工作，用穩定的技術和裝置，不要為了自己一時之快或者想賣多些貴些就向人家推銷東西，否則人家會適得其反的。還有一類型的技術人員，可能還是想在企業中提高下自己的技術能力的，但苦於自己的能力，因此想多看多學一些新知識技術，甚至有時他們有的因為自己想學和用技術，因而要求你們甲方用的。哈哈，遇到這類人的話，你們就可以向對方瘋狂推銷了，讓他們感到，買了或用了你們的新產品新技術，他們的負責人的水平也會牛起來哦。

     

 5）  單一管理型。這類型的，在甲方的企業中，一般是懂些技術，但不是太多，但偏向做資訊管理的。他們基本不涉及
技術層面，因為他們下面還有基層的操作員。對這類人，一定要把握：
     A 要把設計階段，需求階段的東西跟他探討清楚，如果他技術上把握不了的話，要暗示對方多讓基層的技術人員
跟你們接觸。哎，因為這類型很多都是寫方案型的，而且有可能還要做其他企業內的雜事。

     B 對這類人，一定要在項目初，向他瞭解更具體的基層技術人員的情況以便聯絡，否則到時有事找他就麻煩了。
這類人，要著重把業務跟他探討好，不要老向他們塞太具體的技術原理。但這類人，也是向他們推銷你們新產品，
新技術比較容易的，呵呵，因為他們不是技術牛人，都有從眾的心理。因此，建議你們可以在項目初，
適當多找時間介紹你們公司的新技術新產品，而且要特別讓對方知道，買了用了你們的技術，對方以後更不用去管技術了，
更能舒服地做他的leader去了，剩下的都由他的手下去做吧。因為他們這類人的心理，就是想作方案，少去接觸煩人的
技術，但又不能不接觸哦，因此可以適當把大致的原理跟他們講清楚就行了，沒必要讓他們知道太細緻的東西。

 

6  基本啥都不知道型。這類型其實是最頭疼的，也最麻煩。他們不搞技術的，有可能就是業務部門的代表。對付
他們的辦法真是很難言語細緻表達出來，但感覺起碼要把握如下幾點。
   
   A 他們不搞技術的，因此你們可以將新產品新技術向他們忽悠一下，但要注意“度”，不要適得其反，到最後搞到
他們被你忽悠了，用了你們的花俏東西，結果主要的商務程序的改進卻沒讓他們滿意，不要本末倒置。
  
   B 最好配上業務需求分析師跟他們溝通，甚至多在對方現場辦公。每次拜訪他們，讓他們從細節上認為你們
是很嚴肅認真的Team Dev，不是去忽悠他們的，是確實幫他們提高生產力的。因此重要的會議，要多派你們團隊
重要的人馬去，起碼層級要對稱，不要某次開會，人家領導到齊，你才派一個分析員去，要讓他們覺得你們是高度
重視。

   C 在項目開始前，跟他們反覆強調需求的重要性，要讓他們覺得，需要儘可能在他們內部處理好再提交，否則他們
自己都沒想好的話，會導致多次返工，最後損失的是他們，最好多舉一些失敗的案例給他們知道。多次向他們佈道這點的話，
會讓他們從心理上重視的，記得是多次。

  D 公關他們時，要適當談談業務的，通過非正式的渠道，多套下他們的一些他們不敢在正式場合說的話，這個，想必大家
知道什麼意思了，呵呵。

  E 讓他們感到，你們團隊的項目是做的很快很高品質的，比如多用XP的快速原形發布，每隔一段時間，就讓他們
看到很有功能性的東西，他們不搞技術，最喜歡看到這樣了，他們心理上會有錯覺，認為這東西估計有快搞好了吧。
當然，詳細的涉及需求和軟體工程的東西，這裡就不詳細說了，以後再說。