close
過去我算是懂溝通的，要怎樣表達想法，並不是難事，所以常常沒事就被選作組長、隊長什麼的。
如今我傻了，我真的不懂溝通，因為我已經失去耐心了，而我溝通的對象，也失去耐心了。當溝通的雙方都已經有了先入為主的想法時，大概就不會有所謂的溝通了。
這讓我想起一些描述特殊教育的電影，在對方真的準備要跟你溝通之前，是沒有溝通的可能性的，但是，在多次的嘗試跟釋出善意後，總有一天對方會釋開心房，好好地聽你在說什麼。
最近我就常有這種感覺，只不過是會在有病跟沒病的角色間替換。
有些事情，道理是很簡單的，但是，只要你放入許多的變數，他就會衍生出重重地困難。就像最近，由於產品開發逐漸地有東西出來，因此儘管還沒完成，卻也已經開始逐步地找業務來看新產品的相關功能。這些業務有很多是我不熟的，他們有的會認為工程師就是埋首在技術領域，或者認為工程師都是宅男，另一方面，有過不少成功經驗的業務，會對自己看到，認知到的成功，有自己的一番見解，在雙方初次見面下，我拿出一套未完成的產品，不免會有很多擔心跟質疑。說實在的，如果我是第一次看到這個東西，我也會質疑同樣的問題，但事實上，這些改變都是來自於要解決一些根本性的問題，但因為還沒完成，所以也難以描述他會帶來的效果。
這些問題，就好比以前電視，壞掉了敲一敲就會好，是因為映像管接觸不良，新產品索性就改用LCD，做了個超薄電視，結果卻被抱怨，如果壞了不知道要敲哪裡一樣。因為大家都沒用過，只是紙上談兵，所以要說服提問的人，是不太可能的，只能讓他們勉強接受，帶著心中無限的擔心離去。這樣的結果實在令人氣餒。
另一方面，我是一個善於舉例的人，對於不想思考的人，我可以用生活化的例子讓對方了解我要說明的重點。神奇的是，業界人士多半自認自己很專業，很有經驗，唯一沒有的，就是時間，所以他們不想聽你舉例，他們想聽很專業的細節，並且認為自己可以理解。但很遺憾的是，一直以來，結果都是雞同鴨講，因為軟體跟系統牽涉的技術太多太雜了，在我的架構中可能是同一套東西要一起處理的，在對方的認知中卻往往無法將之關聯在一起，到頭來就是他只聽到他想聽的，但卻沒聽到我要講的。
溝通的關鍵就是傾聽，但同時，對方的言詞中有許多的陷阱，闡述的重點往往在弦外，所以要不斷地詢問，已確定自己聽到的跟對方表達的是同一件事情。不過，最近詢問問題經常會得到一「你是不是搞不清楚狀況」的表情，其實，當我認為一件事情可能有兩種以上的可能時，我就會裝笨把關鍵問清楚。我看過太多次，會議中大家以為達成共識，結果事後的認知卻是有很大的差異，所以我也一再地要求，希望會議中的議題在決議後，能夠記錄下來並重新念一次，以確定大家的認知並無二致。
還有一種，就是太抽象，主管跟老闆講的東西，我聽起來都是很有道理，很正確，但問我對不對，仔細一想，我也不清楚事實上到底講了什麼，好像怎麼說他都對，但實際上的意思是什麼，我到底有沒有聽懂，我也說不上來。
對我來說，最困難的事情就是不懂裝懂，或是隨口應和，所以經常聽到一句話我消化起來比較慢。像是如果FAE說客人就是要某個奇怪的規格，我會思考客人的這種要求是不是出自於我們給予的限制、專案的限制，或者客戶對自己需求的理解有問題，或甚至是FAE問錯了問題，有時候，不是答案有問題，而是我們根本問錯了問題而不自知，所以如果不確認，做什麼都是浪費時間。
後記：
我很欣賞我們家老闆的觀念「從架構上來解決問題」，「把問題分成多個模塊，模塊間的關係要簡單、乾淨」，當然這不是為了逢迎，在此之前我也不曾公開表示過，只不過真跟我追求的方法相同罷了。在學習物件導向的過程當中，你可以看到原本看起來單純的程式碼中，可以透過對需求跟問題的分析、部署、封裝，來產生多個模塊，不同的問題領域就會被鎖在一起，同時，在工作上的安排上，也可以讓特定領域的專才發揮得更深入，而規劃人員則可以在佈好局後，朓開來看清各個模塊間的關連，並藉由各模塊的運作來組織架構。延伸到日常生活中，你會發現套用到大多數的情境下都可以適用，公司可以分部門，企業可以分不同事業群，連快餐店，都可以重複利用不同的成分組成各種套餐。肢解、重組的過程，也跟早期工業化的作法相同，儘管形式不同，但道理是相通的。
全站熱搜
留言列表
