此为历史版本和 IPFS 入口查阅区,回到作品页
呂紹民 darrenlu.eth
IPFS 指纹 这是什么

作品指纹

【關於衝突,你應該知道的兩種類型!】

呂紹民 darrenlu.eth
·
·

這是 PM 系列計畫的第五篇, 近期主要會以書籍心得、整理為主
再加上一點自己的菜鳥實務經驗,歡迎各位可以一起參與這份讀書計畫!

「從需求到設計 - 如何設計出客戶想要的產品」


所有的專案,都會面臨到團隊成員意見相佐的時候
就算做了多麼萬全的準備,還是會有意料之外的狀況產生

這些衝突可能不嚴重,但放任不管的話可能會造成嚴重後果



不重要的衝突

協調者的首要工作,是判斷衝突是否重要
重要的衝突與專案本身有關,亦與團隊成員有關係

而有時候,會遇到衝突與專案無關、或是與專案人員無關
這就是「不重要的衝突」,協調者只要解釋其關係,便能化解衝突

一、時空&專案錯誤

例如在討論某項專案技術時,經驗老道的 A 說:「這技術用好多次了,問題很多」
其他人也跟隨附和,說某個技術真的很難用(基於某個系統的狀況下)

協調者這時候可以適當的詢問,是不是由於某個系統,導致某技術很多問題

這時候大家便會明白,並沒有真正的衝突點,只是假議題

-

二、人的對立

如果兩個人長久以來相處不合,很容易混淆「過去」與「現在」的差異
爭辯時常用「你總是...」「你從不...」,變容易轉變成對人不對事的情況

協調者適當的詢問,可以促使兩方冷靜下來,擱置舊仇
而如果這兩人沒有宿仇,起因可能為「對方很像某個遇過的人」,混淆兩者

協調者如果在這時候選邊站,會造成對立情況更加惡化
如果無法在當下將兩個人帶回專案上,只能請兩人暫時離開團隊

「如果你們不能解決雙方的問題,只好請你們兩個都離開團隊」 

-

三、不可或缺的人

威脅某個人離開開發團隊,絕對不能只是說說而已
如果對立雙方都不可或缺,最好的辦法就是:兩個都開除

處理人員對立的秘訣在於「越早面對問題,成功的機率越高」
根據龐大的經驗,在專案的越早期,就越沒有人是無可取代的

拖延只會使本來可解決的問題,變成難以解決

-

四、部門之間的偏見

另一種對立發生在不同部門之間,通常是因為過去早有類似案例
例如:技術人員 VS 行銷人員、企劃人員 VS 設計人員... 等

處理這種部門衝突的最佳方式,就是在兩邊彼此正式共事之前
給予兩組人馬多次機會,讓他們以「人」與「人」的方式相處、認識

譬如說吃個 Pizza 、開個派對、一起在公司看場電影之類的
趁派系還沒有建立起來前,先讓團隊熟悉彼此,較不容易產生部門衝突

建立一般的人際關係,而不是專業角色,有助於專注專案問題

-

五、層級衝突

別懼怕層級衝突,只有當不同層級的人全部聚在一起討論
才是解決層級間互不了解、誤會的最好辦法

只有當該層級的人員不在時,大家才會忘記考量彼此的觀點


重要的衝突

如果就協調者努力的觀察,發現都不是如上的「不重要衝突」
那接下來就可以處理「重要的衝突」了!

一、磨合個性衝突

組員間並不是因為「偏見」,而造成衝突
而是因為彼此的個性,比如:有人天性樂觀,有人一絲不苟

個性上的衝突,應該被重視並以有效的溝通進行處理
負責人應該告知所有人目前的情況,並讓所有人意識到:

每個人都有權力追求自己「想要的」,但並非每個人都可以「被滿足」

這個原則事先說清楚,並獲得眾人同意後
對立雙方因為個性、意見產生衝突時,也能理解為是出於善意且合理的

又或著是可以針對兩種方案,提出第三種「折衷方案」,有助於推動進度

-

二、努力溝通

有效率的主事者必須具備良好的溝通技巧,以領導技巧不好的團隊成員
在這個雙方有不同想法的階段,我們也需要讓大家意識到:

爭論一個事實,但是這個事實真相未來才能得知,所以沒有誰對誰錯

協調者的工作為「釐清問題並測試雙方的假設」,有時候這樣會激怒當事人
但過去的經驗發現,如果當事人等到事情真的發生後才發現是錯的,會更加憤怒

所以,樂於處理因為「事實假設不同」的問題,有助於專案推進

-

三、處理價值衝突

即時已經處理了「個性問題」,也處理了「資訊來源」的問題
但我們仍會遇到不同人馬,對於同個專案「期望不同」造成的價值衝突

典型的衝突中,很容易遇到:

  1. 品質與既定開發時間的問題
  2. 成本與既定開發時間的問題
  3. 專案效益與實際開發時間的衝突
  4. 安全性與便利性的衝突
  5. 功能齊全與可靠性的衝突

諸如此類,在進行需求了解的時候,很常會遇到上面的這些問題
而遇到時,也千萬不要沮喪 ; 如果你沒有遇到,也不要太高興

因為這代表,你根本沒有真正了解到問題在哪

而在價值衝突的處理上,可分為兩種做法:

  1. 告知團隊成員,這類衝突本來就會有,請冷靜下來「好好溝通」
  2. 說服團隊成員,在「設計階段」再討論這些未來有的衝突

這類的衝突,不應該在釐清需求時討論,而是下一個「設計階段」討論
再下個階段才開始決定品質水準與開發時程等內容(甚至問題根本不存在)

任何於需求要件階段達成的妥協,對設計者來說都不具任何意義


優質的協調工作,幾乎不落痕跡,眾人未曾注意之際,輕舟已過萬重山
如果接受協調的人之中有接受過協調訓練的人,協調者運作起來會更輕鬆

「協調」這條路,共勉之!


2020 / 03 / 26 , 紹民



關於「嗨,我是紹民」


CC BY-NC-ND 2.0 授权