「可以請你幫個忙嗎?」想保留拒絕空間,又怕得罪人,試試這個回話技巧 [反問對方為何要找我幫忙(執行)]
「可以請你幫個忙嗎?」想保留拒絕空間,又怕得罪人,試試這個回話技巧 [反問對方為何要找我幫忙(執行)]
1.焦點放在「為什麼」而非「做什麼」
首先,你不能第一時間就問:「要做什麼?」當你一開始就把話題的焦點放在「做什麼」,就等於錯失拒絕的時機。因為當你詢問「做什麼」,對方可能就會覺得你已經準備幫這個忙了。
不過,你可能會想,問這個問題是為了評估對方拜託的事情的難易度,再決定要不要幫忙。如果等到對方說出請你幫忙的事由,才說「我考慮看看⋯⋯」,對方可能會覺得請你幫忙還要有但書,就算最後你幫了他,他也不見得覺得你是真心想幫忙。
《好好說話》指出, 遇到對方有求於你,第一時間不是先關心「做什麼」,而是先關心「為什麼」要做這件事。 兩者的差別在於, 「要做什麼」的最終決定權是落在我們身上,至於「為什麼要做」,則是把壓力轉嫁給對方。
請對方說幫忙的理由,爭取時間思考
請對方給我們一個幫忙的理由,是對方的義務,不要覺得不好意思。 先問原因,一方面顯得我們是真心關心對方,另一方面也是讓自己更容易採取下一步對策。
舉例來說,如果對方說:「最近 A 業務有些爆單,不知道你能不能幫我處理一些呢?」當你知道對方請你幫忙的事由與原因時,就可以根據對方的原因給出一個不幫忙的相似理由。比方說:「噢,我有聽說,我們這邊最近也接了一個類似的訂單,我是真心想幫你,但真的幫不上忙。」
《說理I》作者傑伊·海因里希斯(Jay Heinrichs)指出, 值得信賴的說服者會針對特定情況給予拒絕的理由,而不是丟出萬年不變的答案。
心得:
這篇和『委婉的溝通技巧 ~ (指桑罵槐;遇強則屈,借花獻佛)』 類似,都是不直接立馬告知/回復對方,而是使用 時間換取空間 的概念爭來取找尋最佳解的方法
一般和別人應對時,也可以重複對方問題,除了爭取時間外,也透過重複問題達到刺激大島的效果
9 thoughts on “「可以請你幫個忙嗎?」想保留拒絕空間,又怕得罪人,試試這個回話技巧 [反問對方為何要找我幫忙(執行)]”
這就是5W2H解決問題 /四象限 的思路一樣
先釐清問題-5W2H [ http://jashliao.eu/yourls/fgtuoho ]
+ What: 描述發生什麼問題現象 ?(反向思考:有沒有可能是陷阱/假問題)
+ Why:我們為何要處理這問題,它可能造成什麼影響 ?(處理與否/各別優缺點列表)
+ Who :釐清誰是此一工作處理人們 ?( 誰執行,為何是他,有無其他選擇 )
+ When :估算預計可處理完成時間 ?(1.5倍)
+ Where :在何地方或作業環節中處理 ?
+ How : 解決方案是什麼 ?如何導入 ?(準備兩個以上方案,最好正向+反向各一以上)
+ How much :發生的成本與負擔歸屬?( 花多少/賺多少/停損點… )
判定處理先後次序-四象限 [ http://jashliao.eu/yourls/fgtxfq5 ]
推掉 工作/幫忙 的第一步
推卸 工作/幫忙 的第一步
推卸 推掉 找
理由
藉口
幫忙
工作
以自己(自我) 為中心 所以先考慮 WHO -> 為何找我(為什麼是我)
時間換空間
沒有搞清楚核心問題,被拐的實例
https://nash966.pixnet.net/blog/post/4482926-%E9%81%87%E5%BC%B7%E5%8D%B3%E5%B1%88%EF%BC%8C%E5%80%9F%E8%8A%B1%E7%8D%BB%E4%BD%9B
一位同樓層不同公司的同事(以下簡稱A先生)於昨日與一位本公司的AE Engineer非常慎重地跑來我的座位找我,只為了問我一個問題:『要如何用程式得知現在時間。』
首先我非常納悶為何A先生要與本公司的AE一同來找我(A先生本就與我相識),再者A先生的問題有點籠統;
首先我反問是在什麼環境下用什麼開發工具或語言,是Visual C++嗎?
我在得到一個肯定的答案後隨即馬上不假思索地回答time(null)可以得到現在時間
A先生馬上補充也一並要得到年月日,我則當著他們倆位的面找了一下MFC函式庫,並且馬上給了他們一個答案(某某函式)要他們試試。
在他們得到答案且各自回到座位後我獨自尋找了一下有沒有更好用的函式,果然…讓我找到一個很方便的做法,接著我就把那三行程式印出來(有一行是show result用的),帶著那張A4紙到A先生的座位上準備給他一個驚喜,不過我看到的卻是一個神色緊張不知所措的男人(A先生平常說話非常自大且有點沒禮貌)在看過A4紙之後一直推說他對Visual C++不太熟,說有問題要再找我問(其實我給的那2行程式根本沒有技術可言,可謂非常簡單之明瞭);其實我當下馬上意識到他一定會再問我,不過接下來我就開了一整天的會,也沒想那麼多。
今天(零點前的今天)A先生果然來找我,不過這回他單槍匹馬一個人來找我,一到我座位上馬上丟出一張A4紙跟我說︰耶~ Visual C++我真的不熟,我直接說好了,我那邊有一個case是Visual C++寫的,老闆找不到人做,我跟我老闆說我Visual C++很熟,他把case丟給我做,這是我老闆要的(手指著A4紙)。接著我看了一下A4紙竟不是我昨天那張,而是他老闆的需求印在一張A4紙上(而那需求其實在我昨天給他的A4紙其實已經告訴他方法了)。
Bug變Feature
Bug VS Feature
錯誤變特性
缺點變特性
錯誤 VS 特性
缺點 VS 特性
回答華為公司面試題一頭牛重800公斤一座橋承重700公斤問牛怎麼過橋?[5W2H1R]
https://blog.csdn.net/love1988520/article/details/116226097
首先要市場方面再次確認客戶需求:
明確客戶要牛過橋的原因,是要吃牛肉還是要活牛;
如果是要吃牛肉,那麼可不可以用不低於該牛品質的牛肉來替代該牛,若答案為是,該客戶的實際需求是吃牛肉,活牛過橋不再是必須實現的客戶需求,召集專家重新評估解決方案。
如果是要活牛,那麼可不可以在河對岸用同質量的牛滿足客戶需求,若答案為是,該客戶的實際需求是在河對岸要活牛,過橋不再是必須實現的客戶需求,召集專家重新評估解決方案。
若確認以上皆否,該牛為客戶寵物,必須全須全尾活蹦亂跳的送達客戶河對岸的新家;或者說專家評估就是牛過橋是最佳解決方案。那麼客戶需求精進成:把這頭800公斤活牛送到河對岸。
實現需求的困難點為:橋面承重僅700公斤。
好,專案負責人(產品經理)召集內部相關人員展開腦力激盪會議,會議時間嚴格控制1小時以內。
會議中得到以下解決方案:
1、降低牛對橋面的壓力。實現途徑有給牛節食一天;給牛繫上熱氣球;
2 加強橋承載能力。評估發現橋墩最大承載能力達1000kg,橋的承重瓶頸在橋面,可以給橋面臨時鋪設棧板進行加強,牛通過後恢復原樣;
3、…
記錄會議結論,送交研發,要求研發給予優選方案及風險評估、規避措施,形成可行方案後,研發專案責任人召開方案評審,依評審意見進行最佳化、細化,如有致命問題或過多的嚴重問題則方案推倒重來,直到形成最終方案給市場確認,由市場介面人分別與客戶確認可行,橋樑負責人確認放行。拿到通行指令後,立即執行,專案負責人即時追蹤。
以上行動需有正式記錄並歸檔備查,一旦出現意外,由整個組織統一承擔責任,盡團隊之力挽回不必要的損失。
牛過橋後,相關人員總結經驗案例一併彙總,供同事參考借鏡。
整個過程中的會議結論可能很簡單,但這個會議仍然是必須要召開的,目的是引入組織的能力降低意外,降低風險,同時預約整套組織的資源,在過河過程中可以對各種意外進行快速反應。
再來談談這個問題背後隱藏的目的:
如果面試者直接給出某個具體的、可靠的解決方案,那麼這個面試人比較適合做研發基層;
如果面試者給出解決思路,不說死最後能否實現,可以做專案介面人;
如果面試者給出全套解決視角,他要嘛做過功課,要嘛就確實可以帶團隊做專案。
———————分割線————————
補充一下:
趕牛過橋應該是實現需求的手段,本身不像一個真正的需求,面試者需要挖掘出客戶的核心需求是什麼,然後給出好的解決方案。
我的原答案中漏了華為一個很重視的點:如果明確了牛是客戶的寵物,需要運送到河對岸比較遙遠的指定位置,客戶原本希望華為把牛送過河,那麼華為的市場人員一定會深入挖掘牛過河之後客戶還有什麼工作要別人去做,然後給出更優解決方案,使客戶滿意度超出預期,以便展開進一步合作。
當然,這是市場銷售需要做的本職工作,如果是面試研發崗,點到為止提醒市場銷售多問一下就可以,不必深入展開。