即使您的工程团队中有许多不同的人物,他们可能也知道如何相互合作。 他们共享了截止日期和目标,了解了项目的技术细微差别,并看到了同事的最佳工作经常在不间断的情况下发生。
更大的挑战是与非技术团队进行沟通。 通常,这些部门不知道开发人员喜欢如何工作。 此外,他们不知道他们的许多问题已经被回答了多次。 结果,您的开发人员发现自己对同事提出的问题感到不知所措,他们所有人都迫切需要他们的帮助才能越过终点。
这种情况的问题是双重的。 对于初学者来说,当您的程序员承受着放弃他们为帮助销售人员或市场营销人员所做的工作的压力时,结果就是大量的生产力损失。 最重要的是,您组织中的团队最终会觉得这种无所事事的方法是协议,可能会使每个人都感到沮丧。
作为工程经理,您如何解决此问题? 答案当然不是为了公司而告诉程序员处理它。 相反,这里有一些提示使 跨团队交流 更轻松,更多 对您公司的所有人都有利。
与您的团队一起制定参与规则
同样,此处的解决方案不是告诉您的工程师不惜一切代价帮助销售和市场营销人员。 同时,如果您在没有团队投入的情况下为技术要求创建了准则,那么对整个团队都是不公平的。 尽管您应该对团队的工作有很好的了解,但是您的开发人员甚至更加了解他们当前正在解决的项目和挑战。
与您的首席工程师坐下来检查他们当前的工作量。 根据您的发现,请他们帮助您创建并记录参与规则,以便公司在需要程序员帮助时可以参考。 对于某些团队来说,这可能意味着在24小时内回答一个初始问题。 对于其他人,这些交往规则可能会更加严格。 好消息? 不仅有一个正确的答案。
这样是否可以阻止不同团队中的人们走到程序员的办公桌旁提出紧急要求? 可能不会。 同时,该文档将帮助每个人围绕 跨团队交流 ,并且在每个开发人员找不到无法拒绝同事的方式时,也会给每个开发人员一些参考。
任命团队负责人处理请求和共享信息
每年,我们都会在Stack Overflow上对开发人员社区进行调查,涉及诸如他们最喜欢的技术和首选的工作环境等主题。 今年,来自世界各地的100,000多名开发人员参加了会议。 我们的内部员工以及任何想 浏览数据集 。
尽管面临的挑战是因为我们能够获得这些见解,所以 每个人 至少可以想到几种在工作中利用它们的方法。 这就是我们的数据团队实施员工提交请求的过程,同时还明确了主要联系人是过程的开始。 他们还创建了内部文档,以便公司的每个人都可以在寻求帮助时知道要包含多少信息。
Stack Overflow的数据科学家茱莉亚·席尔格(Julia Silge)说,这些指南有助于她的团队发挥更多的咨询作用。 她补充说:“它们使我们能够交流一些我们可以做和不能做的现实。” “他们鼓励个人提出具体的具体要求,并向我们提供信息,我们需要优先考虑自己的时间。”
让您的开发人员负责
确保开发人员拥有处理请求所需要的内容很重要,但是确保他们对同事的同情心也是您的工作。 这篇文章中的概念不应该使您的团队在同事被打扰时立即与他见面。 如果程序员确实要抨击某人,那么请您大声疾呼,并与该人合作,避免将来再遇到这种情况。
发生这种情况时,您有两种选择。 您可以通过解释他或她要做的事很多。 尽管确实如此,但这不一定是正确的方法。 随着时间的流逝,您的同级经理将很难就未来的问题咨询您。
如果您发现程序员对某人有好感,请务必及时解决。 请花几分钟与该人聊天,以了解事情发生的原因,可能做的不同以及将来如何处理类似的情况而不会对不知情的队友感到沮丧。
是否想找到使跨团队知识共享更加容易的新方法? 详细了解团队的堆栈溢出。