這些年來，頻繁且大量的與各種不同領域、位階、背景、行業的人溝通，也參與過數百個專案的日常溝通，而一件事情能否高效完成，仰賴的就是溝通，由其實跨部門專案，溝通的重要性更是不言而喻，大家都懂得這道理，但真的做的好的人實在太少，我認為關鍵點在這，多數人並不具備與不同背景的人溝通的能力。
做業務的，不會理解研發，做研發的，也不會理解業務，彼此之間總有許多誤解與糾葛；基層員工不理解主管，主管不理解老闆，老闆更不明白為何員工總是跟他站在對立面，彼此間的壁壘愈來愈大，在解決問題與確認需求時，往往需要反反覆覆多次，並一再討價還價，歷經多次修修改改，才心不甘情不願的妥協於一個雙方可接受的版本。
其實雙方的角度(老闆.VS.員工、業務.VS.研發)、知識領域(銷售、技術)、承受的壓力(業績、專案)本來就不同，考量點本來就很難完全趨於一致，我原先認為這是一種很自然的現象，直到近三年我投身互聯網企業，公司的推進速度飛快，為了讓決策更高效，為了讓專案做錯重來的機率降低，也為了讓公司整體的業績能一路倍增，我興起了從根本解決這個問題的念頭。
如果，能讓所有人的溝通都拉到同一個水平線上，那一定會很高效，但問題是那條水平線是什麼？又要怎麼做到呢？在2016年我花了幾天的時間構思了一個基本架構，如下圖：
我先初步把公司內人與人溝通過程最常出現落差的原因歸因於兩個層面，一個是組織位階，愈高層的老闆，通常愈是策略思維與經營導向，而愈基層的員工，通常愈偏執行與作業思維；一個則是專業領域的差異，功能部門諸如業務部、行銷部、客服部，他們通常著眼於解決面對業績、客戶時所遭遇到的問題，並依此提出他們的需求，這些需求多半是單一功能，而接收需求的研發部門呢，與功能部門通常形成一種極端，會希望找到問題的共性，並系統化、根本的解決問題。
舉一個實際案例來說，如果工程師-John跟業務經理-May兩人之間在溝通一個需求，兩人之間顯然就具有明顯的組織位階與工作職能的差距，遭遇銷售問題時，業務經理考量業務管理制度的改進，而工程師則思考在技術上如何排除這個問題，並避免再次發生，兩者的角度都沒有錯，但思路不同，解法不同，所需的時間不同，結果也因此不同，彼此的溝通是無效率的。
即便是與同為研發部門的工程師與高階主管間，一樣存在組織位階差距，以及相對較小的工作職能差距，畢竟高階主管偏管理，也不是太熟悉目前的技術，因此彼此間仍存在一定的專業領域差距。
而這些差距就是造成雙方溝通無法在同一水平線上的關鍵原因，而消除落差的方法是什麼呢？我當時的作法是訓練研發部門的同仁要具備「商業思維」。
商業思維四力
商業思維的基本構想是要讓團隊成員更熟悉公司運作、企業經營的本質，以及公司策略，藉此能弭平基層與經營層之間因為組織位階造成的差距；同時也讓同仁跨越研發的邊界，更多的去接觸功能部門，包含流程、制度、日常工作，甚至開始要求他們要學習業務、行銷與服務相關的知識，接此縮短彼此的專業領域差距。
我在公司運作了一年多，成效頗豐，離開公司後，我進一步將過程中傳達的觀念與知識彙整成商業思維四力，分別是數據力、策略力、敏捷力與產品力。
數據力
我從公司的財務面開始談起，告訴大家收入、成本與現金流的觀念，內容涵蓋了固定成本、變動成本、毛利、淨利等基本觀念，並進一步拆解了收入結構，拆完後大家就很清楚公司靠什麼賺錢，哪種商業模式的獲利最佳；拆解成本結構，明白了錢都花在那些地方，哪些地方在浪費錢；拆解了客戶結構，大家更清楚哪些族群的客戶最忠誠，貢獻了最多的業績。
接著，我進一步提到提升業績的方法，我簡單的說明了客戶分群、分級，精準行銷、交叉銷售、客情維繫、渠道管理、轉化率優化等概念，並告訴大家怎麼從數據中去找出經營的問題，例如業績未達成的原因，名單轉化率下降的原因等，我告訴大家，這些都是從數據中能反應的，也是研發部門能產生巨大價值的地方，我也順口舉了幾個案例來說明數據化管理強悍的地方。
說完這些，大家頓時清楚了公司的運作機制，也了解了老闆常常掛在嘴上的那些事，我後來發現，其實不僅研發與後勤人員對上述觀念陌生，連業務、行銷人員也是一知半解，我想我有必要去普及這些知識。
策略力
我最常問研發人員：「你知道這專案怎麼來的？為什麼而做嗎？」
其實我問的就是策略，在做策略規劃時，往往都是一群高管聚在一起，討論出策略，接著就定行動方案，而這些行動方案就化為一個個的專案分派到各個部門去，但如我前面所說，高管們熟悉策略與經營，但已經脫離一線工作太久了，他們訂出來的行動方案真的能解決問題嗎？
坦白說，錯誤的機率非常高。
他們當然不是故意的，而是因為專業領域與組織位階差距造成的誤判。如果，承接需求的人沒搞清楚要解決什麼問題，就貿然投入去做，最後的結果可想而知。
我之所以在談策略力前先講數據力，是因為兩者本來就有先後關聯，在此我一樣拿了三國志當案例，如果你手邊有這樣一張dashboard，你除了對公司的狀況一清二楚外，你也很清楚每個數字代表的意義，此時的你，還會容易做錯決策嗎？不會的，就我的經驗裡，我認為多數的錯誤決策往往是發生在對現況與目標的認知不知，而造成認知不足的關鍵原因之一就是沒有充分的數據。
因此，在策略力中，我先透過三國志讓大家回想數據力，公司經營看哪些指標？這些指標的相關數據是否具備？拆解到每個部門時又看哪些指標？數據呢？先讓大家把dashboard給描繪出來。
接著我以平衡計分卡去引導大家思考策略產生的過程，從公司年度目標到財務、客戶、內部流程、學習成長等四個構面的策略生成，並逐一將行動方案給設定出來。目標à策略à行動方案的過程，就是我要大家思考的，所有的行動方案或專案，一定都有對應策略與目標，搞懂了策略，就不會輕易做白工。
敏捷力
企業環境多變，有愈來愈多的企業都開始強調敏捷，公司成長速度快，面對的挑戰與需求的多變性也大，敏捷本就是必須，當時我僅僅強調幾個觀念，快速交付、試錯、迭代，我們首先將這個觀念運用在專案工作上。
第一個動作，先花很少的時間提供臨時解，供緊急應變使用，解法可能是提供小工具或者透過其他workaround的方式處理，並在相對短的時間內（可能是3–5天）先提供局部解，減緩大家面對問題的壓力。
緊接著，將專案從大拆小，一個原先半年的專案可能會被拆成4–6個階段，而每個階段都可以獨立成一個專案，都可以獨立交付。當專案顆粒度變小時，交付的頻率提高了，調整順序的彈性變大了，也大大減輕了等待的痛苦。
後來我們更將這樣的觀念推廣到其他部門，當需求部門提出一個功能需求時，我們先跟他們一塊梳理流程，並用人工或其他方式先打造第一個MVP(Minimal Viable Product)，藉此加快驗證。當時的思路是，人工雖然無法處理大批量的事情，但優點是變動速度快，早上談好，下午就能改了。而這些經過人工驗證的MVP，進入系統開發後就十拿九穩了。
而業務部門們之所以願意配合我們這樣做，是因為我們已經有了數據力跟策略力的支撐，明白他們要解決的根本問題是什麼，彼此已經能站在同一條陣線上。
產品力
相較於一次性的專案，我更希望所有成員都能具有產品思維，做一件事，應該要思考這件事能否同時運用在其他系統、流程上；今天做了這個功能，對整體系統的幫助是長期還是短期的，會不會解決了局部客戶的問題，卻造成多數客戶的麻煩。
我希望大家思考的點有三個，首先是定位，那些東西應該做在系統裡，應該形成規範，但那些東西應該以專案或人工的方式做單點處理，這之間評估的準則很簡單，就是定位。什麼做，什麼不做，這是做產品的基本。
接著是優先級，根據優先緊急程度將所有的需求做好排序，以高價值者優先處理。最後則是複用性，這功能做了，有多少客戶會用到？用在線下的功能，能否也給線上使用？銷售流程的設計，能否讓招募流程也借鑑呢？
定位、優先級、複用性，當搞清楚這些，你會知道產品該往什麼方向走，也會知道如何與需求單位溝通。
算起來，數據力與策略力是有效弭平組織位階與專業領域落差的關鍵知識；而敏捷力則讓我們從開發團隊敏捷，走入全組織敏捷；產品力則讓我們更加具焦於關鍵與正確的任務上，商業思維四力，分享給大家。