与他人融洽相处的艺术

团队反模式

Jilbert Ebrahimi摄于Unsplash

介绍

作为Web开发人员,我们在极其复杂的环境中生活和工作。 我们所依赖的语言,工具和技术是复杂,复杂的,并且通常需要详细的了解才能被有效利用。 此外,要成为一名优秀的Webdev,就需要一种多学科的方法,该方法应结合编程,计算机科学,UI / UX技能以及特定领域的知识来开发有用的应用程序。

但是,我们面临的最复杂和最具挑战性的任务是团队合作! 团队合作需要两件事-团队合作和工作。 DUH。

韦伯斯特将团队定义为“从事工作或活动的许多人”,并将工作定义为“在身体上或精神上发挥作用,特别是在出于目的,强迫或必要的情况下持续努力”。 至少可以说,尽管这些定义肯定是准确的,但似乎过于干燥。

我对团队的定义是“一群个人一起工作,为实现共同的目标而合作”。 同样,我对工作的定义是“为实现目标必须执行和验证的一系列活动”。 换句话说,当团队是执行工作的团队时,工作就是要做的。

最终,团队团结一致完成工作才能实现目标。

照片由Jeffrey Lin在Unsplash上​​拍摄

回顾的重要性

由于人类本身是复杂的,常常情绪激动且不合逻辑,因此作为团队工作的生物需要计划,努力,同情心以及对反模式的理解,这可能会对团队的绩效产生负面影响,进而影响团队实现目标的能力。

将团队反模式识别为敏捷回顾过程的一部分,可以帮助团队进行自我纠正。 在回溯过程中,敏捷团队通常会过多地关注其工作的技术方面。 尽管这当然很重要,但通过查看工作流程以及团队成员如何进行交互以完成工作,可以实现更大的收益。

随着项目的进行,以这种方式使用反思的团队往往会变得更强大,更有生产力和更成熟,这是因为除了生产成果之外,还经常注意他们的工作方式。

团队反模式

作为人类,我们经常从错误中学到比成功更多的东西。 正如我们依靠编程反模式的研究来防止错误的重复一样,出于同样的原因,团队反模式的研究也是有用的。

下面介绍的反模式并非旨在全面列出所有可能影响团队绩效的反模式。 但是,它们是我发现最有害的。

反模式#1-客户不知道他们需要什么!

对于新开发人员,有时甚至是更有经验的开发人员,通常希望向客户指示要求和功能,而不是相反。

这种态度出现的最常见原因是客户不被视为团队的一部分。 请记住,就像Webdev是构建应用程序的领域专家一样,Customer是业务流程以及正在构建要解决的问题的领域专家。

将客户视为不连贯的信息源(和资金!)是对宝贵资源的极大浪费。 将客户作为团队成员并积极参与需求收集,设计,增量测试和部署策略,可以帮助开发出更强大的产品并赢得未来项目的信任。

反模式2-我的路还是高速公路!

作为专业人员,我们已经投入了大量时间,精力和资本来建立我们的职业生涯。 因此,我们为自己的工作感到自豪,并为交付的产品感到自豪。 这很好,直到坏为止。

一位智者曾经说过:“骄傲落在倒下”。 当我们的自豪感阻碍了我们认识到我们创造的技术或解决方案可能不是最佳解决方案时,我们就成为了前进的障碍。

情况变得更糟。 当这种情况发生时,我们不仅降低了产品的价值并可能损害团队实现目标的能力,而且我们还阻碍了团队中其他成员的工作。 愿意接受建议并与团队中的其他人合作以发现解决方案,这有助于团队中的下级成员获得经验并在团队成员之间建立更牢固的关系。

这触及了团队合作的核心,即通过协作和合作来构建比单独完成的更好,更强大,更快的产品。

反模式3-房间中最聪明的人

您与某人共事了多少次,使他们进入房间时安静(不是因为受到尊重,而是因为他们在讨论中占主导地位而又不尊重他人)导致? 这些人可能很聪明,但他们常常忘记总是有一个更聪明,更有经验或拥有更深的领域知识的人。

1970年代,罗伯特·格林利夫(Robert K. Greenleaf)定义了仆人领导的概念 仆人式领导将领导的方向从指挥和控制转变为首先具有以下素质的仆人:

  • 倾听
  • 同情
  • 疗愈
  • 意识
  • 劝说
  • 概念化
  • 预见性
  • 管家

倾听同理心是仆人领导者的前两个​​素质,这绝非偶然。 领导他人并帮助他们成长和进步,需要成为积极的倾听者,理解他们的立场,理解各种观点具有价值,然后指导而不是指示团队。 指导并不意味着强迫您的队友采用您的职位,而是集体找到一个可以找到最佳解决方案的职位。

反模式4-我可以做到!

在团队中工作意味着贡献更大的利益,并随时准备在需要时帮助您的团队伙伴。 但是,过度帮助存在不利之处。 即,变得过度投入。

过度投入的结果是,您将无法完成任务或做得很好。 无论哪种情况,不仅会阻碍您的进步,而且也会阻碍整个团队的进步。

这并不意味着您不应该帮助您的团队伙伴,而是意味着您必须以一种不会损害项目一个方面的利益的方式这样做,并且您需要能够说出“不”不会破坏您与队友的关系。

您可以用来解决此问题的策略是:

  • 在您的日程安排中预留时间专门帮助团队中的其他人。 将此作为应急方案纳入项目计划。
  • 当对您方便时,不要害怕帮助他人,而不是对他们方便时。 在宏项目级别上,优先考虑队友需求对工作量的影响。 换句话说,关键路径是什么?
  • 上下左右交流。 不仅要对请求说“不”,还需要团队和团队领导的帮助和意见,以确定您应该在何时何地提供帮助。

反模式5-让我们在以后的Sprint中修复它!

但丁在《地狱》中写道:“但愿所有进入这里的人们都放弃了”。

很简单,技术债务是机构拖延的一种形式。 它通常是由于允许近期约束覆盖长期要求而引起的。 技术债务的问题在于它的作用是成倍增加的,因为随着时间的推移,它会导致许多变通方法,这使得解决原始问题变得更加困难。

任何团队面临的最困难的任务之一是适当地确定任务,功能和修复的优先级,以便消除或最小化技术债务,而不是制造技术债务。 这是使Web开发像科学一样具有技巧的一个方面。 确定将任务推向更高速度的影响可能并不总是那么容易。

但是,一些可能有用的经验法则是:

  • 如果是错误,请立即修复。
  • 如果用户不要求它,则不要内置它。
  • 如果现在很痛苦,那么将来的痛苦程度将无穷无尽

反模式6-弗雷德错了!

可以说这是团队反模式中最有害的,因为它会导致团队内部的衰败和功能障碍。 每个团队在项目生命周期中都会遇到某种程度的分歧。 使成熟的,高绩效的团队与功能失调的团队区分开的原因是,他们如何应对。

功能失调的团队通过分成不同的派系来处理分歧,这些派系将观点的技术差异提升为个人和情感战争。 这使团队破裂,这意味着不同派系正在沿着通往目标的不同途径开展工作。

更重要的是,这意味着营造一种不健康的氛围,从而导致有毒的工作场所。

成熟的团队知道成功有多种途径,而最好的途径通常是思想和观点的结合。 成熟的队友不会互相攻击。 他们找到共同点,并从此开始进行工作,以解决分歧并找到最佳解决方案。

包起来

David Clode在Unsplash上​​拍摄的照片

您可能已经注意到,所有这些反模式都以人及其互动为中心。 这是因为故障很少是技术的唯一结果。 相反,失败是计划不足或执行不力的结果,其根本原因在于团队合作的方式。

了解团队如何出错可以让您识别出何时开始出现问题,从而可以采取适当的措施来防止失败。

最重要的是,在团队中工作时要开放,与队友坦诚地交流好坏,保持同情心,互相帮助,将自我放在门上。 简而言之,当仆人领袖。