jim yeh on 九月 6th, 2007

在團隊朝向共同目標邁進的過程中,成員間對問題不同的觀點很容易產生一些歧見。而為了尋求共識,團隊成員常會透過對問題進行討論,找出對問題的解決可以化解彼此歧見的做法。昨天,同人與朋友討論到他過去產品開發的失敗經驗,朋友提到了:

當初的真正問題是,特定開發成員個人的目標與方法,與整體團隊是不一致的。而我跟另一位同事都無法改變他,所以失敗了。

這一段話充分地顯露出朋友的心態,然而同人卻認為,用這樣的心態進行溝通,很難會有好結果。為什麼呢?因為溝通是雙向的,當我們討論的出發點是試圖用言語或行為來使對方改變時,這樣的討論並不會有實質的溝通效果,而只是一種單方面的說服行為,此時雙方很難站在對方的立場來思考問題,討論當然不會有交集可言。

其次,朋友所說的「整體團隊目標與方法」其實指的只是團隊中多數人的看法,但這真的是整體團隊目標與方法嗎?可能不同的人會有不同的見解,在團隊尚未達成共識前,這個觀點只是一個在某些人心中未經審視的假設或信念,當我們把個人信念當成團隊目標時,代表我們並沒有對他人不同的信念予以尊重,在這種情況下,對於立場不同對方而言,他憑什麼要聽我們的,為什麼不是我們聽他的呢?

可惜朋友沒辦法理解我想要表達的意思,雖然這個經驗已是陳年往事了,他卻一直認為事實上明明是對方錯了,這種事有必要溝通嗎?他一直堅持自己的觀點,讓他沒辦法意識到他對問題必須確定感的堅持,使他無法敞開他的意識允許更具洞見的觀點出現。對於他而言,這個經驗對他的意義也只是「事實證明我是對的」,卻無法讓他參與與他人對話並集體思考,以得到更多具創造性的觀點。換句話說,在他堅守他個人信念的同時,他的見解常常會被自己意識所侷限了。

舉個例子來說,朋友以為他們開發軟體產品和做軟體專案是不一樣的,但他卻無法理解,開發軟體產品的行為本身就是一種專案。雖然,一般人會把專為某個組織或個人量身打造的系統視做專案,把軟體產品定位為通用於各種不同需求的使用者,但標準專案的定義並非如此狹隘。

依據 PMBOK 的定義,專案為完成某一獨特的產品或服務所做的臨時性努力,臨時性是指專案有一個開始及結束日期,獨特意味著專案的最終成果是之前沒做過一模一樣的。從以上定義來看,只要軟體產品開發有既定的時程,且開發出來的產品又是以前沒做過一模一樣的,本身並未脫離專案的範疇,因此朋友對專案的見解顯然是錯誤的。

當然,朋友非專案管理專業,當然不應對他抱持著有專案正確認知的期望。但同人認為,非專業並不代表專業可以不去重視它,然後以自己的主觀想法來批評專業。同人對有些自認什麼都懂的人,不先去深入了解專業,或向內行的人求教,卻一味地對專業有自以為是之評批的行為,深感不以為然。例如,像下面這句話就說得非常不得體。

當然,學過 PMP,CMMI 就硬要把所有事都往上面套,也不是不行。

這句話是一種對人不對事的批評與嘲諷,充分顯出言者自身的傲慢與偏見,也足以讓聽者感受不到應有的尊重與誠意,這是一場無意義的辯論,因為對方並不想了解不同觀點的看法,以促進相互對問題深入地思考,他只想說服他人用他的觀點看事情,那就沒什麼好說的了。

Powered by ScribeFire.



     

One Response to “尋求共識的出發點”

  1. [...] 這位專案管理者的分享也讓同人回想到我在〈尋求共識的出發點〉所提到的對話,我當時對朋友想說服他人的觀點很不以為然,我也特別強調溝通態度的重要性。 溝通是雙向的,當我們討論的出發點是試圖用言語或行為來使對方改變時,這樣的討論並不會有實質的溝通效果,而只是一種單方面的說服行為,此時雙方很難站在對方的立場來思考問題,討論當然不會有交集可言。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">