軟件工程心理學之3---甲方項目負責人 PK 乙方 (注意：本寫列文章，未經本人同意，謝絕轉載，版權所有，如需轉載，請與本人聯系，謝謝）
???
??? 上周的系列之二(http://www.cnblogs.com/jackyrong/archive/2006/09/05/495791.html），主要是閑聊了關于甲方項目負責人如何和甲方的領導相處配合，以及其中要注意的地方。在本文里，將探討下在整個項目過程中，作為甲方的項目負責人，應該如何于乙方進行配合，如何揣摩好乙方的心理，如何能和乙方和諧相處。

???????? 首先，我們繼續來復習上次提到的圖。
??


???? 這次我們著重談的是箭頭中的“3”。首先我們來看看，作為甲方信息項目負責人，在面對乙方的情況下，會遇到一些什么樣的問題（普遍而言）。我列舉了大概下面一些常見的：
1、來自領導各方面的壓力比較大，領導期望大，自己也有很高的期望，但時間緊迫，又第一次做甲方，覺得沒把握；有的人原來做技術的，現在角色轉換了，覺得做甲方無聊枯燥。

2、項目大，自己覺得在實施方面經驗不足，自己的知識體系結構與乙方有很大的差距，面對乙方提出的要求，新技術，新的實施方法，自己
了解的不多，老有感覺被“乙方牽著鼻子走”的感覺。


3 、感覺對乙方的監督不到位，老是感覺乙方進展慢，不合當初提出的要求，于是老是催乙方，但又提不出很好的對乙方的具體要求。

4、和乙方的工作中，經常意見不一，雙方理解分歧大，老覺得乙方偷工減料，經常和乙方發生爭執
?????? 在上面的這些原因中，有的是由于甲方負責人本身的問題做成的。比如第1點，我就見過有甲方負責人出現過這樣的情況，當然，出現
這樣的情況的一般是甲方負責人的經驗問題，或者是做信息項目的新手，又或者是以前是專搞技術的，這次轉換角色有點不適應。
?
?? 在這樣的情況下，建議先做下心理上的調適。假如你是由于經驗問題或者是角色剛轉到甲方來的話，建議你可以這樣想：我畢竟以前是搞技術的，雖然現在轉了角色，雖然要做的東西不同了，但起碼不用做編碼CODING了?，可以站在更高的角度去把握問題了，可以學到更多的
軟件工程的知識以及管理規劃的知識，可謂海闊天空了，可以做“監工”了，有做“小老板”的感覺了。呵呵，上次我有位朋友，在單位原來是搞技術的，屬于技術狂，后來由于有項目要外包給其他公司做了，他自然成了甲方負責人，開始他覺得不爽，覺得做甲方負責人無聊枯燥，整天要上聽領導指示，下要面對乙方。后來我讓他按上面的講法重新思考，重新調整自己的心理狀態，重新去感覺做甲方的樂趣所在，最后，由于他技術功底好，加上肯學習，很快就轉換了角色了，在整個項目中對各類問題，以及和各方的關系處理的很好。
????? 而對于第2點的情況，應該是普遍存在的。原因可能是：可能是由于經驗的不足，工程龐大，自己在這方面的業務知識還是不足夠，對一些新技術之類的和乙方提出的方法不大熟，但時間又緊。在這樣的情況下，建議有幾點：
???? 1、你自己的心理上要堅信：你是甲方的負責人，你不是全能的，你的職責是把需求較好地告訴乙方，配合，監督乙方完成工作，而不是去做乙方的參謀。因此對于知識方面的缺陷，你要有個清楚的認識，如果不是涉及太核心的業務流程知識，而只是涉及到一些花俏的知識和技術，則無必要過分強調自己去全盤照收，畢竟你的精力是有限的。要搞清楚，乙方提出的新東西，是否真正適合本項目使用。這就涉及到一個評估的問題。這時建議你先把乙方的有關方案仔細研讀記錄，并要求乙方提出明確的根據和理由，千萬不要輕信乙方表面
上的東西。打個比方，乙方說要上。NET系統，吹到如何如何好，但做為甲方的你，你可以結合項目目前的具體情況，再讓乙方提出根據理由進行判斷，就是：
???????????仔細研究項目的業務流程和具體情況+要求乙方真正舉出理由根據+咨詢第三方意見+查詢同類案例的經驗

??????????這樣的做法的好處是“反客為主”，因為要知道，有時設置甲方的負責人有可能根本不是搞技術出身！還可以咨詢第三方的意見，最簡單的是可以和手下開會（手下的一般都是搞技術的），和他們探討乙方的方案。注意做為甲方負責人的你，不要那么直接讓你的下級清楚你知識上的缺陷（否則太明顯的話，有可能讓下級對你產生不信任和認同），要通過和他們討論，間接布置任務給他們，由他們來進行解答，從中聽取相關意見。最后，還可以多查詢同類案例的成功或者失敗經驗，搜集好這些資料，以便在開會時和乙方討論時有根據可以提出來。
????? 在做好這些工作后，對于乙方提出的新玩意，你最好還是自己了解其基本原理和應用就可以了，太深的東西你根本沒必要去了解，或者你讓你的手下去做和整理。

??? 2、心理上要認為自己是掌握主動權的，因為畢竟你是甲方，你是客戶，是上帝。在同乙方打交道的時候，要讓乙方覺得你做為甲方的負責人，是對項目整體的把握是到位的，是有大局觀的，是有很好的掌控能力的，是有領導風范的，是有經驗的。因為這點是很重要的，特別是假如甲方負責人剛接手，或者是經驗不足的，或者是根本不是技術出身的話，更加要在乙方面前表現得鎮靜自若。建議如果你手下有搞技術的人員的話，每次開會都帶上他們；如果碰到乙方吹新技術，新方案的話，自己要保持冷靜，如果不熟的話，可以在會上適當拖延下，讓下次再討論答復，或者讓技術人員解答，有時也要在乙方面前，多表現自己的權威（甚至做下戲有時也要的，呵呵）。

???? 而對于第3，4點，主要是由于缺乏對乙方的量化監督。很多情況下，如果沒有第三方監理的話，甲方很容易陷入盲目的監督中，比如表現在形式上的監督，要乙方定期匯報進度，缺乏在細的方面上的監督。因此有如下建議：
1、在項目一開始，就要擬訂好對乙方的監督計劃。比如定義的會議制度，會議需要乙方參加人員，乙方的長期聯絡人。監督計劃最好按照里程碑來實現，不能過于太粗糙，比如等乙方完成需求調研才進行審核，可以改為：要求乙方完成需求調研中的某個部分的調研，就要提交給甲方審核一次，就象XP里一樣，小規模審核。而且最好也留一定的余地給乙方，比如要求乙方在某個時間段內提交，有的時候
不能對乙方太過苛刻，否則會引起乙方的不滿意，影響接下來的工作。

2、? 每次和乙方開會討論問題時，要做好記錄，最好能錄音。開會前，按出現問題的嚴重程度，由高到低列出來，會上向乙方提出來，最好能搞成一個表格的形式，比如能記錄乙方當時的響應，會后的響應，實際的效果等，這樣以后一目了然，知道乙方到底做了些什么
工作了。對于原則性問題，要明確地向乙方指出，不怕得罪乙方，而對于乙方提出的意見和方案，自己也要記錄，不急于做結論，因為主動權在你手。

3 比如一份典型的監督計劃的模版有可能是這樣的（僅供參考）
????
???

?監督計劃

?

1、? 需求分析階段中乙方對需求調研效果的監督

?

原計劃內容描述??????????	? ? ?
乙方計劃開始日期	?
乙方計劃結束日期	?
?實際開始日期	?
實際結束日期	?
完成情況	?
滯后情況乙方描述	?
乙方提出的解決方案	?
乙方提出的問題	?
甲方對本階段的意見問題	?
雙方對下階段的意見	甲方： ? 乙方：
下一任何的起始時間：	?
本階段備注	這里可列出本階段雙方可參考的已有制品或文檔情況 ? ?
雙方領導簽名：	甲方 乙方 ?

? 當然，如果有第三方監理方的話，則上面加上監理的意見和看法及簽名等。這樣在實際操作中，就量化了，有規范了，大家都要遵守。
先寫到這里，下次繼續寫，歡迎各位繼續批評和補充，發表看法
posted on 2006-09-10 00:25 jackyrong的世界 閱讀(...) 評論(...) 編輯 收藏

轉載于:https://www.cnblogs.com/jackyrong/archive/2006/09/10/500041.html

總結

以上是生活随笔為你收集整理的软件工程心理学之3---甲方项目负责人 PK 乙方的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。