題:
同事反應過度,要求澄清
AddictedWithOracle
2017-06-19 21:21:03 UTC
view on stackexchange narkive permalink

我收到了一封來自業務用戶的電子郵件,請求更新1150名員工的國家標識符。作為一個相當新手(我在公司任職僅一年),我找了另一個開發人員“ RP”(5年),因為她了解更多,以查看是否已經有一個腳本可以這個任務。線程如下所示:

請求者:請使用附件更新員工的NSS。
我: “ RP”。嗨,“請求者”,您能否說明更新是否適用於國家標識符?謝謝。
請求者:是的,它是國家/地區標識符。
RP(5年開發時間):不,我們沒有針對以下條件的自動程序
我: **從電子郵件線程中刪除了業務用戶**如果是這種情況,那麼我們可能需要為此創建一個新程序。我們可以在星期一在測試環境中進行測試,然後讓“業務用戶”在投入生產之前進行驗證。請讓我知道您對此的想法。
RP:我們已經有一個更新國家/地區標識的過程,該過程不會向用戶公開。不建議更改國家標識符,並且有很多參數。需要檢查數據的完整性,例如工資單是否已在具有當前ssn的員工上運行,是否有其他員工存在提供的ssn等。請在進行任何操作之前與“ MANAGER”進行討論。

我很困惑,因為她早先說過沒有為此創建任何程序。因此,我要求澄清一下:

我:我尚未對此進行處理。您之前提到過,還沒有為此建立任何流程。你能澄清一下嗎? “不,我們沒有為此準備好的自動程序。”

這是她的回复

RP:是的,是的。仔細閱讀該聲明。儘管它可用,但尚未準備好使用,並且尚未在生產中使用。
該軟件包需要調整和重新編譯以更新我們要求的列。它僅供開發團隊內部使用。它在UAT實例中用於恢復工資並行的ssns。
通過指出這樣的語句,我可以知道您要提出什麼嗎?
我無意隱藏任何已使用的內置程序並增加團隊工作。
如果您看到下面的討論,您應該了解為什麼它說沒有可用的程序。
建議,在直接跳轉到解決方案/建議之前,請先了解該要求是否有效,因為
僅僅因為我們擁有自動編程的功能並不意味著我們會繼續根據SR使用它。請運用一些想法,並嘗試對更新進行影響分析。
最後但並非最不重要的一點是,如果您不考慮在這些陳述中花費更多的時間,不如在這些陳述中討論和花費時間,將不勝感激。這樣的更新的影響。
例如將文件數據與系統數據進行比較,並讓團隊知道情況如何。

我對她的答复感到驚訝,而且我不知道她是如何認為我在拋出“指控”或“挑起”這些東西。我終於回答了控制情況:

我:“嗨,RP,冷靜點。:)這裡沒有提出“ allegations”。我只是想澄清前面的說法,僅此而已。不要否定它。 :)不確定您為什麼得出我在“提出”的內容。這只是一個澄清請求。我們明天可以討論這個問題,以提出解決方案。謝謝澄清。

某種程度上讓事情變得“更糟”,看來我們的經理(與RP具有相同的國籍)站在了她的身邊:

經理:澄清電子郵件應以1:1的方式發送。

可能需要考慮的一些注意事項:

  1. 整個團隊都被複製到了電子郵件中,包括我們的經理。
  2. 我在全球範圍內遠離他們工作(我在PH,他們在美國)。
  3. 他們是不同國籍的人(我在菲律賓,他們是大多是印度人。)
  4. 電子郵件交換已過去了一周d,我們無法互相呼喚。
  5. ol>

    我的問題是:

    1. 我說錯什麼了嗎?
    2. 可以做什麼?我現在要這樣做嗎?
    3. 如何避免這種情況?
    4. ol>
即使帶有笑臉:)單詞“冷靜”也很少達到預期的效果...
我不確定這是您的同事反應過度還是您自己沒有掌握流程的細節以及她提出的問題的嚴重性。
您可能應該去收聽這個播客節目和/或閱讀成績單:http://www.quickanddirtytips.com/productivity/email/what-should-you-never-say-in-an-email
即使沒有“平靜下來”,笑臉也足以激怒我,而多餘的笑容使我倍感生氣。
@brhans,我什至會說,它們的解釋可能非常糟糕。不好意思,笑臉看起來像是挑釁。就像:“你生氣很有趣”。
在平靜下來的歷史上,從來沒有人*實際上*通過聽到“冷靜”一詞而平靜下來。
@berry120事實並非如此。如果您沒有意識到自己的脾氣確實可以幫上忙。
您為什麼在整個電子郵件中都這樣使用引號?您是專門針對此答案執行的操作,還是通常執行的操作–如果是後者,則可以避免。
我以前曾經是高級開發人員。它是這樣的:1.客戶會因為不了解技術或設計的某些方面而要求他們不應該做的事情2.初級開發人員會回答他們並做出明確或隱含的承諾3.高級開發人員陷入困境,必須非常小心,不要告訴客戶“否”,而要等到正式討論發生之後再進行討論。4.初級開發人員就像“為什麼不這樣做?我可以輕鬆地做到這一點”,因為他們不會了解到底發生了什麼...可能會帶來很多額外的工作或壓力。
@brhans我認為您的意思是“特別是帶有笑臉”
十一 答案:
Laila Agaev
2017-06-19 23:34:59 UTC
view on stackexchange narkive permalink

據我了解,以下是我對您的問題的回答:

我說錯了什麼嗎?

我認為是的:

  1. 在要求澄清是否有程序可以執行請求者想要的操作時,您忽略了RP消息的措辭強硬的觀點:這是很危險的更改,必須進行與經理討論過。
  2. ol>

    這可能使她感到煩惱和擔心,因為您似乎在跳槽考慮如何實施解決方案,而忽略了重要的建議,未經批准請勿這樣做。這可能是為什麼她的​​第二個回答措辭要強得多的原因,因為您似乎之前不太了解或認可她的建議。

    1. 告訴某人“冷靜”是在專業環境中思考,粗魯和屈尊。特別是如果他們是您的上級。
    2. ol>

      這時我該怎麼辦?

      道歉(例如“如果我不禮貌或不屑一顧,我會很抱歉,我會按照您的建議進行操作”),然後按照她說的做,並與經理討論此事,然後再考慮實施細節。在確定您需要它們之前,不要問她任何進一步的實現細節。

      編輯:看到評論中有關道歉措辭的討論,是否存在“如果我以粗魯或不屑一顧的態度離開,聽起來好像是不真誠或道歉。

      如何避免這種情況?

      1. 不要告訴人們冷靜。

      2. 更清晰地傳達您正在關注給您的建議,並認真對待高級開發人員的擔憂。例如,除了編寫:

      3. ol>

        ,我還沒有從事此工作。您之前提到過,還沒有為此建立任何流程。你能澄清一下嗎?

        嘗試類似的事情:

        感謝您的建議,在繼續進行之前,我一定會與“ MANAGER”進行討論,並且我了解此請求的危險性。出於好奇,您能否澄清一下...的意思?

        儘管就我個人而言,在與經理討論之前,我不會再為其他開發人員打擾其他技術問題。在這種情況下,我將回答如下:

        謝謝您的建議,我知道這是非常危險的,我將與“ MANAGER”討論是否繼續。

極好的答案。 我要補充一點,說“冷靜”可能是“如果對我有任何冒犯,我感到抱歉。我不確定我為什麼這很重要……您介意嗎?和我聊天嗎?” 當電子郵件therad變熱時,拿起電話。如果您不能僅僅寫信,您不是要冒犯他們,而是會盡快拿起電話/ Skype尋求澄清。始終保持良好的意願。
通常,在類似情況下,我將澄清請求的措辭作為與經理進行討論的輸入。“我想確保在與經理討論時,我掌握了所有可用信息,您是否可以澄清...”的含義
儘管他不應該說“冷靜”或使用表情符號,但這已經結束了。對我來說,這位資深人士反應過度。也許OP一直讓她煩惱很多次,因此做出了反應。實際上,準確地詢問他們作為自動程序具有什麼才能知道可以從什麼開始,這並不是IMO愚蠢的問題。
您是否建議在管理結構中的所有人中以一對一的電子郵件和CCd的方式要求澄清?
“很抱歉,如果我粗魯或不理會您的問題”。我將其更改為“很抱歉,我對您的問題不禮貌並且不屑一顧”。以“如果...對不起,”開頭的道歉對我來說並不真誠。
@firtydank雖然我對OP的文化不了解,但是在我的工作場所,“我很抱歉……”是每個人都“非常”喜歡的。“對不起,我...”表示您有*意圖*粗魯/不屑一顧。在OP當前所處的情況下,他們需要推遲意圖,同時還要道歉。
通常,我將其表述為“對不起,我沒有試圖表現出粗魯的態度。”將“對不起”部分與緩解措施分開。
@EBrown是一個公平的觀點,但是“對不起,如果我不禮貌或不屑一顧,我很抱歉”也可以解釋為“對不起,您無法理解我的真實意圖”,這令人光顧。我在這裡最喜歡IllussiveBrian的建議。
@BaileyS我認為這在很大程度上取決於公司的文化和團隊的規模(以及澄清的性質)等。通常應該優先考慮誰應該參與和不應該參與。就個人而言,如果與他們沒有直接關係,通常我會避免將他們包括在電子郵件鏈中,所以我不會為任何非CC或團隊以外的人提供CC請求。但是,在大型公司中,我已經看到這種“質量CC”很常見,因此它本身並不令我感到驚訝。經理在這裡(為時已晚)專門說要使其私有化,所以我建議將來遵循這些指示。
@dyesdyes我認為,上級可能很生氣,因為OP不承認她的指示或擔憂。我也會很煩。在我看來,OP也誤解了前輩所說的話。她告訴客戶,沒有自動程序,OP跳上了程序,然後繼續執行,而不是考慮整個問題。我認為她認為這是一個愚蠢而危險的問題,因為“我們可以自動執行此操作”比“我們應該執行此操作以及我們如何驗證它是否正常工作”不那麼重要。不知道細節,我無法進一步評論。
至少考慮到我在閱讀問題中引用的對話時所做的假設,大多數答案對我來說都是沒有意義的。在從同事那裡發現是否已經存在這樣的工具之前,OP可能會合理地要求其經理建議構建新軟件?
@MarkAmery我不相信高級開發人員會要求他與經理聯繫以“構建新軟件”。我認為她打算讓他討論是否甚至應兌現了該請求,如果是,則應採取什麼程序,因為這似乎是一項危險的操作,需要進行大量測試。
從“但是只是出於好奇”中刪除“但是”,所以對我來說這只是“出於好奇...”,但這似乎是一種消極的攻擊性否定。小話,大區別。
AiliuiadhpCMT完成。
除了這個出色的答案外,我還建議OP下次“親自”進行澄清,以便肢體語言和語氣可以幫助另一方了解您只是在查詢信息而不是而不是指責或其他任何事情。
https://en.wikipedia.org/wiki/Non-apology_apology“如果”道歉是一種經典的非道歉,很多人對此的反應很差。
Kate Gregory
2017-06-19 23:20:39 UTC
view on stackexchange narkive permalink

您的同事告訴您:

  • 沒有預構建的腳本可以執行此操作
  • 做到這一點不僅僅是腳本的簡單問題;而是您需要非常確定自己不會破壞所有數據

,而且您全都在指責,將自己的電子郵件中的一些內容粘貼回給他們,以證明由於沒有腳本,所以沒有流程,這顯然意味著任何人都可以做自己喜歡的事並隨意改變領域。這使我生氣過,並就你抄送其他各種人在它的上面。當您的高級同事試圖讓您挺直時,您進入了一種將同事保持直挺的方式,其中包括“冷靜”,“笑臉”和“就是”。

盡快道歉。請勿使用“僅”,“僅”或“說明”一詞。請勿使用任何表情符號。以“ I”開頭的句子。強調您不會破壞數據完整性。感謝您的同事在繼續運行腳本之前提醒您可能出現的問題。通過詢問您的同事何時有空與您合作來解決“確保可以更新標識符”問題,或者重申在進行更多操作之前,您將與該經理會面,以此作為結束語。

評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/60821/discussion-on-answer-by-kate-gregory-co-worker-overreacts-to-request-for-clarifi)。
我認為您可能對OP所說的內容了解過多。“這顯然意味著任何人都可以做自己想做的事並隨心所欲地改變領域”。←這是從哪裡來的?
Xavier J
2017-06-19 22:36:14 UTC
view on stackexchange narkive permalink

在出現混亂的第一個跡象時,您應該拿起電話或安排一次Skype會議。東西很容易在翻譯中迷失-我不能推定,但是如果電子郵件兩邊的母語是英語,那就更有理由拿起電話來工作了。

不幸的是,電子郵件交換是在周末進行的,我們彼此之間是遠程工作。
這很有趣,因為Skype每天都在工作。
您也可以通過電子郵件發送會議要求。在某些時候,試圖將所有通信都放入電子郵件交換中會適得其反……這就是為什麼您最終訪問此站點。
繁榮!電子郵件(或與此相關的短信)異常失敗的另一種情況。
@XavierJ,是的,Skype每天都在工作,但是當此人處於離線狀態時,除了發送電子郵件外,您別無選擇。:)
@AddictedWithOracle不,您發送一封電子郵件,說:“我們可以在XX:XX AM / PM進行Skype澄清嗎?”如果此人與您在同一辦公室,則與您發送的會議請求沒有什麼不同。
如果可能的話,避免在周末發送電子郵件/工作的另一個原因。
@DavidK Ohhhhhhhh,是的!但是,即使在一周中,也存在時區問題。
@DavidK,好點了。我有在周末發電子郵件清理星期一工作的壞習慣。
“這很有趣,因為Skype每天都在工作。”-並非每個人都能擁有一個互聯網連接,它使Skype通話比通過令人費解的聲音片段混亂得更多。
-1
-1
之所以選擇手機或面對面的手機是一個不錯的選擇,是因為它可以使人們建立人與人之間的聯繫。處理電子郵件要困難得多,但可以付出努力。第一步是使交互一對一。在與許多抄送人(尤其是面向過程的人)進行電子郵件交換期間,許多人傾向於防禦。丟臉的可能性以及無法大聲思考的壓力使某些人只想按書做所有事情。OP必須隨著時間的推移發展這種關係,以重新獲得她的信任。
以我的經驗,電話/ Skype /任何形式的通話都是最糟糕的通信方式,原因是通話質量低,即使沒有語言障礙也難以理解。郵件可以讓您有時間閱讀,重新閱讀,使用谷歌搜索含義,在您的感情受到傷害時冷靜下來以及校對不要說一些您應該對自己說的話。唯一的事情是,人們實際上必須要做上述所有事情,而不是盡快使“對手”失望。Skyping無法解決問題。這裡的另一個錯誤是在只涉及一個人的情況下向許多人發送郵件,這是電話通話的最大福音
@AddictedWithOracle Protip-避免像使用表情符號那樣使用表情符號。甚至您的表揚似乎也有些粗魯/屈從於您的表述方式...
如果語言問題是溝通問題的原因,那麼現場進行交流可能會使情況更糟(因為這樣人們就沒有時間在字典中查找內容了)。
Sierra Mountain Tech
2017-06-19 23:08:11 UTC
view on stackexchange narkive permalink

我已經花了很多年在Outlook收件箱中工作,我想我可以提供一些建議。

我將首先回答您的第三個問題。

這樣可以避免嗎?

儘管與您聯繫的人很粗魯,但“ you”始終需要盡可能地專業。請記住,所有發送的電子郵件都會被永久記錄下來,這可能會成為審查時間或問題日後緊張的重點。

過去10年來,我通過電子郵件處理過許多沮喪或無禮的人,但是最好的方法始終是專業的方法。

要與正在回答您“澄清”問題的人打交道,您應該始終道歉並表示感謝。這有兩個目的。第一個是化解任何日趨緊張的情況,第二個是將進一步的對話引向更為文明的話題。

示例:“對不起,如果我說了些讓您不高興的事情。我只是想澄清一下,可以更好地了解情況。感謝您的澄清和時間。祝您有愉快的一天。“

有時候,您可能想用一些機智的話回覆或“貼在他們身上”,因為您認為他們應該得到一封苛刻的電子郵件,但從長遠來看,始終最好保持專業水平。

不要讓一封電子郵件對您的工作造成負面影響。

我怎麼說?

在您上一次回復之前,我認為您的談話還不錯。我認為其他人可能已經得出了一些結論,即與某些開發人員打交道時,他們不需要跳槽,而是可以做到。他們可能對他們的工作非常敏感。

但是,在那之後,當涉及到您的最後答复時。

簡單:是的。

即使其他人對您“無禮”,以實物回應永遠不會受到青睞。

有時您會想自己“我發送的電子郵件不會冒犯我”,但這不是寫電子郵件的最佳方法。進一步考慮以下方面:您正在向經理甚至經理髮送電子郵件。這是您應該重點注意的措辭和技巧。在99%的情況下,它的效果與預期的相反。說“別否定”,將您的措詞改成不太針對閱讀電子郵件的人,而更籠統。例如:“我不是說我否定的意思”。確實,您發送的整個最後答復是各種各樣的。很多不幸的措辭。任何人都會以錯誤的方式使用它。

這時我該怎麼辦?

發送道歉電子郵件將是一個不錯的開始。您可以這樣說:“對不起。我並不是想表現出粗魯的態度。將來我會更加小心我的言語。”

有些人不能如此輕鬆地得到安撫,

說了這麼多,您很可能會從中恢復過來,並且在幾週/幾個月內沒有人會記住它。只要聽我說的關於“永遠專業”,問題就可以解決。

謝謝你你能解釋我可能說錯了嗎?
@AddictedWithOracle:我在“我說錯了嗎?”問題的答案中添加了更多上下文。
謝謝,是的,我對她的冗長回應有些不高興,所以這是故意讓她煩惱並揭露她反應過度的一種嘗試。事後看來,這是一個不好的反應。無論如何,在她做出冗長的回應之前,我很好奇我可能說錯了什麼。
@AddictedWithOracle:導致您最後一次回應的對話並沒有把所有事情都告訴我。我認為其他人可能已經對某事感到惱火,並把挫敗感帶給了您。可能以為他們很清楚,並試圖解釋一下,但有點。
@AddictedWithOracle我認為您似乎並沒有真正注意到她對是否應執行此更改的強烈擔憂,並直接詢問了一個可能毫無意義的問題(如果已決定不應在此更改中進行此更改)。第一名)。
@LailaAgaev,在表示沒有為此目的構建任何程序之後表示了自己的關切,然後後來自相矛盾。
@AddictedWithOracle:我認為您不理解某些措辭上的區別。“我們沒有為此準備好的自動程序”是指事物的用戶方面。他們沒有IT部門之外的客戶或員工可以輕易使用的東西來更改相關字段。然後他們說他們有一個僅供開發人員使用的程序,用於進行一些更改。(很可能在發生錯誤的情況下),但是創建一個允許用戶對該字段進行更改的程序會帶來一些最好避免的問題。
-1
我幾乎不喜歡所有關於`的事,如果我說了些讓您不高興的事,我感到抱歉。我只是想澄清一下,以便更好地了解情況。感謝您的澄清和時間。祝你有美好的一天。`嘗試'“”對不起,我讓你不高興。我不了解情況。現在,我知道[您從該人那裡學到的東西。]感謝您的澄清和時間。“對不起,如果不是道歉,我很抱歉。。“度過美好的一天”通常被認為是開除;在某些團隊中,它的字面意思是“走開”。
@Kate Gregory:我的所有電子郵件都以“祝你有美好的一天”結束。如果有人認為“離開”,那麼該人還有其他問題需要解決。我在電子郵件中選擇的用詞很少遇到問題,在大多數情況下,我遇到遇到問題的人是因為他們的日子不好過。話雖如此,我相信我可以坐在這裡思考一個完美的句子,但是我想說明一個觀點而不是提供一個完美的答案。
“對不起,如果我說些讓您不高興的話。”有條件的道歉根本不是道歉,而這將責任推給了接受者。“我道歉”既必要又充分。
不要再發送道歉郵件。郵件是第一時間造成問題的;下次您直接與對方通話時,請解決。
WernerCD
2017-06-20 07:02:37 UTC
view on stackexchange narkive permalink

在不研究已經回答的問題的情況下,我只想補充一下我認為是“對話”中至關重要的部分,這些對話可能已經被忽略了(我沒有看到這一點,至少不是這樣)脫穎而出,截至發布此答案為止):

目標/包含的會話受眾

僅用於澄清我的部分:

  • 當您“最初”詢問時,是與“客戶”在一起的,並且碰巧在電子郵件中包含“同事” ...
  • 對於客戶而言,您沒有“準備生產”的功能
  • 當您“進一步”詢問時,您刪除了客戶並將對話移至“團隊+經理”
  • 您確實開發了一個“東西”程序...
  • 您擁有的“東西”還沒有準備好客戶。

因此,原始答復是給客戶的(“我們什麼都沒有”),後來的對話是沒有客戶的(“我們有,但是距離生產還很遙遠”)...

因此從技術上講,兩個答案都是正確的:對於客戶,您沒有程序。對於內部使用,您確實有一個程序。

在此線程的其餘部分中,我認為我沒有看到過這樣的問題:對話A與對話B的受眾不同……會創建100%正確的不同答案。

可以根據受眾(內部,客戶A,客戶B,投資者)的不同方式回答相同的問題(“我們有流程嗎?”) ,等等)。

您在內部所說的內容可以-並且應該-與外部傳達的內容有所不同。而且,如果您想分開來看,這種情況有很多不同的組-僅在這個問題上-應該以不同的方式處理:

  • 客戶
  • 1-1澄清(經理:讓他們自己,不要包括我)
  • 團隊
  • 團隊+管理
  • 團隊間

我敢肯定,如果您四處詢問,您會找到許多跨越國界並造成嚴重破壞的對話的例子。

還請注意,當RP變為私有狀態時,RP從“程序”切換為“過程”,這似乎在該消息的後半部分(健全性檢查等)中進行了描述。
@Izkata是的,有些措辭和術語有些混亂(不同的“語言”,即:客戶,程序員,經理,發帖人的ESL,雙方的ESL,跨越邊界的術語,即:程序,過程等)。..這就是“我的澄清”所在的位置:我正在嘗試壓縮我“聽到”的內容,以查看它是否與“所說”的內容匹配。電話遊戲是PITA。
原始問題的好答案。用戶的需求和用戶的需求是完全不同的,有時最好只是對他們“撒謊”。作為團隊的一部分,OP應該做到這一點。
@polku我不認為這是“說謊”。可能是圍繞這個問題而展開的,但我不認為這是在撒謊...公司尚未發布(甚至以beta形式)該“過程”的“程序”。在幕後和引擎蓋下,有一個“程序”,該程序有錯誤,不可靠,未經測試等,但是絕不影響“客戶準備”。僅僅因為您有一個內部工具/ API /流程...並不意味著該公司擁有那些可供客戶使用的工具/ API /流程。
如果密切相關,我也認為“需求”與“需求”是不同的話題。在這個答案中,我所關心的只是“對話”,即目標受眾,參加者等。在任何生活中,您都必鬚根據誰在進行個性化定制對話...是所有者,經理,客戶,管理員...您可以與每個小組進行不同的交談-並獲得不同的答案,每個小組的回答都是100%正確。如果可以的話,應根據那些需要和需求量身定制對話。
user71684
2017-06-21 07:10:49 UTC
view on stackexchange narkive permalink

我認為問題在於,越高級的開發人員認為您理解她在說什麼,但是從您的角度來看,您不理解並且需要澄清。

她的回答“我們已經有進程等”的措辭和混淆都非常差,這就是您在stackexchange上表達的意思。您並沒有對流程等提出質疑,只是感到困惑並想了解,但是從她的角度來看,您與她處於同一頁面,並且對她的建議提出質疑。

相反,的意思:如果是這種情況,那麼我們可能需要為此創建一個新程序。我們可以在星期一在測試環境中進行測試,然後讓“業務用戶”在投入生產之前進行驗證。請讓我知道您對此的想法。

從她的角度來看,您正在設定繞過她的資歷的基調。而是應這樣表述:“ RP,您認為我們應該為此創建一個新程序嗎?”這樣可以保持她在談話中的資歷,同時確保您被認為是積極主動的。您仍然會誤解她,但是至少可以使您更好地理解她的想法,而不是看起來像在挑戰她,這會更好地定下基調。

許多開發人員(以及一般人)認為他們的措辭非常清楚,並希望每個人都能立即理解。但是實際上,他們編寫的所有內容都是模糊的,沒有上下文。這裡似乎是這種情況,因此您只需要處理它即可。為了保留她的資歷,請嘗試將問題更多地定為問題。只有當她指責您做您未曾做過的事情時,您才能為自己站起來。始終設法首先使你們兩個都在同一頁面上。

gnasher729
2017-06-21 14:51:18 UTC
view on stackexchange narkive permalink

仔細閱讀該對話後,我會說您將自己的立場放到了正確的位置。

您收到客戶的請求,並問了一個有更多經驗的人該怎麼做。有人告訴您,沒有自動方法可以做到這一點。

然後,您沉迷於waaaaaaay,提議應該創建一些軟件來執行您想要的操作。看,那絕對不關你的事。如果您要創建某些軟件,請諮詢您的經理,解釋為什麼需要該軟件或對您有所幫助,經理會弄清楚該軟件的成本和收益是什麼,以及該列表的價格如何優先事項。

到那時,所有警報鈴都在經驗豐富的開發人員的腦海中響起。她知道您有問題,而且絕對沒有業務意識。她知道,如果您嘗試繼續前進,可能會造成重大損失,並且由於您被證明沒有商業意識,所以這是合理的恐懼。因此,現在她告訴您:在與經理交談之前,請勿觸摸任何東西。

然後出現了一個更大的虛假情況:您將部分響應發送給了經理。那就是你破壞人際關係的方式。

我建議向她發送一封電子郵件,您將與您的經理討論與該客戶的關係,並為將電子郵件及其部分答案發送給您的經理道歉,並說這是錯誤的,您不會再這樣做。

這樣您就知道自己做了什麼:問題不是您侮辱了她,或者您做了她侮辱的事-她在資歷和經驗上都領先於您,您可以別侮辱她,你只能讓她對你笑。您所做的只是讓她頭疼,因為她突然不得不面對一個經驗不足的同事,她擔心她會做一些真正愚蠢的事情。

“建議創建某些軟件” –我個人無法從實際使用的“我們可能需要”一詞中讀取“我們應該”(既不是純英語,也不是受RFC啟發的字眼)
@HagenvonEitzen即使OP提出了創建軟件的時間表(“在周一的測試環境中”),這看起來也不是嗎?我猜想RP在她看到“星期一”一詞後就擔心了。
Bernhard Barker
2017-06-20 20:06:31 UTC
view on stackexchange narkive permalink

我認為您最初的澄清要求一般來說( 很好)(如果僅因為它可以歸因於“發生溝通不當”,您就應該在以後避免這種情況)。

您的上一次答復有很多錯誤。不要試圖減輕心情,尤其是不要因為對她的評論不屑一顧或告訴她如何感受。

從答復中刪除所有這些內容,您會得到一些完全合適和專業的東西:

嗨,RP。感謝您的澄清。我們明天可以討論這個問題,以提出解決方案。

在這一點上,,我可能建議您什麼也不做,並確保您以後的互動完全專業。

您還可以考慮道歉:

對於我的上次答复很抱歉。

不要試圖以任何方式為其辯解,不要說“對不起,如果是,那就別說了。”


您的經理的答复並不意味著他/她站在了自己的一邊,他/她只是認為所有其他人都不需要閱讀。

bluegreen
2017-06-20 20:16:01 UTC
view on stackexchange narkive permalink

首先,我同意經理的觀點,從澄清開始的對話應該是1:1或1:1 + Manager。

我認為這裡的一些問題越來越嚴重,而且更常見的是,將電子郵件視為非正式對話。請記住,當您發送電子郵件時,您並沒有傳達人們在談話中沒有意識到他們用來確定人的情緒的語調,肢體語言,面部表情等...文字笑臉並不能真正彌補這一點。電子郵件應保持正式格式,以免誤解。

我意識到這之間存在時差,但是我認為清除此問題的最佳方法是通過電話/ skype通話。面對面的對話可以比電子郵件鏈走得更遠,在這一點上,我懷疑這只會使事情變得更糟。

jpalala
2017-06-21 12:50:13 UTC
view on stackexchange narkive permalink

在我看來,您對某些陳述的措詞方式似乎只有一些問題,似乎是他們的錯。我唯一的建議實際上是避免澄清時使用引號和笑臉,而要保持專業水平。知道您的位置會有很大幫助(菲律賓語中為“ kung pano lumugar”)

我知道有時規範可能不夠準確,因此您應該與主管或高級負責人核對一下規範是什麼關於以及應該如何解決。

但是,由於您處在公司世界中(我認為),因此您需要遵循類似角色概念的概念-設定您的職位和所處的位置,並以一種表明自己的方式寫作“不是在推動事情,只是在要求澄清-基本上,您需要以既有主見又沒有乾擾的方式來表達事物。

另一件事-除非您像超級親密的朋友,否則永遠不要笑臉。可以放進去以使人感到溫暖,但這會降低專業音調。

還不清楚那件事是做什麼的,因此您可以在發送電子郵件要求澄清之前做更多的研究-人們通常沒有耐心回答那些小問題為此,但是如果您通過下載可能已經在此處等待進行一些修改的腳本進行了一些初步的研究,就會更願意提供幫助。

對您有利,您試圖弄清楚這些事情您本可以一對一地完成操作,而不是放下笑臉並提出指控。作為遠程工作的一部分,您需要設置視頻通話來確定一個人對事情的看法是明確的,並且正如其他人已經評論過的那樣,有些事情一對一比較好。

無論如何回到您的問題上:

  1. 我說錯了嗎?

    • 不,您只是跳過了仔細閱讀他們在說什麼並理解每個要點的內容。
  2. 這時我該怎麼辦?

    • 我不建議辭職,我建議與HR(如果有的話)或其他同事討論如何更好地措辭
  3. 如何避免這種情況?

    • 感謝他們的建議,然後開始工作,把它當作工作的另一天。只需關注對您的期望(特別是如果您還不熟悉該公司的話)。順便說一句,我是菲律賓人,但是你來自哪個國籍都沒關係
  4. ol>
Abhinav Galodha
2017-06-20 21:29:36 UTC
view on stackexchange narkive permalink

在戴爾·卡內基(Dale Carnegie)“如何贏得朋友和影響人”的啟發下,一些對我有用的黃金法則。

  • 每個人都需要了解所有人都是不同的,需要讚賞工作場所的多樣性,並珍視每個人帶入團隊的想法能量
  • 此外,每個人都喜歡被重視,而人類不喜歡被不喜歡和指責(尤其是在一個小組中)
  • 您不想與不了解您的人交談。
  • 要記住並相信的重要一件事是每個人正在努力以正確的方式實現共同目標。所有團隊成員(開發人員,BA,QA,PM,經理,業務用戶,產品負責人,董事...)都在嘗試他們的最佳來實現並超越客戶的期望。

我說錯了嗎?
如果您考慮 RP 的觀點,並從她的回應中考慮以下問題。

  • 您可以更好地嘗試聽和理解RP正在通信的上下文。試著讓自己穿上RP鞋並考慮一下。她正試圖向一個對要求知識不多的人解釋,您似乎通過在電子郵件中引用她來挑戰她的陳述。
  • 她已經解釋了代碼中的問題,並明確指出建議不要在生產中運行代碼。您可以嘗試了解本程序需要做一些工作,然後就部署到Prod中的計劃提出建議。

對RP的第一反應可以做得更好?

  • 不要在電子郵件中復制經理和整個團隊。您的經理是正確的,澄清應該是1:1。原因是您需要確保可以消除兩個人之間的困惑,並且不要使任何人看起來像個壞人。

  • 只要有可能,請嘗試與該人交談通過與他們進行肢體交談,電話,聊天或電子郵件(1:1)。

“對RP的第二響應”可以做得更好嗎?

  • 也如其他答案所述,請不要嘗試在電子郵件中使用 calm down 之類的詞。您試圖讓RP感到她已經對您的回答感到不高興,並且處理不當。

  • 您需要同情她並理解她為什麼寫這樣的電子郵件。儘管我認為她也不太滿意她的回答,但您也可以控制自己的寫作,因此請嘗試同情她,讓她覺得如果您處於她的位置,您也會以同樣的方式做出回應。如果您能意識到自己對她的理解,那麼至少可以使她聽您想說的話,並且更願意討論。

我在這一點上是這樣做的嗎?

  • 您正確執行的第一件事是讚賞此電子郵件通信是一個問題,您已開始探索其他意見和改進方法。
  • 嘗試與RP和團隊進行強調,傾聽並認真理解他們要傳達的內容。
  • 與RP進行非正式的1:1討論,並討論工作或非工作內容。嘗試與RP建立關係,並讓她了解您為什麼以這種特殊方式做事
  • 尋求她過去對這個問題的反饋,並嘗試保持靈活性並提供可行的解決方案。你們都需要容納彼此的觀點。
  • 與您的經理交談,並讓經理知道您意識到這種經歷是一種學習經驗,也是您學到的東西。此外,請徵詢經理反饋,以了解事件及其如何得到妥善處理。
  • 了解團隊文化以及團隊喜歡如何工作。每個團隊都是不同的,您需要靈活地適應自己。調整後,您需要學習如何說服您的團隊了解您的想法。

如何避免這種情況?
由於我之前也有類似的工作經歷,因此我可以與您建立聯繫。我可以說這不僅是觸發此類電子郵件的事件,而且還主要是一系列事件,最終人們在電子郵件中消除了沮喪。儘早觀察並撲滅大火,以免造成更大的事故。也許過去發生過類似的交流,但RP卻沒有以這種方式做出回應。嘗試通過經常與他人交談來獲得反饋,最重要的是,如果您閱讀了我的其余文章,那麼您會發現一些有用的提示。

我希望與您的團隊建立更好的關係並最終保持聯繫為您的團隊願景做出貢獻。



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