A团队的开发人员向其mgr解释问题,mgr与B团队的mgr进行对话,而后者则向其开发人员解释:错误沟通的秘诀
—尼古拉斯·弗兰克(Nicolas Frankel(我相信@Home很长时间)(@nicolas_frankel) 2016年9月28日
这篇文章解释了此推文背后的原因,此推文一时兴起。
面对现实,大多数开发人员(包括我自己)更喜欢处理代码而不是与人打交道。 但是,在与其他开发人员进行交流时,我们拥有共同的上下文和理解,因此无需进行很多解释。 所有专业工作(例如律师或土木工程师)都是相同的。
现在,如果我必须与另一个团队的开发人员(或其他技术人员)进行交流,我将直接与他联系并进行聊天。 有时,管理人员需要参与,因为他们必须了解和/或做出决策。 在这种情况下,我会与该开发人员和我们的两个经理组织一次会议,我们将聊天,达成共识,然后向经理解释这些内容,让他们做出决定(也许会稍微影响他们... )。
花很多时间试图向我的非技术经理解释核心问题,让他在我不在场的情况下与另一位经理打交道,最后让另一位经理与他的团队一起处理问题,这真是疯狂。 任何玩过中国窃窃私语的孩子都知道,传递消息的多层中介会导致乱七八糟。 如果每个层都可以理解的简单消息失真了,那么当它变得复杂时会产生什么结果呢? 何时不是每个玩家都能完全理解它?
在我职业生涯的早期,我就已经处理过这种“过程”。 我认为有两个原因:
-
筒仓结构
-
因为公司通常按专栏组织(首席财务官,首席营销官,首席技术官,首席人力资源官等),所以沟通主要是垂直的-从上到下(几乎没有反向)。 由于目标完全不同,因此很难信任另一个团队。 因此,这是一种使事物处于控制之中的方法...或者至少是假装这样做。
中层经理
-
工厂需要中层管理人员来处理装配线工人,而大多数传统公司则完美地反映了该组织。 在高科技公司中,劳动力是由受过良好教育的开发人员组成的:对中层管理人员的需求远远没有那么高。 因此,他们必须向组织证明其“价值”或暴露为无用的。 将自己设置为必要的中介已成为生存策略。
我天真地希望,在所有敏捷项目中,这种行为都会消失。 因此,请想象一下这周发生在我身上的惊奇。 在向我的经理解释了有关沟通效率的上述部分之后,我轻轻地(但坚定地)告诉他,改变这一点并不在他的能力范围内。 我再次指出,如果没有人做任何事情,事情将永远不会改善,但没有结果。
如果您发现自己处在这种情况下并且无法改善情况,我建议您用脚投票。 就我而言,与这个特定团队的合作接近尾声,因此我的问题将很快得到解决。 恐怕这个``过程''根深蒂固,以至于在不久的将来无法改变-如果有的话...
翻译自: https://blog.frankel.ch/making-sure-inter-teams-communication-doesnt-work/