はじめまして。株式会社PRUM的工程師ひとみです。
我日常會整理並分享在程式學習與實務工作中容易卡關的重點，
以及工作中常見的「落差」。如果能幫助到誰，我會很開心。
傳達不了，不是說法的問題。透過「看見」對方而改變的需求定義故事
前言
「明明有好好說明，為什麼還是傳達不出去？」
剛開始以工程師身分工作的時候，我有過好幾次這樣的經驗。
我以為自己已經很仔細地說明規格了，結果之後卻被說成「跟我想像的不一樣」。
在需求定義的會議上明明已經取得共識了，交付之後卻又被說「不是這個意思」。
每次遇到這種情況，我都會想：「如果我能講得更好就好了。」
但其實，問題不在於我會不會說明，而是在於我沒有看見對方。
為什麼「同樣的說明」有時能傳達到，有時卻傳達不到
有一次，我用同一份資料向兩位客戶做說明。
對 A 先生，我邊展示畫面完成後的樣貌邊說明「會像這樣運作」，
他立刻就說：「了解，那就照這樣推進吧。」
但接著對 B 先生，我也用了同一份資料、同樣的說明，
他卻反問：「為什麼要用這個架構？」
結果對話就開始接不上了。
一開始我覺得「B 先生真是個難纏的人」。
但其實不是這樣。
A 先生是靠眼睛看、抓住畫面感的人
B 先生是透過邏輯與理由來理解的人
只是這樣而已。
每個人接收資訊的方式都不同。有些人靠外觀和視覺來理解，有些人靠語言邏輯來理解，
也有人是實際動手、靠身體感受來理解。即使傳達的是同一內容，
如果沒有配合對方的接收方式，就不會產生「真的有傳達到」的感覺。
現場常見的 4 種類型
只要稍微觀察對方的言行，就能大致看出 4 種模式。
只要意識到自己或客戶屬於哪一種類型，
需求定義現場的進行方式就會有很大的不同。
想先知道結論的人
「所以，時程趕得上嗎？」
這是經營者或決策者常有的類型，一開始就會先問這句。
不需要冗長說明，簡短整理出結論、原因與選項來傳達，
對方會比較高興。
我以前曾對這類型的人從經過開始仔細說明，
結果中途被打斷說：「結論呢？」
比起這樣，直接先開門見山說「已經延遲 2 天，原因是 ○○，對策有 2 種」
會更受歡迎。
靠願景驅動的人
「如果這個系統完成了，業務會整個改變呢！」
這類人會因為這一句話眼睛發亮。
產品負責人或事業單位的人很常見。
如果一開始就急著把細節規格一一釐清，對方的熱情很容易瞬間冷掉。
先分享願景、讓對方產生共鳴，再進入細節討論，通常會更好。
安全感是關鍵的人
「目前的作業不會突然改變吧？」
這類人會這樣確認。對變化比較謹慎，也常常不太敢說出真心話。
因此要先建立一種可以說出「如果有任何在意的地方，請別客氣儘管告訴我」的關係很重要。
若想避免之後的大反轉，就應該細心地把對方的真實想法引導出來。
靠數據確認的人
「那個根據是什麼？」
會立刻這樣問的人，常見於工程師或 QA（品質保證）人員。
「大概沒問題」絕對行不通。像「我會確認 log，並在今天 17 點前向您回報」這種誠懇態度，才會轉化成信任。
避免認知落差的「覆述」用法
在掌握類型之後，還有一件事也希望大家意識到。
那就是「重複對方的話來確認」這個習慣。
客戶：「我們每天早上都要手動整理全門市的資料，
真的很辛苦……」
我：「每天早上都得手動整理，真的很辛苦呢。」
光是這樣，
就會產生「這個人有好好聽我說話」
的安心感。再進一步說，
我：「也就是說，把轉錄作業自動化、把輸入錯誤降到零，才是最終目標，對嗎？」
客戶：「正是如此！」
像這樣透過確認，就能在認知出現偏差之前先取得共識。
「有沒有說過／沒說過」這類問題，大多都能靠這種小小的重複與確認來避免。剛入行的我，完全沒有「重複確認」這個概念。我只在意自己有沒有理解，卻沒有確認對方是否真的認同。
總結
我以前一直以為：
「只要我講得更好，就能傳達出去」
但實際上，比起說明方式，更應該先思考的是別的事。
那就是：
對方重視什麼，又是以什麼方式接收資訊的人
當然，磨練表達能力也很重要，
但在那之前，
這個人到底是怎樣的人呢？
先對對方產生關心，這件事也許才是更重要的。
先想想自己屬於哪一種類型，或許也會很有趣！
PRUM 的工程師中，有 95% 以上是沒有經驗者錄用。
如果您對本公司有興趣，歡迎看看以下網站文章。
原文出處：https://qiita.com/prum_hitomi/items/aedc1409d1f19c4d14f6
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
