導入設計思維 Design Thinking 的時機：比溝通更重要的那些事
在討論設計思維 Design Thinking之前，我們先一起來看看這個案例：
「工程師到底在搞什麼 ? 一個簡單的訂購功能居然一改再改。」
專案經理一邊抱怨一邊寫著功能調整的描述，
怒氣沖沖的準備在 Review Meeting 給研發團隊 Development Team 好看。
「 SPEC 根本沒寫 ! 我怎麼會知道無法完成訂購時，也要發送通知給客戶的上下游廠商。」
工程師在會議後也是怒氣沖沖的抱怨著產品團隊 Product Team 。
這樣的情節在每天不斷發生著，團隊氣氛十分低迷，導致開發期程時間過長、產品品質不佳，主管、老闆更是不滿意，正所謂「做到要死，被人嫌到流涎。」
大家應該都有遇過這樣的情況，到底是產品團隊 Product Team 的問題比較大? 還是研發團隊 Development Team 呢?
認知不同的解決方法
筆者認為其實雙方團隊會有這樣的摩擦，最主要的原因是認知不同。
而認知不同是因為雙方的目標和思考方式不同，通常一提到認知不同，多數人的第一直覺反應就是「溝通不良」，解決方法就是嘗試不斷地進行溝通，例如：開更多的會議、更多的mail往來、更鉅細靡遺的會議紀錄。
筆者認為提升溝通能力的確非常重要，但要建立有效的雙向溝通，卻不是一朝一夕，且相當耗費成本，所以比起建立有效的雙向溝通，更建議在團隊中導入設計思維 Design Thinking ，讓雙方對於產品的開發有著共同的思考方式，在事前規劃上就達成共識，自然就能解決雙方認知不同的問題，而避免事後的大量溝通。
什麼是設計思維 Design Thinking ?
設計思維 Design Thinking 是以人為本的思考方法，透過挖掘人的真實需求、需要及痛點，在評估技術的可行性後，尋找創新的最佳解決方案，進而創造更多商業成功的可能性。
當雙方團隊都有設計思維 Design Thinking ，案例的問題便會浮現在規劃會議上討論：
「客戶想導入 JIT(Just In Time) 的零庫存管理，因此我們要在客戶完成訂購原物料時，便馬上發送通知給客戶以及客戶的上下游廠商，協助客戶快速取得相關訊息以及物料的調度。」
專案經理描述著客戶的使用情境及真實需求。
「發送通知的功能在技術上是沒問題的，但應該不只要在客戶完成訂購時通知，無法完成訂購時應該也是要吧 ? 畢竟關聯著庫存的調度。」
工程師在思考了客戶需求後，提出了這樣的回應。
「雖然客戶沒說，但的確應該是這樣，並且也應該要一併通知客戶的上下游廠商，我會在會議後跟客戶再次確認。」
專案經理將該建議紀錄於待確定事項上，在會議結束後跟客戶進行了再次的確認。
事前共識的效益遠大於事後的溝通，如果雙方團隊都能從客戶的角度出發，去思考客戶真實的使用情境及需求，便是跨入了設計思維 Design Thinking 的第一步：Empathy 同理心。
後續將持續介紹如何應用設計思維 Design Thinking 在各種真實案例中，如果大家喜歡的話，記得持續追蹤FB、IG、Blog。
📩任何想法/問題或合作邀約歡迎私訊或來信
workxthinking@gmail.com
留言
張貼留言