題:
初級同事在客戶面前質疑我的方法
Shru
2014-07-30 02:10:57 UTC
view on stackexchange narkive permalink

My junior colleague and I attend a meeting every week. Last week I was giving a presentation about the proposed work to be done and my colleague questioned my methodologies in front of the client. At the time I was clueless what to do.

I am still not sure how to handle this kind of situation. What should I do in a situation like this? What should I tell the client/my colleague?

Has anyone had an issue like this?

您是否與同事做了任何準備工作以準備會議?您為客戶誇大的地方是否正當地引起您的疑問?
客戶的反應是什麼?保持客戶的信心/支持與確保初級同事保持一致很重要。
****評論已刪除****:請避免使用評論進行擴展討論。相反,請使用[聊天]。在Workplace SE上,評論旨在幫助改進帖子。有關更多詳細信息,請參見[什麼不是“註釋” ...](http://meta.workplace.stackexchange.com/questions/72/what-c​​omments-are-not)。
十 答案:
Kaz Dragon
2014-07-30 12:05:53 UTC
view on stackexchange narkive permalink

“我很高興您提出這樣的要求,” 。

但是處理此問題的一種方法可能是成為下級同事沃森的夏洛克。就像該行已編寫腳本並已交付一樣,以便您可以向客戶解釋其原理。誰知道呢,證明您的產品已被深深地證明甚至會有所幫助。

當然,如果適合這種情況。

@JamesRyan同意,如果這是作為回答客戶問題或客戶帶來的新信息的一部分而發生的,情況將有所不同。我讀過OP表示不是這種情況,因為如果作為對客戶問題的回應的一部分提出了初中生要提問的觀點,那麼如果我是問這個問題的人,我會提到它。意見分歧是件好事,應予以鼓勵,在客戶面前的意見分歧通常是有問題的。
@nomen這是一個很大的問題之後,您如何跟進?我問是因為每次嘗試進行演示時都會發生類似的事情
@l46kok:這取決於上下文。我寫了一個涉及其中一些問題的答案。
****評論已刪除****:請避免使用評論進行擴展討論。相反,請使用[聊天]。在Workplace SE上,評論旨在幫助改進帖子。有關更多詳細信息,請參見[什麼不是“註釋” ...](http://meta.workplace.stackexchange.com/questions/72/what-c​​omments-are-not)。
HLGEM
2014-07-30 02:50:27 UTC
view on stackexchange narkive permalink

The last time I saw this happen, the response was to stop the meeting temporarily, take the person out to some place private and explain to them that they had better not do that again and if they did not agree (as the person who did this didn't) then they would not be returning to the meeting or, depending on the level of insubordination in the private meeting, their job. As it turned out that person was immediately transferred to another team and never allowed to be involved in anything to do with that project again.

Since you didn't do it at the time, you (and/or you boss) need to have a private sit-down meeting with the person and explain how you need to present a united front to the client no matter how much you disagree in private or their job will be at risk because things like this can cost you the client. This is a firing offense but someone junior may not have realized that so give him the benefit of the doubt this once. Make sure you clearly and unambiguously explain what will happen if he does it again though. Check with your boss and HR if necessary before the meeting to explain the process when a person has a performance problem (which this is and a very serious one at that.) There is no coding skill in the world that can make up for this lack of judgement around a client. The junior dev needs to understand that this is not acceptable in any way shape or form.

Make sure you also go over the presentation with the team beforehand, so any objections to what is being presented can be raised at that time. Do not take a person who raises an objection and will not agree with the end decision to any client meeting concerning that topic.

Make sure your whole team understands that actions have consequences and that in front of the client is not the time or place for disagreement. However, when they have objections beforehand, listen to them seriously and make changes if need be. Or if you cannot for other reasons, explain why. Often the junior people are not aware of the political considerations that might make a technically less than optimal choice the right one for the situation. Juniors need to be taught to think in terms of more than the technical when deciding. The only way they can learn that is if you explain the other considerations.

There seems to be some feeling that this is harsh. It is not. I am not suggesting firing the guy this time. I am suggesting that he needs to clearly understand that actions have consequences and one of the potential consequences of this type if action is getting fired. It is being kind to the guy, helping him realize the inappropriateness of his actions before he gets himself in a situation he can't extricate himself from.

Some bosses will be far less forgiving of this sort of thing than others and no one likes to be made to look bad in front of the client. Nor do businesses like the client to hear their dirty laundry. Professional disagreements have their time and place, the sooner this guy learns that the better for him personally.

This is actually mentoring the junior not being harsh. In reality, the world can be a harsh place. There are things that are not tolerated in business that would have been OK in school. Many young people don't realize this at first and I have seen several get fired for things far more minor than this because the person who should have taken him aside and explained this to him did not.

As senior people it is partly our job to make sure that juniors are clear on what is and is not acceptable behavior in that particualr workplace. Yes the OP erred in not making it clear beforehand, but that is an error that can't be corrected for this guy, only for the next one. In the meantime, the junior person needs to know why this is unacceptable and what the consequences of continuing to do things like this are.

The consequences may vary from company to company, the OP should talk to his boss or HR about their process. Some places give several chances, some go right to formal HR documentation of a performance problem and some may not particularly care (probably few given that this happened in front of the client). But by all means the Junior person needs to be talked to about why this is a problem and what the possible consequences of continuing to do this are.

In closing, even a person with less than a week's experience should know you never bring up a difference of opinion in a client meeting. That is workplace 101, day one stuff. I agree the senior should have done a better job of prepping him, but some people are so convinced they are right, they don't get that there is a time and a place.

Lastly, before counseling someone on an issue of performance, it is always a good idea to have a talk with HR about what types of things can and cannot be done or said. Anyone in a leadership role should have this conversation long before they have a particular problem employee to deal with.

請避免使用評論進行擴展討論。相反,請使用[聊天]。在Workplace SE上,評論旨在幫助改進帖子。有關更多詳細信息,請參見[什麼不是“註釋” ...](http://meta.workplace.stackexchange.com/questions/72/what-c​​omments-are-not)。
這個答案無論多麼徹底,似乎都有一個嚴重的“空白”,因為它毫無區別地承擔了高級合夥人的權力。但是,初級,其他合夥人可能擁有別人所缺少的某些技能/知識,否則就不需要他們參與。根據我在類似的客戶談判中的經驗,考慮這一點至關重要(為什麼不這樣做,如果不知道的合作夥伴沒有其他合作夥伴的信號,可能會導致談判無意中陷入“危險水域”並淹沒整個項目。考慮[編輯]以“填補空白”
將此歸結為一點,初級同事的薪水應(部分)抵消因不當行為而導致的收入損失的風險。在幾乎所有諮詢組織中都是CLM / CTM。
@ArtTaylor CLM和CTM是什麼意思?
@AnthonyGrist“限制職業移動”和“限制職業移動”。
nomen
2014-07-30 09:11:18 UTC
view on stackexchange narkive permalink

這很簡單。如果大三學生提出反對意見,並帶有實際的看法,那麼您應該以專業的態度行事,說您不知道,然後將其放在下次會議的議程上。

此處的理由如下:

  1. 如果有人提出嚴重反對意見,則客戶將希望查看解決方案。

  2. 能夠立即提供解決方案的您有兩個基本選擇:

    • 嘗試虛張聲勢,否則將問題打折。對客戶來說,這看起來不太好。他們想要解決方案。通過拒絕提供解決方案,您已經有效地結束了談判。

    • 擱置該問題。這提供了解決的希望,即使目前尚不解決。這為您提供了繼續會議的機會,討論了您要處理的其餘業務。這對每個參與人員都是有效的時間利用。這也是假設性的。您正在傳達“我們下次會告訴您”。這實際上是一種折衷。 “我們現在不能給您解決方案,但是我們可以盡快解決。”他們可能會接受它或離開它。那仍然比替代方案更好。這也是一個承諾。信守諾言是贏得信任的方法。

  3. ol>
@nomen:僅供參考,您將獲得很多人的反對,他們認為專業的工作是偽造您不具備的信心。我猜這是非匿名投票有用的一種情況,因為(a)認真誠實,(b)願意省略不便的信息,(c)致力於明確地撒謊,這是值得我們將來參考的情況。實踐。這些東西中的任何一個對於不同的人來說可能都是“專業”一詞的固有部分。如此勇敢地將其發佈為觀點的晴雨表。
狂熱經濟學對為什麼人們如此害怕說“我不知道”做了一個很棒的播客。非常值得一聽:http://freakonomics.com/2014/05/15/the-three-hardest-words-in-the-english-language-a-new-freakonomics-radio-podcast/
嘿,伙計,雖然這對您來說可能很簡單,但假設對所有人來說都是直接的,則不是最佳方法。為了滿足我們的[備份準則](http://meta.workplace.stackexchange.com/questions/255/faq-proposal-back-it-up-and-dont-repeat-others),請考慮[編輯]解釋為什麼這是正確的答案。希望這可以幫助
Jonast92
2014-07-30 02:26:20 UTC
view on stackexchange narkive permalink

在這種情況下,您可以告訴他們,您將在演講後與同事討論此問題,並且如果遇到問題,您一定要與您的客戶面對面。

這是簡單的方法,因為這顯然會使您不舒服。

但是,作為專業人員,您應該能夠解釋和支持您所做的每個決定,這是您工作的一部分。但是,如果您的同事可能會導致您的客戶對您的服務失去信心,則可能不應該在客戶面前這樣做。您未來甚至更好的方法,假設您的決定在演示之前會受到質疑並為之做準備。

在客戶面前不是意見分歧的地方。應該討論計劃,證明計劃是合理的,並且能夠經受嚴格的評估-但初級人員如果不了解這些問題要在後台散列,而不是在前台和/或害怕,則不應參加客戶會議/或工作客戶端。
-1
這就是我要處理的地方-關於您的方法論和方法,您應該沒有絕對不能證明任何人對其進行辯解的理由。這樣,當Jr對此提出疑問時,您就有機會證明自己已經考慮了替代方案,並表明了為什麼選擇的方法是正確的方法。通過一次充分準備的會議,甚至可以建議Jr提出一些客戶可能正在思考但不願提出的問題。
Clair
2014-07-30 21:10:08 UTC
view on stackexchange narkive permalink

在這種情況下該怎麼辦?我應該告訴客戶什麼?

在不知道具體情況的情況下,例如方法論的哪一部分被提出,以及質疑是什麼,很難給出100%的答案。

如果這是一個簡單的案例,使您對產品/設計/方法等充滿信心,並且可以清楚,簡潔地說明您提出的方法為何正確,那麼您就可以在沒有提出建議的情況下順利地克服這一問題對客戶的負面看法,同時又不會因“我們以前曾考慮(反對)這種方法”而對您的誠信造成太多損害,但是出於(這個/那個/另一個)原因,我們確定了這個(您的方法)是基於(最好是基於證據的輸出)的最佳方法。“您可以在回答之前加上“您加入我們之前(同事姓名)之前”的內容,並以(我很樂意在會議之外討論其他任何問題'),這應該會阻止您的同事進一步介入,並希望向客戶介紹合作團隊提供優質產品的觀點。甚至還可以通過進一步展示產品的耐用性和適當的設計來帶來意想不到的好處。

或者,如果您認為該問題可能有一些值得探討的問題,或者根本無法以簡明的方式提供合理性(允許您迅速返回正軌),那麼我的建議是向客戶建議(無論如何)您對詢問是否有效的信念)該觀點值得一提。讓客戶參與其中,然後達成協議,何時達成協議以及如何與客戶溝通。涉及此特定項目的後續會議,在隨後的計劃會議中添加為議程項目,期權評估文件等。請務必詢問客戶他們希望如何參與此過程,並明確說明將考慮所有選項,並建議最能滿足其要求的選項。這應該使客戶放心,您作為提供者的誠信以及您沒有“隱藏”任何東西。

從這一點開始,您應該可以從現在開始繼續進行演示和開會,但是,如果所質疑的方法的一部分是破壞交易的方法,或者您的方法論的其餘部分取決於該方法,那麼您可以承擔請記住,您的方法論陳述的可信度可能會因尚未解決的問題而受到損害。

我應該告訴我的同事什麼?

在會議之外(我不建議您在會議中途拖拉某人進行口頭打擊),花點時間向您的同事解釋一下無論提出的觀點是否值得,面對會議的客戶都不適合提出關注/反對意見。

由於他們是初級員工,所以有很多因素在起作用;對面向客戶會議的協議不了解,對技術/專家知識“印象深刻”的願望,對所投放產品的了解不足等。所有這些都可以並且應該盡快解決。在下次與客戶會面之前,可能且至關重要的是。

毫無疑問,大三學生犯了一個菜鳥錯誤,但值得牢記的是他們是菜鳥。也許可以從這種經驗中吸取一些教訓,例如;

  • 初中生是否適合參加會議?如果質疑是關於產品的設計,那麼表明他們對產品的了解還不夠。上帝只知道我已經開發出了一些解決方案,從技術設計的角度來看,對於剛畢業的剛畢業的新畢業生來說,它們必須看起來很瘋狂。但基於許多其他因素,例如實際上最適合業務規則,客戶端的技術限制等。在我讓任何人參加有關我們產品組合中特定產品的會議之前,請確保他們對設計,方法論和其背後的原理有足夠的了解,以便能夠參加。

  • 有會議準備嗎?我知道有人討厭“會議前會議”。但是,確保每個人都有適當的準備參加面對客戶的會議,確保所有人都同意將要討論的內容並對“建議”有信心,這只是很好的常識,並且將來會避免發生此類事件。 / p>

我個人建議,如果沒有惡意的意圖(恐怕你要當法官),只是警告下級犯錯誤,並解釋您和公司未來的期望應該足夠了。相信我,您不能給他們任何修飾,可以擊敗他們可能遭受的自我鞭degree程度,尤其是如果他們是新角色(我是根據一些個人經驗講的) 。他們可能會為自己的徹底災難而感到沮喪和沮喪,但這很可能使他們感到沮喪,但是這些教訓可能會在他們的整個職業生涯中繼續存在,並且在以後的工作中會做得更好。長期。

通過確保填補知識空白,為初中生提供支持,對他們進行培訓,了解他們對客戶會議的協議和期望,並確保他們提出問題不是一件壞事,只要它在正確的時間和正確的地方。你永遠不會知道,他們的問題可能值得……

嗨,克萊爾,讓客戶參與審核過程是一個好主意嗎?
嗨,@Shru。這可能取決於您與客戶的關係。如果他們大量參與產品的設計/交付,請讓他們參與審核。但是,如果他們希望您打包並交付,只是向他們提供保證,確保您已審查了可能的選擇,並且對原始建議或相反的建議的替代方法是更好的方法充滿信心。
John LeDuc
2014-07-31 00:05:10 UTC
view on stackexchange narkive permalink

我去過那裡,了解您的位置。目前,您可以採取三種行動。

1)如何恢復客戶信心

2)將來如何實時處理

3)如何管理初級同事幫助為將來的活動做準備

這是我的方法。

1)如何恢復客戶的信心

與客戶進行跟進會議,討論這種互動,以確保他們仍在與客戶打交道。專業的人。您很幸運,因為您每周有一次會議。在某些情況下,這種情況發生在幾個月的銷售推銷中,您可能再也沒有機會挽救了。

讓客戶知道您的團隊願意接受同事的反饋和挑戰在所有級別上,這都是同事發表講話的原因之一。當然,這是假設情況是正確的(在某些地方是不正確的,哈)。

這是一個讓客戶知道您的團隊正在吸收他們以及內部項目成員的反饋的機會。考慮。詢問他們是否對這兩種方法有任何想法或擔憂,以及是否有偏好。以此為契機繼續出售您的團隊。但是,不要過多地關注您和同事之間的互動。

向客戶保證,正常情況下,這些討論是在內部進行的,而且這種情況很少發生-但是請不要給與別人更多的機會。認為這是應受懲罰的罪行。這將以比您想像的更快的速度嚇scar客戶。

2)將來如何實時處理這種令人毛骨悚然的建設性反饋行動。

我會使用上述方法-並在心理上進行實踐-因此,當一個人在“公開”中受到挑戰時,回應是自然的,而不是腳本化的。另外,您不會在大燈前被吸引,像鹿一樣。

我會像這樣向同事講話:“我喜歡您在本次會議上的反饋。讓我們離線進行討論,以便我們進行更詳細的介紹。”

然後向客戶發送,“ [$ Client],如果我們推進議程並在以後跟進有關細節,您有任何異議嗎?我不想失去這次會議的動力,但這可能值得探討。”

3)如何管理下級同事,以幫助為將來的參與做準備

如果沒有更多有關所涉及的每個人之間的關係的詳細信息,這很難回答(正如其他人所指出的那樣)。

但是關鍵是要嚴厲對待,特別是如果這是此人第一次發生這種情況。

在專業責罵中,民間有很長的記憶,除了您可能會失去寶貴的資源這一事實外,還有一天,這個“初級”人可能會增加體重。與您將來的演出工作有關的決定。如果一個人是定期更換的團隊的承包商,或者誰想要成為某一天的承包商,則尤其如此。

-1
Vality
2014-07-30 15:23:23 UTC
view on stackexchange narkive permalink

我意識到您可能對此同事的行為感到很不高興,這可能嚴重損害了會議的利益,但是這很可能是由於此人的無知而不是任何不當行為或惡意,尤其是因為他們正如您提到的初級員工。

在近期內,您可能要做的最好的事情就是記錄異議並安排其與客戶討論,這很不方便,但不會破壞您與客戶的關係只要您能正確處理以下會議。

但是從長遠來看,您必須教給這位同事他們所犯的錯誤,首先,我將假設這是他們第一次這樣做,就像重複一遍,他們已經被告知這是一種簡單的違紀行為,應該這樣對待。項目出於某種原因增加價值和價值不要因為犯了一個單一的社會錯誤而被扔掉。相反,請採取長期選擇,並幫助教會該團隊成員如何在客戶面前表現。

我個人一開始對如何在客戶面前採取行動一無所知,而在很大程度上保持沉默在會議期間,但是隨著時間和鼓勵的投入而做出更大的貢獻,我無法想像狠狠地冷落甚至開除這個人會幫助任何人。如果他們有分歧,應該把它們帶給您或在客戶會議背景之外的經理那裡表達他們,會議就是這種爭論的錯誤地方。但是,還要強調一點,這不僅表示您不關心他們的意見,而且只有在以適當的方式給出建議的情況下,您才可以適當考慮。

Colton Allen
2014-07-30 23:43:07 UTC
view on stackexchange narkive permalink

我當然不是專家,但是我確實在強調“團隊合作”但所有事物都來自一個來源的工作場所有經驗。您的標題是“初級同事正在客戶面前質問我的方法”。這不是“您的”方法,而應該是“團隊的”方法。說你是一個團隊是一回事,實際上要成為一個團隊是另一回事。您想稱呼他們。

團隊在各方共同貢獻的同時灌輸共同犧牲的感覺。如果決定採用的是“您的”方法論,那麼您不應該聲稱自己是一個團隊。我只是認為,如果您的團隊在工作的某個方面存在分歧,那麼您應該在解決該問題之前解決該問題,然後再參加會議。討論過。多數規則。

記住團隊是平坦的。如果您的辦公室是分層結構的,則應重新考慮使用“團隊”一詞。這只會使您的員工感到困惑,並在工作場所造成更多的摩擦。

雖然似乎確實沒有必要採用軍事風格的等級制度,但我認為完全沒有資歷概念的100%扁平化團隊很可能會忽略現實,例如,請參見以下奇妙的答案:[我如何克服“多年經驗”的要求職位?](http://workplace.stackexchange.com/a/1485/168)
@gnat我就像人們稱呼我我是一位員工。我並不在乎什麼管理風格。
我提到的答案不是在談論頭銜,而是在談論誰更了解:_“判斷只是經驗,愛迪生是通過經歷失敗而不是通過一些原始的缺乏經驗的技能發明的。”
團隊團結很少。運動隊,海豹突擊隊,有效的工程隊-不平坦。團隊可以是扁平的,但這不是團隊定義的一部分,在業務或技術工作中也不常見。
您生活在哪個怪異規則中?商業不是也不應該是民主國家。
-1
@Spike0xff當我在高中時期參加體育運動時,我們總是“提名”一位領導者。並非通過任何正式程序,而是總會有一個人脫穎而出。在扁平的結構中,優秀的領導者會根據其領導素質而崛起。就韋伯斯特而言,團隊的定義無論如何與商業或軍事都不相容。僅僅因為每個人都錯誤地使用它並不會突然使它正確使用。希望這可以清除一切。
這個項目也很有可能由獨立的團隊成員在不同的部分上工作。例如,一項調查由一個人負責抽樣,一個人負責權重,一個人負責實地調查,等等。在這裡,“我的”很合適,我可以想像一個在負責抽樣(但希望進行更大的事情,例如加權)挑戰加權方法-無論是好是壞。
嘿@ColtonAllen。 merriam-webster.com說,一個團隊是“一群一起工作的人”。我是否訪問了錯誤的網站?這與業務不兼容嗎?在我的工作中,我們經常團隊合作。海豹突擊隊是人,很確定他們可以一起工作。我們是否對“一起”一詞的含義不同意?它沒有說“團隊是扁平的”或“團隊選擇自己的領導者”。你真生氣對於您在這方面的任何痛苦經歷,我深感抱歉,但我認為您過於籠統了。有時候一個壞經理只是一個壞經理。
@Spike0xff嗨,斯派克。忽略響應的被動積極性,團隊就像您所說的“一群一起工作的人”。我與程序員而不是經理一起工作。我喜歡絕大多數的經理,但他們只是分配工作給我。他們沒有積極參與這項工作,只是進行採購。說經理是團隊成員,就像說安排FIFA比賽的人是團隊成員一樣。
James Kingsbery
2014-07-31 22:21:49 UTC
view on stackexchange narkive permalink

其他人已經討論瞭如何處理您的同事,所以我不會在這部分內容中加進去。

我想說,您應該對著鏡子看一眼。如果您是高級同事,則應該已經討論了該方法論,以及您打算如何與參加會議的任何人(包括您的下級同事)向客戶介紹該方法論。這樣,您就可以在會議開始前消除任何異議(是否應提出異議)。

此外,由於您是高級同事,而且(從問題來看,)會議,您應該非常清楚會議的目的是什麼以及您試圖擺脫會議的意圖。我參加過公司間會議,很明顯,這是一次集思廣益的會議,在這種情況下,人們彼此矛盾是很自然的。另一方面,如果這只是一個演講或推銷活動,那麼你們兩個都應該非常清楚誰在說什麼,你們每個人將扮演什麼角色,等等。

Tom Au
2014-07-31 21:47:04 UTC
view on stackexchange narkive permalink

從一個層面上講,您的下級同事不應該在客戶面前“糾正”您。 (最多,他/她應該私下與您談一談。)但是根據您自己的承認,您“毫無頭緒”。這讓其他人進入了權力真空狀態。

您需要做的第一件事是加快學習材料的速度。否則,您基本上是無能為力的。

一旦您控制了局勢,您將可以更好地控制您的同事。或在需要時向上級尋求幫助。

我認為您可能會誤解了這個問題,OP對會議的主題並不是一無所知,但對於如何解決青少年的從屬問題卻一無所知。


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