在專案開發這17年來，幾乎每一個團隊都會面臨到一個很現實的狀況【理念不合】，怎麼辦？
說到這件事，我想先分享發生在我身上的三個故事。一個是剛進遊戲業大約3年的故事，當年的我還是一個血氣方剛的小夥子，那時候的想法總是覺得只要有足夠的理論基礎，肯定可以在討論的過程中克敵制勝，只是通常結果都不是想像的那樣。在某一次的專案進度會議上，報告一個設計概念，那個設計是關於【怪物AI】的，由於在討論的前幾天才剛看了【遊戲人工智慧】這本書，裡面有提到一些AI的設計方式、理論，於是年輕的我就很興奮的將這個AI設計套用在當時的專案上。原本以為這樣的設計會讓大家對我另眼相看，覺得好棒、怎麼想得出這麼厲害的設計…。但是，我錯了，因為當時的製作人在他過去的開發經驗裡，並不是這樣設計的，於是我和製作人兩個人就在整個團隊的進度會議上吵起來了，現在想想，那個時候的我還真的是完全失去理智，吵到讓團隊的人看著我們兩個激辯…。(感覺真是害羞)
第二個故事，也是讓我非常印象深刻。因為我過去也很喜歡畫圖，也畫過不少東西、出過很多本同人誌、投稿，甚至還有出一本教人用Photoshop畫圖的書，對於畫圖這件事還是頗有自信的，但是在某一次，因為自以為對【美】這件事是很有見解的，於是不小心就踩到當時資深美術設計的底線。和他的關係，也從本來的【無話不談】，最後變成【無話可談】了。
第三個故事，那個時候我轉職到營運單位，學習營運的經驗，但是當時公司的營運與研發其實是不和的，不過營運與研發常常吵架是很合理的，因為立場不同、專業不同，所以常常會有不同的意見，只是當時的營運長希望我可以協助去協調雙方的溝通，就從營運單位又被丟回研發了。那個時候，因為被委派重任，加上又有不少的開發經驗，所以又想要一展長才，就在這個時候，遇到一個意見很多的技術，雖然他的想法很多，但是很多都只是流於表面，於是在溝通的過程，又習慣性的用【理論】想去讓對方【強迫接受】，最後雖然爭贏了，但是卻被當時的技術長斥喝了，當時的技術長這樣對我說：「我知道你很聰明，但是這是團隊開發，就算你爭贏了，對於專案來說並沒有任何幫助。」，這次事件就給了我很大的反省。
因為我想要用【理】去說服這件事，在第三次遇到挫折後，我就開始反省了，才真的知道什麼叫做【有理說不清】。經歷過這麼多的專案開發後，也才徹底理解【理性討論】這件事，其實並不存在，因為每個人都會有自己的想法，在討論的過程中，總是會有被說服的一方，要如何讓【被說服的一方】可以【放下】並【接受】，才是關鍵所在。
就在幾年前，當時出了很有名的書《被討厭的勇氣》，其中有一段的內容大概是這樣的。「人為了達到目的，而捏造了憤怒的情緒做為手段」，其實整本書的內容講的非常得多，有興趣的朋友可以去找來讀讀，或許可以幫到現在的你。回來說 《被討厭的勇氣》 提到的這件事，當我理解到這本書提到的概念後，漸漸的開始試著在會議中、討論中、爭辯中，讓自己抽離，可以用後退一步的角度看待這一切，為什麼這麼說呢？很多時候會吵架，多半都是為了讓對方可以接受自己的論點或想法，但是都會陷入「理性討論」，最後就會變成「情緒爆炸」了，因為誰也不讓誰。一旦情緒起來後，只要有一方先攻擊對方，基本上當下的溝通就會變成「無效溝通」。
很多管理學的書都會說，用更開闊的心胸去接納更多的資訊，但是這是一種【行為】，行為的產生需要想法支撐，可是更多的時候，就是這個想法很難改變。
舉例來說，在軟體開發中很常發現的狀況是，有兩名經驗深厚的工程師A和B，A是做大型開發案出身的，經常在30-50人的團隊中開發，追求系統的穩定；B是接案開發出身的，經常在3-5人的小團隊開發，追求開發的效率。當這兩名工程師放在同一個團隊的時候，就會有非常多的想法會衝突，不管是開發流程、系統架構、coding style、版本控制…等的概念都會天差地遠，可想而知的是，爭吵從不會間斷，或許從組團的第一天就開始了。
所以，又有更多的管理學的書說「慎選團隊成員」，要找理念、想法接近的夥伴，但是當我們只是團隊的小螺絲的時候，又無法影響主管會找誰加入團隊。這些都是一環扣著一環。即使一開始有好好的選擇團隊成員，誰又有辦法可以確保團隊成員的想法永遠一致？在實務上，這些都只能算是盡量控制「吵架」這樣的風險產生。
回過頭來說說，最近一次成功解決意見不合的案例。前陣子，工程師與品管單位也發生了一些些的摩擦，當時狀況是這樣的，品管單位為了可以讓工程師方便確認BUG，於是會在描述BUG時，除了說明BUG的狀況，還會列出BUG重現步驟，甚至會附截圖、錄影片，用盡各種方式，就是為了想幫助工程師去確認BUG。出發點很棒，對吧。但是，工程師卻不領情。
在合作第一年的時候，這樣的狀況還不明顯，但是第二年開始這樣的矛盾就開始加深了。至於這個問題突顯得關鍵在於「績效考核」，因為績效考核的關係，公司開始看重BUG的產出及修復比例，於是會開始反向要求工程師要顧好品質。工程師就會開始針對BUG有比較激烈的反應。
起初工程師有強烈反彈的時候，幾乎全部的人都認為「都是因為績效考核」，因為「績效」，所以不想讓自己的「績效差」，所以「不認列BUG」，開始「對BUG產生激烈的抗拒」。
於是，開始針對績效考核的處理方向去進行，當時做了以下幾種行動：
1. 檢討BUG認列標準
2. 與前端、後端工程師分別討論BUG的標準
3. 工程師產品品質的計算方式調整
當時，自己都覺得應該就這樣解決了，但是，其實根本沒解決，爭吵還是存在。
於是，左思右想，覺得還是需要和意見比較激烈的工程師【1vs1面談】，其實這個面談的目的不是希望他照我們的想法走，而是要徹底理解抗拒的真正原因。一問之下，才發現問題的癥結在哪裡。其實這位工程師在意的根本就不是所謂的績效，而是BUG重現花了他們太多的時間，有些時候這些BUG得重現又不見得100%可以重現，於是為了解決一個BUG，花了太多時間去驗證，如果品管人員提供的資訊中有一些錯誤資訊，可以加速工程師去判斷。而工程師認為這個行為是品管人員的基本功，也就沒有去跟對方說希望對方能做到這些。
至於品管人員則是依據過去的開發經驗，使用他們過去和其他工程師合作的方式，以為這樣的資訊就足夠了，甚至還做得更多。雙方都以過去的經驗在進行開發，但是，不同的成員組合，不同的團隊組合本來就會產生不同的開發流程，這一點在初期並沒有做好，於是衝突不斷。
但是後來，就安排一次的會議，讓工程師提出他們需要的資訊，並指導品管人員如何查出「錯誤訊息(ErrorMessage)」，之後，雙方的爭執就暫時消失了。
其實，很多時候的爭執都是因為【想法不同】，而造成這樣的原因可能有：
1. 過去的開發經驗
2. 當下遭遇的困難
3. 現在的組織文化
4. …包含上述得其他100種狀況
會造成的原因非常非常得多，不同的時空背景下，造成問題得原因都不一樣，但是面對這樣的狀況，有幾個原則可以參考。
1. 不要妄下定論，在未求證前，所有的原因都只是假設。
2. 想辦法創造「1vs1對話」的機會，有些時候「1vs1對話」可以了解很多內心深處的話。
3. 不要預設任何立場，千萬不要預設對方就是因為OOO，所以OOO，這會讓對話直接中斷。
4. 不要指責對方應該怎樣，記得傾聽對方內心的聲音，一旦指責對方，立刻會產生上對下的優越感，接受方也會立刻築起防禦的高牆，對話也會變成爭辯。
5. 仔細筆記對方在意的點，這個動作非常重要，因為會讓對方感受到【尊重】。
以上這幾個原則，只是個人在面對衝突時，在採取行動時，讓自己盡量遵守的原則，獻給在專案開發路上，一路受挫的個專案經理們。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言