題:
會議期間如何回答不確定的問題
Kane
2016-05-04 17:19:08 UTC
view on stackexchange narkive permalink

本週過後我將要參加一次大型會議,我必須準備會議中常見問題的一些答案。

我擔心的是,有些問題是我所不知道的

在會議中我不知道答案時如何回答問題,同時確保其他人認為我仍然專業且值得信賴,儘管我不知道答案。

>

通常,我會說“一旦完成研究,我會稍後再與您聯繫”,但這感覺太不專業了。

我應該說些什麼來回答超出我的知識範圍的問題會議?

其他信息

我是程序員。通常,我會參加一個會議,回答任何客戶提出的一些技術問題。

我相信我們每個人在會議期間都將面臨此類問題。

為什麼您認為必須研究問題的答案並不專業?
您是否覺得自己在這次會議上“舉足輕重”,並且沒有真正擔任這一職務的條件?還是您有能力和稱職,但只是不知道每個潛在問題的答案?
“我不知道該怎麼辦。我會對此進行研究並與您聯繫。”
您應該知道,有一種疑問句風格,就是不斷問問題,直到答案是“我不知道”。它並不是(有必要)通過提取答案使您看起來很糟糕,而是更多地了解您的思想界限在哪裡,或者達到了什麼程度。這是西雅圖地區的常見樣式。
說“我不知道”並非不專業。如果您不了解自己,就會表現得不專業。我經常看到這種行為,這不可避免地使您看起來像個傻瓜。
在我接受一次工作面試後被告知,我被“特別地”提供了工作,因為我願意承認我不知道問題的答案,而提出這個問題是為了明確目的,看是否候選人會在不知道的時候承認。今天早上我剛剛進行了一次討論,討論如何假裝真正不了解的東西是有效網絡管理的障礙。
@Brandin“我不知道”聽起來很誠實和直接。 “稍後我會再與您聯繫”通常是指“ ...並且,如果您認為我真的會與您聯繫,那麼您會更愚蠢”。無論如何,OP都在談論*會議*,富有成效的會議應該是在會議結束*之前而不是在某個(未指定的)未來日期獲得足夠的信息來做出某事的決定。您很少需要*所有*的信息來做出正確的決定,但是您需要的是*準確的*和*可靠的*信息,而不是猜測。
@Brandin,他們之所以聘請像我們這樣的經紀人,是因為他們希望擁有一些專門知識來處理他們的“嬰兒”。因此,在這段時間內,客戶非常敏感。無論他們問什麼問題,以及他們是否認為我如此專業,都會導致我的公司丟失一個項目。
@BlueRaja-DannyPflughoeft,我同意你的看法。但在某些情況下,您實際上是不允許這樣說的。也許我們的文化不同。
我沒有不同意任何答案,但是他們忽略了我認為很重要的兩件事。說“我不知道”是非常專業的,尤其是如果您憑權威說出來的話。擁有它。不要聽起來溫順或在灌木叢中跳動。另外,“我不知道”比“我不知道”更專業。聽別人的演講,聽聽“不要”聽起來比“不要”更好。
@Kane:很好奇,您在世界或文化的哪個地區生活/工作?
最好說您必須研究它,並且如果需要快速回答,請說出您當前認為最可能的答案,同時強調這只是初步猜測,您稍後將進行更準確的解釋。我見過處於這種情況的人們總是不假思索地立即回答,只是說些什麼,這總是非常錯誤的,他們仍然假裝對此有100%的把握。這很煩人,您可以相信我,它看起來更加不專業。
@Kane文化可能會影響您傳遞/表達消息的方式,但不會影響您不了解某些事情並需要傳達這一事實。如果這是您的問題中的大問題,也許您應該提到客戶通常來自的地區。
您應該說“我將立即通知該問題”,然後在可能的情況下回答。您並不需要了解所有內容,也不必準備解決每個可能的問題,並且您*準備*願意接受它。至少我期望如此。
@DocBrown,我目前在新加坡IT領域工作。
-1
十 答案:
Sheldonator
2016-05-04 17:43:42 UTC
view on stackexchange narkive permalink

無論您多麼有知識,您都不可能一無所知。

有些東西真的很複雜,無法為之做好準備。它會非常定期地發生,並且承認自己不知道並沒有什麼可恥的。實際上,最好是說你不知道,而不是胡說八道以節省面子,這是不專業的。精細。如果您認為自己不能自己做,並且需要幫助,請說出來。如果您可以自己找到答案,則可以返回其他與會者(例如,通過電子郵件)以分享找到的內容。也許那時你會覺得很傻,但是如果你不誠實,你就不會專業!

“我實際上不知道這一點,但是我會研究它”是一個很好的短語,我自己使用它。我唯一要注意的是,如果您對每個問題都這麼說,您似乎對自己的工作一無所知。後續行動尤為重要。您需要盡快跟進研究結果。您不希望該短語聽起來像是更改主題的藉口。您希望人們知道,當您說出自己的想法時,便會有所作為。
另外,當您說“我會研究”時,您是在公開承諾實際去研究它。您將*至少*向提問者報告此問題的答案,但最有可能向整個小組報告。否則,您可能看起來像是在試圖隱藏某些東西(即使不是)。因此,如果您說要研究某件事,則需要遵循。
@corsiKa:我經常說:“我不知道,但是我會在一天/一周/一個月的月底找到並給您回信”。有一個截止日期總是可以激勵我。
如果您只說“我不知道,但我會研究它”,那麼您可能看起來自己還沒有做好充分的準備/不知道您在說什麼。最好先解釋清楚,再說再跟進。 “我知道功能_X_取決於_Y_和_Z_,這將很容易實現,但是我不得不就_X_的其他依賴關係以及它們的複雜程度再次與您聯繫。”
-1
-1
@Ilmari Karonen:提供期限限制了自己,只有在您知道可以保證及時回答的情況下才可以接受。職業世界是不可預測的,您可能無法保證這些事情。我認為,給出最後期限而不是最後期限要比僅僅說“我會仔細研究並找回你”要糟糕得多。
沒有給出最後期限聽起來像是您正在避免問題或模糊不清。會議中的人很可能會逼迫您達到最後期限。
Kate Gregory
2016-05-04 18:02:44 UTC
view on stackexchange narkive permalink

帶筆記本。如果您對可能要問的問題有個很好的主意,請在書中記下數字或日期,以便在被問到時可以參考。

在書的空白頁上,寫下所有內容

被問到時,請回答。如果您不知道,請說“我不知道”。考慮添加“我可以找出並聯繫您”。這並不總是正確的做法。有時正確的做法是添加“但我相信Steve確實如此,Steve不是嗎?”或“直到收到供應商的通知(我們應該在下個星期三)之前,我們才能解決這個問題”或“目前,所有這些都在等待最終立法,而根本沒有時間表。”有時問題不是很相關,沒有人需要答案,他們只是在問,所以就停在“我不知道”。

另外,請注意,在回答問題時,您不會意外地做出承諾,尤其是您無權做出的承諾。與客戶打交道時尤其如此。 “我們可以在部署中擁有這三個報告嗎?” “新格式是否需要額外付費?” “直到有更多開發人員被分配到這項工作多久?”在這裡,無論您是否知道,都不會說“我不知道”,而是說“那不是我的決定”。是的,源源不斷的“您必須問我的老闆”可能感覺不到很棒的客戶服務,但是如果答案不是您要提供的,那就不要回答。這些“問題”實際上是變相的決定,如果客戶讓您滿意,通常是從不了解任何情況的初級人員那裡獲得免費的東西。小心。 “這是(經理)的決定。您要我將請求轉達嗎?”通常適用於這些。

如果您同意研究某些內容,請在書中做一個清晰的註釋(不要與其他無關的註釋混在一起),包括問題,誰想知道,以及一些緊急程度。當提問轉移到其他人時,請寫下您的詢問內容和發言內容。 (我曾經有個男人忘記了上週他說的話要完成的程度,然後問“上次我說了什麼?”-不好回答。)您可以在以後整理這些筆記,然後捕捉一下”報告完成了90%,仍然需要價格,下週ui拋光”,這樣,在下次會議上,您就可以回想起他們已經知道的內容。

無論您被問到什麼,盲目的提供都可以找出來可能很糟糕一個彌補的答案。

在會議之後,迅速查看您的詢問以及您是否不知道存在問題。有時是不可能知道的,也不是你的錯或不知道的問題。在其他時候,很明顯你沒有準備。因此,請花15分鐘的時間思考如何確保下次不會感到措手不及。

對於當前目的不必回答的問題,添加“這超出了該項目的範圍”,要解決這些問題將花費大量的時間和精力。
我看到這些天開會的人太多了,沒有筆記本,或者他們帶來了一個筆記本,但實際上從未打開過。而且很痛。如果我在會議後有一個動作項,它會在我的筆記本中顯示一行,並帶有一個[彩色編碼的便利貼標誌] /cbs/009257.html),具體取決於優先級。每天第一件事,我會列出我的高優先級操作項列表。我會全天定期檢查所有內容。非常重要。
這些人可能會在隨身攜帶的手機,平板電腦或筆記本電腦上做筆記。問題是,這看起來就像在會議期間檢查Facebook。紙質書無誤,並告訴其他人您正在記錄該物品並將要這樣做。
除了上述內容,我強烈建議您提前提出問題,以便您準備解決問題的信息。好的會議應該有好的議程-這意味著人們對他們將要討論的主題有所了解,並且知道議程是什麼,這使您可以在會議之前花費15分鐘的時間來查看關鍵信息,這將使會議更加有意義。可能您將能夠回答重要問題。
user8365
2016-05-04 17:40:44 UTC
view on stackexchange narkive permalink

不要說謊。如果您試圖愚弄其他所有人,您將在很長一段時間內看起來都不專業。如果您找不到滿意的答案,請開始提出解決方案以幫助找到答案。

  1. 我需要更多時間。
  2. 該公司的其他成員需要
  3. 公司需要聘請外部幫助,因為它在這方面沒有專業知識。
  4. ol>

    我們都希望成為有答案的英雄,但有時您是找到英雄的人。

比“不要說謊”更重要,不要猜。您可能不希望歷史將您記住為“說服每個人都是X的好主意的人”,而且如果會議室中的其他人對X的了解與您一樣少,那麼做起來就很尷尬。
@alephzero我認為猜測是可以的,只要您明確表示不確定並會進一步調查,就沒有基於您的猜測的最終決定。
@alephzero-好點。我想說的是,如果您不對自己缺乏確定性感到不快,那您將陷入不誠實的境地。
Hanky Panky
2016-05-05 11:30:15 UTC
view on stackexchange narkive permalink

通常,我會說“一旦完成研究,我會稍後再與您聯繫”,但這感覺太不專業了

太好了,錯誤!在沒有做任何研究的情況下回答您不知道的專業問題實際上是 在這裡要做的不專業的事情。

告訴某人我會對此進行研究並與您聯繫,這是您可以採取的最適當的應對措施之一。如果我是面試官或什至是您的老闆,並且可以肯定我所問的不是您應該已經知道的日常知識,那麼您的答復會讓我感到滿意。

David Spillett
2016-05-05 14:20:29 UTC
view on stackexchange narkive permalink

作為一個經常被帶到客戶會議中的開發人員兼DBA,我感到您很痛苦,但是...

”,但這感覺很不專業。

那根本不是不專業。不專業的做法是嘗試完全避免該問題,或者在聽起來令人信服的地方當場做出一些令人信服的事情(用腳思考無可厚非,但要清楚這是您在做什麼,否則您可能會設定無法實現的期望)。

您如何說出自己的回答可以對您在客戶眼中的樣子產生很大的影響,儘管如此也許有些鮮明“我不知道,我會盡快回复您”。可能不是最佳選擇。

我傾向於用“這是一個好問題”來打開這樣的回答,然後以最佳猜測(“我認為可能是X”,“我們可能會回答加上Y”,“您可能會Z”),最後加上“但我必須檢查幾件事,然後找您確認”。

如果會議中的人員是具有活躍用戶的現有客戶,那麼根據問題,您也可以將其推遲:您的進一步調查可能是要求他們或最終用戶提供更多詳細信息(直接或通過調查應用程序日誌,以了解他們實際上如何使用特定功能(可能與設計功能並不完全相同),因此您可以添加“我們可以離線詳細討論嗎?”或指出您要做的部分是研究它們如何與您的服務配合使用。實際上,這可以幫助,讓您表現出專業精神:您不會花費大量的會議時間(如果您中的一些人和他們中的一些人在會議中,浪費的時間很快就會變得昂貴)細節未知,因此您的效率是 ,但是您正在積極參與(或顯示參與的意圖)他們及其需求。當然,這裡要小心,不要超越您自己團隊中的界限-例如,我通常被信任直接與客戶離線討論事務,但是在與新客戶談判的初期或在處理“政治上”困難的事務時(即(當出現問題時)或通常只是一個困難的客戶,關於誰與誰談論什麼的問題,存在更明確的命令鏈。

有時在這種情況下沒有很好的“最佳猜測”您只能說“這是一個很好的問題,我必須先研究X,然後才能給出有用的答案”,除非會議中的其他人提出了不切實際的要求(如果是這樣,

tl; dr:您的建議並不是完全不專業,但是您可以大大提高自己的專業水平。用仔細的措辭給人的印象。

user16626
2016-05-04 20:23:16 UTC
view on stackexchange narkive permalink

記筆記和提前準備很重要,但是您談到的另一個方面是,我認為其他人都沒有解決。

聽起來您似乎不在乎自己是否在乎可以解答您的所有疑問,但是沒有答案的印象會在您的聽眾中留下。

關鍵是在您的聽眾中灌輸信心。 p>

說“對不起,我沒有答案,但會後會跟進”。最好說的是:“我認為X和Y使我們走到了這一步,但是我還需要跟進Z。以前我做過類似的工作,發現W是個問題,但是Z對我來說是新的”

換句話說,它可能有助於證明對答案和您找到答案的能力的了解有限,而不是簡單的“我不知道”。只要在向人們展示您對主題的知識時,以不太冗長的方式表述該短語,就會使他們對以後有能力回答此問題充滿信心。

N.B。作為軟件專家已有多年的經驗,我見過各種資歷的人和組織結構圖水平的人都使用這種方法,而且很少見到客戶做出負面反應-通常僅當該人或組織已經多次放棄時過去降低了他們的信心。

Karl Bielefeldt
2016-05-04 21:01:22 UTC
view on stackexchange narkive permalink

我同意其他答案,即如果您不知道,可以誠實地回答,但是我要補充一點,人們通常更願意聽到部分答案,甚至是專家的猜測,只要您明確地將其表示為部分答案或猜測,並承諾稍後再提供確定的答案。

如果這樣做會導致合同或法律義務,則您不想這樣做,甚至假定的。例如,您不想對客戶提供現成的猜測,即交付他剛剛告訴您的複雜功能將花費多長時間。

只是說明您將如何找到答案,而不是說“我不知道”。這使您更有信心,並使您看起來更有能力勝任其他人。

coteyr
2016-05-04 23:50:15 UTC
view on stackexchange narkive permalink

當被問到您不知道答案的問題時,該問題分為三類。

您確實應該知道答案的問題。

完全屬於您權限範圍內的事情,您應該已經做好準備。例如,“什麼時候可以完成X項目?”當您領導該項目。

在這種情況下,您最好的選擇是猜測,然後正確猜測。然後讓自己或您的團隊來回答。同樣,這些是您應該知道答案的問題。

其他人應該知道的問題。

這些是應該轉移給其他人的問題。例如,“其他團隊什麼時候完成X項目?”在這種情況下,您最好的做法是建議它實際上不是您所在的地區,但您可以調查一下。 “那是鮑勃的項目,但如果你願意,我可以看看。”在大多數情況下,提問者只是沒有意識到這不是您的問題。您需要小心,不要試圖“怪罪”或接管。您只是想通知那裡的人,這不是您的問題。實際上,如果會議變得更糟,您可以說“我當前未分配給項目X”之類的內容,然後保留。

您只是不知道答案的問題。

有很多問題您無法準備或無法解決。沒想到。如果您不知道答案,那也不是您遇到的主要問題。然後一個簡單的“我將不得不研究”是完全可以的,並且實際上是首選。

第一種和第三種有什麼區別?您的職責範圍和會議目的。如果會議是要評估項目的狀態,那麼不知道您的零件狀態是不正確的。不知道將在項目的下一階段中使用的電話線的總長度是可以的。

示例:

對於這些會議,您的項目負責人是項目X的一部分,該項目是在建築物側面建造一個巨型字母X的項目。

狀態會議:

問:您什麼時候可以開始繪畫?
A:我們仍在等待顏色選擇,之後大約需要一個星期

Q:什麼時候可以選擇顏色?A:Bill正在領導負責顏色選擇的工作組,我可以問他是否喜歡。

問:最後允許您畫X時,您需要多少繩子?
A:我將不得不再與您聯繫,我沒有提供任何數字。我的面前。

您真正應該知道的第一個問題。這是您工作的重要部分。第二個問題不是您的工作,但您知道是誰。第三個是您無法預料的問題。它仍然是您所在的地區,但是您應該如何知道它將在狀態會議中出現。

根據經驗,永遠不要說“我不知道”,總是“我必須研究”。主要區別在於“我不知道”是最終決定。 “我需要研究”是開放式的。

您針對第一種問題的策略的風險很高。如果您沒有做好準備,那麼您的猜測可能是錯誤的,最終您將看起來很糟糕。除非您能提供一個非常安全的猜測,否則我寧願承認“對不起,我不准備就此進行報告”,並解釋原因,即使這是一筆昂貴的費用。
我同意這是一個冒險的答案。但是,同樣,這僅是您真正應該知道答案的問題,因為您的工作以及會議的內容。在這種情況下說IDK是非常糟糕的。即,讓我們說選擇顏色是您的工作,而這次會議是關於項目X的顏色選擇的,那麼當有人問您“我們將在X上使用哪種顏色?”時,您不知所措。您最好準備一下會議,或者重新安排會議的時間,但是現在所有在會議室中的人都在用他們的時間,只需說“黃色”,然後在以後必須解決的話
很難說出1和3之間的區別。屬於第一類的問題很少,在所有情況下,我都認為您最好重新安排時間,然後準備一下會議,但是如果您已經搞砸了,要找到適合自己的處境,最好先做錯事再不要“完成工作”。無論哪種方式,這都是一個令人毛骨悚然的情況。
我相當喜歡這個答案的其餘部分,但是在情況1中進行猜測的建議使我無法反對。如果您清楚地說明自己在猜測,那會很好。
Lightness Races in Orbit
2016-05-05 17:07:55 UTC
view on stackexchange narkive permalink

就像這樣:

我不知道。

就是這樣。

我不知道

直率,誠實,謙虛。

沒有什麼比面對一個不知道答案的人更糟糕的了。 ,嘗試對問題進行喃喃自語,使他們看起來比他們更了解。它總是極其明顯,一點也不討人喜歡。最近,我出於這個原因幾乎完全拒絕了原本是中等至中等的求職者。

經理們很欣賞能夠承認的人,“我不知道“。

如果屬於您的權限範圍,可以通過添加以下內容來證明您的用途和行業:

但是我會為您找到答案的。

就是這樣!無需任何“技巧”或社會工程。只需說一句話。

如果您的經理認為您不專業,並且此後對他們沒有用,那麼幾乎可以肯定,他們已經從您的工作中得到了印象。要么,要么他們瘋了!

Cary Bondoc
2016-05-05 06:51:56 UTC
view on stackexchange narkive permalink

有時會有一些我們不知道答案的問題,但我們有一個主意,有時我們對這個話題有一個聰明的猜測。如果是這種情況,我通常會說這樣的話

我不確定這是否正確,但我認為...等等,等等。請記住,我不確定該答案,好嗎?

由於涉及您的專業領域,您的猜測可能會對他們有所幫助,請注意,如果您確實不知道並且您不知道關於您可以說的問題,我不知道,對不起。沒有人會認為你是個傻瓜。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...