Toc
  1. 保持技术水平
  2. 调试功能异常的团队:基础知识
    1. 不出货
    2. 人们的戏剧
    3. 过度劳累导致的不快乐
    4. 合作问题
  3. 护盾
  4. 如何做出正确的决定
    1. 建立数据驱动的团队文化
    2. 发挥自己的产品肌肉
    3. 展望未来
    4. 审查你的决策和项目的结果
    5. 对流程和日常运行进行回顾
  5. 好经理,坏经理:避免冲突,驯服冲突
    1. 处理冲突的注意事项
  6. 充满挑战的局势:团队凝聚力破坏者
    1. 辉煌的混蛋
    2. 非沟通者
    3. 缺乏尊重的员工
  7. 高级项目管理
    1. 项目管理经验法则
      1. 这并非是敏捷项目管理的替代品
      2. 每个季度每个工程师有 10 个生产工程周
      3. 预算 20%的时间用于在董事会范围内进行通用的工程维护
      4. 在你接近截止日期时,你的工作就是拒绝
      5. 使用加倍规则进行快速估算,但按计划时间估算更长的任务
      6. 对你带给团队的东西有选择性的估计
  8. 评估自己的经历
Toc
0 results found
第五章:管理团队
2020/07/20

从管理一个或两个人到管理整个团队仅几步之遥,但是管理团队不只是管理个人。至此,你的工作已经改变。实际上,在超出此级别的每一步中,你可能会遇到一套完全不同的要求和挑战。随着职业的发展,最难准备的是要开始做完全不同的事情。你可能会相信,管理是你作为高级工程师开发的技能的自然发展,实际上是一整套全新的技能和挑战。

这是我用来管理团队的职位描述,我称之为“工程主管”:

工程负责人将花费更少的时间来编写代码,但他们仍然从事小型技术交付品,例如错误修复和小型功能,而不会阻塞或减慢其团队的发展。除了编写代码外,他们还负责识别过程中的瓶颈和团队成功的障碍,并清除这些障碍。

预计担任此职务的人将对整个组织的成功产生重大影响。特别是,担任此职务的领导者有能力确定最有价值的项目,并使他们的团队专注于这些项目。为了使团队保持专注,工程主管将与产品主管紧密合作,以管理项目范围并确保满足技术交付要求。除了专注于团队之外,他们还能够确定团队的人员需求,并计划和招募人员来满足这些需求。

工程负责人是独立经理。他们很乐于管理具有不同技能的团队成员。他们将期望清楚地传达给所有团队成员,并频繁地征求和提供个人反馈(而不仅仅是在审核期间)。除了强大的管理技能外,工程负责人还担任其产品组(支柱)技术路线图的负责人。他们清楚地向其主要合作伙伴传达了时间表,范围和风险,并在清晰的时间表上领导了重大计划的交付。此外,他们确定战略技术债务的领域,进行成本 / 收益分析以解决该债务,并向管理团队传达建议的时间表,以优先处理此问题。

我们已经介绍了管理个人的基本知识,但是现在让我们讨论领导整个团队(尽管仍然是技术人员)需要做什么。

本章的主题集中于人员管理之外的工作。因为新经理很容易过度专注于与人相关的任务,所以我想提请你注意管理团队的技术,战略和领导力方面。

成为人的经理

我最初是在一家抵抗传统经理的公司中担任非正式团队负责人的。在担任该职位一段时间后,我该成为正式的人事经理了。经理角色对于公司来说是新手,整个组织都感到有些恐惧。在将工程人员划分给管理人员时,我们权衡了谁会对新结构感到不满。不是每个人都为自己的前同事工作感到自在,但我很幸运。我现在管理的大多数人与我一起工作了足够长的时间,以至于我现在是他们的经理的想法还可以。他们的支持帮助了吨。这并不完美,但是我收到的回扣并不重要。

在这个新职位上,我发现自己管理着一些比技术上要高级得多的人。这是我第一次不能依靠拥有最丰富的知识作为主要的领导工具。这不是简单的冒名顶替综合症。我知道我已经脱离联盟了。他们知道我不在同盟之列!当然,我现在管理的两个最高级的工程师都意识到这很尴尬。我们谈论了每个人的工作要做,而我的任务是尽我所能帮助他们成功。

一名工程师在不断提供反馈的过程中继续帮助我。我努力学习了什么对这个人很重要,以及他们需要什么才能成功。另一个工程师在适应我担任他的经理时遇到了麻烦。首先,他调到了另一个团队。几个月后,他有些 con 悔,他回到了我们的团队并同意与我一起工作。事实证明,成为一名优秀的经理并不是要拥有最多的技术知识。支持人员的工作对于管理成功至关重要。

伯大尼·布朗特

保持技术水平

这本书是给工程经理的。这不是一本通用的管理书。工程管理是一门技术学科,而不仅仅是一套人际交往能力。随着职业的发展,即使你可能停止编写代码,你的工作也需要你指导技术决策。即使是负责系统设计的架构师或负责细节的其他高级技术人员,作为团队的经理,你也有责任让这些人对自己的决定负责,确保决定通过技术上的努力测试,并已在团队和业务的整体环境之间取得平衡。多年来从事这项工作所磨练的技术直觉对于指导该过程非常重要。

此外,如果你真的希望赢得工程团队的尊重,他们必须认为你在技术上是可信的。没有技术信誉,你将面临艰巨的挑战,即使你可以在一家公司中担任领导职务,你的选择也会受到限制。在努力成为一名成功的工程经理时,请不要低估技术技能的价值。

当然,你必须学习如何平衡。弄清楚如何在过渡到管理时保持技术水平是一项艰巨的工作。成为经理所带来的新职责(更多会议,计划,管理任务)不会使自己专心于编写代码。当你被拉到一百万个方向时,可能很难找出如何保留在代码中。

但是,在此级别上,如果你不遵守代码,则可能会冒险使自己在职业生涯中过早地过时。你可能正走上管理职业道路,但这并不意味着你应该洗手技术责任。实际上,我在工程主管职位描述中特别提到,我希望该级别的经理能够实施一些小功能和错误修复。

如果你只是做些小事,为什么还要编写任何代码呢?答案是你需要在代码中保留足够的时间以查看瓶颈和流程问题在哪里。你也许可以通过观察指标来看到这一点,但是当你自己积极编写代码时,感觉到这些问题要容易得多。如果构建速度真的很慢,或者部署代码花费的时间太长,或者调用是一个噩梦,那么经验丰富的工程师在淘汰琐碎的编程任务时会遇到困难。想象一下,这对于你的团队成员而言是多么令人沮丧!当你自己遍历代码时,识别技术债务并优先处理技术债务要容易得多。

此外,作为一个团队的经理,你将被要求帮助指导系统中可能做和不可能做的事情。当你的团队的产品经理有一个疯狂的主意时,如果你有信心评估在给定系统中实现该功能的容易程度,那么管理起来就容易得多(尽管要提防过分自信!) 。强大的工程经理可以确定通过系统实现新功能的最短路径。正如你在担任技术主管期间所学到的那样,复杂项目管理的关键部分是充分了解系统的各个部分,以确定最佳的实施途径。你越了解系统中的代码,确定此路径就越容易。

令人遗憾的是,有些公司并没有真正扮演“几乎没有时间编写代码的经理”的角色。这些公司清楚地划分了管理和技术轨道,以至于经理们立即开始由大型团队直接向他们报告。因此,经理的工作变成了行政和人事管理职位,这些经理最终会在晚上和周末(如果有的话)抢占技术时间。如果你的公司是这样,我的建议是保持技术水平直到你真正掌握了编写代码和设计系统所要学习的知识,然后再决定是否要将职业转变为管理。当你停止编写代码时,很难弥补浪费的时间,而且如果你在职业生涯中过早这样做,你可能永远无法获得足够的技术知识来超越中层管理人员的角色。

如果你对管理人员完全保留在代码中的建议感到震惊,请不要担心!在后面的章节中,我将详细讨论不再存在于代码中的意义,并且我相信这一点已经存在。但是现在,请尝试保留其中一些。我保证,这会使你的工作更轻松。

调试功能异常的团队:基础知识

有时,你会发现自己管理的团队失灵。他们不断缺少可交付成果。人们不开心。他们不断退出。产品经理感到沮丧。团队对产品经理感到沮丧。也许他们只是在工作中缺乏精力,或者对目前的项目缺乏热情。你可以说出什么地方不对,但是你不能完全确定它是什么。一些基本的功能障碍可能会渗入技术团队。我将在这里简要介绍这些功能障碍,以便你知道要查找的内容以及如何解决它。

不出货

你可能不会认为这是功能障碍。例如,也许你的团队处于对新问题的深度研究模式。但是,即使只是进行初步研究的团队,即使进行研究的团队也通常具有目标和可交付成果。总体而言,当人们设定小目标并定期实现这些目标时,他们会感觉良好。

作为团队的经理,你可能担心过分用力,因此让他们错过最后期限而不必大惊小怪。诀窍是学习如何平衡推动团队和阻止团队。如果你仍在为团队编写代码,那么这可能是个精打细算,帮助团队实现其可交付成果的好时机,或者是真正深入研究项目的一部分并与负责帮助的工程师合作了解情况。

有时,团队之所以没有交付,是因为他们一直在使用的工具和流程使他们难以快速完成工作。一个常见的例子是你的团队仅尝试一次或少于一周一次发布对生产的更改。不经常发布的版本可能会隐藏痛点,例如发布周围的工具差,大量的手动测试,功能太大或开发人员不知道如何分解工作。现在你正在管理团队,开始着手消除这些瓶颈。

在我的上一份工作中,系统的关键部分曾一度仅每周发布一次。这些发布耗时数小时,而且非常痛苦,而且经常遭受人们试图在最后时刻进行更改而导致测试失败并拖慢了所有人工作的痛苦。我们所有人都认为这是一个问题,为了使发布速度更快,团队共同努力改善了代码库和自动化程度。在过程结束时,我推动团队进行改进,使我们每天都能发布。这种变化对团队的影响是立竿见影的。事实证明,发布可能是资源争夺的重点。当人们争夺稀缺资源时,团队成员之间的冲突和不快乐几乎是不可避免的。使代码运送资源少得多的稀缺性立即改善了团队士气。

人们的戏剧

有时,我们会让自己在那绝妙的混蛋上停留太久。你知道,你认为无法替代的那个人是因为他的生产力和聪明才智,但他不是团队合作者,会让周围的每个人都不高兴。(有关这种有毒员工的更多信息,请参见“聪明的混蛋”。)这种情况的不太严重的版本是鼓动戏剧,沉迷于负面经历或在闲聊上花费太多时间的人。并针对他们玩我们的游戏。

你必须勇敢地将人们的戏剧化为萌芽。可以向你的经理寻求帮助,这是可以的,尤其是这是你第一次这样做时,但是请注意,与上司相比,你的经理实际上可能更难应付。她没有看到对团队动态的直接影响。她只是看到有人把事情做好。准备与员工和你的老板进行一系列对话。转移到其他团队可能会解决问题。

消极的人比愚蠢的人更容易对付。向他清楚地表明行为必须改变,提供清晰的示例,并在事情发生后迅速提供纠正性反馈。有时候,消极的人只是不开心,而最好的办法就是帮助他保持良好的状态。你必须为此结果做好准备。其他时间,此人不知道自己对团队的影响,因此,只需进行快速聊天就可以减少事件发生。

请注意,口头表达不佳的人不要长时间呆在团队中。这些能量吸血鬼创造的那种有毒戏剧即使是最好的经理也很难与之抗衡。在这种情况下,最好的防守是好的进攻,而迅速采取行动至关重要。

过度劳累导致的不快乐

这个问题很容易解决。通常,因劳累过度而导致的不快乐是你可以解决的问题的根源。例如,如果过度生产是由于生产系统的(不稳定)造成的,那么作为经理,你的工作就是放慢产品路线图,以便暂时关注稳定性。明确警报,停机时间和事件的措施,并努力减少它们。我的建议是在每次计划会议中将 20%的时间用于系统可持续性工作(“可持续性”,而不是更常见的“技术债务”)。

如果由于时间紧迫的紧急释放而导致劳累,请记住两点。首先,你应该扮演拉拉队长。支持团队,但是需要他们的支持,尤其是通过自己的工作来提供帮助。点晚餐。告诉他们,你感谢他们的辛勤工作。明确说明,推送后他们将有明确的休息时间。暂时使它变得尽可能有趣。有时关键时期可以作为团队的纽带体验。但是他们会记住,在压力重重的时期,经理是陪在他们身边,还是在别的地方做自己的事。

第二,尽一切可能从紧要关头学习,并在下次避免使用。如果可以,请剪切功能。如果确实不现实,则推迟日期。紧缩时期会发生,但没有理由经常发生。

合作问题

你的团队与产品团队,设计团队或其他技术团队的合作状况不佳,缺乏协作会拖累所有人。这里没有快速解决方案,但是显示出改善协作的意愿还有很长的路要走。如果你还没有,请确保与适当的同龄人保持定期接触,以解决问题。收集来自团队的可行反馈,并就可能的改进进行富有成效的对话。你可能会破坏团队前的同伴,从而使情况变得更糟,因此即使你对同伴感到沮丧,也要努力保持积极和支持他们在公共场合所做的努力。

如果你的团队不能很好地合作,请考虑为他们提供一些闲逛的机会,而不必全力以赴。让整个团队共进午餐,在星期五下午早些时候下班,一起参加一个有趣的活动,在聊天室中激发一些 PG 级幽默,并问人们生活如何,这都是培养团队团结的方法。作为新任经理,我非常不愿从事这种类型的联系,但即使是大多数内向的人也希望与他们的团队保持亲密关系。假设你没有前面列出的任何“人际交往”问题,那么在此方面的小努力可以极大地促进团队的热情。

询问 CTO:管理前同行

我刚刚被提拔,使我的团队在我的另一个同行中工作,他也是一位高级工程师,他也想要这份工作。我如何确保对此进行管理,以免在继续担任该职位时不会疏远他?

这种经历可能会很尴尬,所以要做的第一件事就是承认这一点。如果你现在正在管理真正与你同行的人,请承认过渡的怪异。对这个人诚实和透明,你将尽自己最大的努力,但是你需要他的帮助。你需要他对你进行的事情进展顺利和不诚实进行诚实的对待。你将必须对他有点脆弱,因为你不会在第一时间完美。

接下来,请记住你的工作已经发生了很大的变化。作为他的经理,你现在可以超越他的决定,但是要非常谨慎地使用此功能。利用你的管理权来推翻技术决策通常是一个坏主意。抵制人们微观管理的诱惑,尤其是那些曾经与你同龄的人。即使他们不想自己成为经理,他们也会对你被“奖励”的感觉很敏感。如果你质疑他们的一举一动并尝试自己做出每个决定,那么你的敏感度将大大降低。

一个必然的结果是,在减轻人员管理的其他职责时,你将不得不放弃以前的一些工作。管理链上的每一步都意味着增加新的责任,而放弃一些旧的责任。你可以通过公开授予他们以前拥有的某些技术工作的更多控制权,从而对以前的同事利用这种情况,从而为你带来好处。这也是向更多团队成员提出新挑战的机会。尽管许多工程组织希望一级经理继续编写一些代码,但他们可能希望这些经理编写的代码具有较小的功能,错误修复和增强功能,而不是深入的新系统。

在所有这些更改中,你的目标是向团队表明你致力于帮助他们成功。你的新角色不会影响团队其他成员;它只是给你一些新的职责,这些职责要么被忽略要么曾经属于别人,然后将你的一些旧职责转移给团队的其他成员。

如果你以前的同事因为无法忍受为你而辞职,那么你的团队将不会成功。他们将对你的任何分歧或感觉到的权力争夺格外敏感。他们甚至可能会尝试破坏你的利益。选择你的战斗。从长远来看,成熟地应对这种过渡将获得回报。

护盾

许多管理建议告诉新经理,他们的一部分工作(如果有效)是成为盾牌(或更礼貌地说,是“废话大伞”)。他们应该帮助他们的团队专注于他们需要完成的工作,而不会被周围更大的戏剧性,政治性和周围公司发生的变化所分散。

我对这种管理方式有不同的感觉。我确实认为,那些不必要地接触与他们无关的有毒戏剧的团队往往会分散注意力和压力。如果你管理的是工程团队,那么他们无需担心客户服务组织中的人际事件。当我觉得自己的世界在燃烧时,我自己的团队继续顺利运作,我感到十分自豪。对于每个人来说,认识到他们可以并且应该专注于他们可能影响和改变的事物,而忽略他们不能做到的事物,是非常有价值的。通常,工作场所的戏剧性只是消遣自我的流失。

因此,是的,保护你的团队不受干扰很重要。或者换句话说,帮助他们理解关键的重要目标并使他们专注于这些目标很重要。但是,期望你可以或应该保护你的团队不受一切影响是不现实的。有时,将一些压力传递给团队是适当的。目的不是要让他们感到压力,而是要帮助他们了解正在处理的内容。极端的保护者认为,他们可以通过给出明确的目标来最好地集中精力和激励团队。但是人类通常需要某种背景来解释 为什么 已经设定了这些目标,从而确定了他们正在努力解决哪些问题。如果特定系统无法正常运行,你将在 11 月遇到运营问题,那么你的团队就应该了解这种后果。适当的上下文可以帮助团队在如何以及在何处集中精力方面做出正确的决策。作为经理,你自己要做所有这些决定不是你的工作。

盾牌有时犯下的另一个错误是否认外界存在任何戏剧。如果裁员发生在公司的另一部分,而团队却从其他人那里发现了问题,而不是使你的团队免于遭受麻烦,你就创造了一种情况,即他们觉得事情正在发生坏事,没人愿意承认。相反,如果你以直接的,低情绪的方式传达有关此类事件的信息,则可以减轻闲话并迅速消除对团队的影响。

你可能是盾牌,但你不是父母。有时,通过兼顾盾牌和导师的角色,我们最终与我们的团队建立了育儿式的关系,并视他们像脆弱的孩子一样受到适当的保护,培养和嘲弄。* 你不是他们的父母。* 你的团队由成年人组成,他们需要受到适当的尊重。这种尊重对你以及他们的理智都很重要。当你将错误视为自己的孩子般的自我延伸时,很容易将它们自己错掉,或者将自己的情感投入到自己之中,以至于你接受他们对自己的所有分歧。

如何做出正确的决定

你在团队决策过程中扮演什么角色?你知道吗?你可能有一名产品经理与你的团队一起工作并拥有产品路线图,或者你的团队致力于进行工作的一组业务功能。你可能有一位技术主管,正如我们在第 3 章中介绍的那样,他仍然对技术有深入的了解,但同时也在考虑项目管理和需要完成的工作。那么,工程经理又将你留在哪里呢?

你承担的责任比预期的要多。产品经理负责产品路线图,而技术负责人负责技术细节,但是你通常要负责团队在所有这些要素中的进度。领导的本质是,尽管你可能仅有权指导决策而不是下达决定,但你仍将根据这些决定的结果来判断自己。

建立数据驱动的团队文化

当你拥有产品或业务负责人时,她应该习惯于使用有关业务,客户,当前行为或市场潜力的数据来证明她的决定的合理性。开始将其他数据添加到混合中。例如,为该人提供有关团队生产力的数据(例如完成功能所需的时间)或有关质量度量的数据(例如,花了多少时间处理中断,或者在 QA 中或发布后发现的错误数量)。这些效率和技术数据点可用于评估有关产品功能和技术变更的决策。

发挥自己的产品肌肉

强大的领导者关心培养成功并拥有一支能够交付成功项目的团队,这意味着磨练你对客户重要内容的理解。无论你是为外部客户编写代码,为其他工程师开发工具,还是运行支持团队,都有一些小组取决于你的工作成果。将他们视为你的客户。花时间发展客户同理心很重要,因为你需要为工程师提供有关其工作的背景信息。发展客户同理心也将帮助你找出技术的哪些方面对客户有最大的直接影响,而这种理解将指导你在工程上投入什么精力。

展望未来

你需要从产品和技术的角度考虑两个步骤。了解产品路线图的发展方向可帮助你指导技术路线图。支持许多技术项目,因为它们具有更轻松地启用新功能的能力,例如,重写结帐系统以插入 Apple Pay 等支付类型,或迁移到支持通过 WebSockets 进行流数据更改的新 JavaScript 框架模型,为了建立更互动的体验。开始询问产品团队有关未来的前景,并花一些时间跟上技术发展的步伐,这可能会改变你对所编写软件的看法或操作方式。

审查你的决策和项目的结果

谈论你用来激励项目的假设是否真的成立。重写该系统后,团队的移动速度更快吗?在添加新功能时,客户行为是否按照产品团队的预测方式发生了变化?你从 A / B 测试中学到了什么?在完成项目后,很容易忘记查看假设,但是如果你将此养成自己和团队的习惯,那么你将始终从决策中学习。

对流程和日常运行进行回顾

敏捷过程通常在每个为期两周的开发冲刺结束时召开一次回顾会议,你可以在其中讨论冲刺期间发生的情况,并选择一些事件(好,坏或中立)进行详细讨论。无论你采用的是敏捷方法还是其他方式,定期的流程回顾对于检测模式和强制决策结果都具有很大的价值。团队对如何获得需求感到满意吗?他们对代码质量感到满意吗?此过程可帮助你了解随着时间的推移所做的决策如何影响团队的日常运作方式。这种方法比收集有关团队健康状况的数据更具主观性,但可以说它比许多客观指标更有价值,

好经理,坏经理:避免冲突,驯服冲突

杰森的团队劳累。每个人都知道 Charles 应该致力于大型系统的重写,但是几个月来他一直在自己的宠物项目上工作。听到查尔斯(Charles)无法使用新系统的抱怨后,杰森(Jason)召集团队,要求他们对应该删除哪些项目以减轻工作量进行投票。他们投票放弃 Charles 的宠物项目对任何人来说都不足为奇,也就是说,除了 Charles 之外,从未听说过 Jason 关于此事的任何消息,并且认为自己做对了事情的人也就不足为奇了。

杰森的团队之所以感到紧缩,部分原因是杰森似乎并没有与其他团队站在一起。他讨厌对新项目说不,但他也不要求更多人来帮助管理负载。每个人都同意杰森很酷,但要让他真正地解决冲突或做出困难的决定真的很难。结果,团队工作过度,努力确定前进的方向,并在其成员中照顾了一些怨恨。

莉迪亚(Lydia)的团队也感到不堪重负,她有自己的查尔斯(Charles)要处理。她向查尔斯许诺,他将有时间从事这个项目,但是很明显,优先事项已经改变,因此他的工作也将随之改变。在与 Charles 的 1-1 中,Lydia 解释了当前的工作量,并告诉 Charles 他的团队需要他帮助他进行系统重写。Charles 很不高兴,Lydia 对此对话并不满意,但是她知道作为团队的经理,她有责任确保他们专注于最重要的项目。

莉迪亚(Lydia)知道这个项目对团队拥有很重要,因此,在她争取更多人的同时,她确保团队知道为什么决定承担这个大项目。她与团队合作确定工作的优先级,并通过遵循一种表示选项和征求反馈的结构,指导他们解决使用哪种技术的分歧。莉迪亚(Lydia)的团队将她形容为坚强但公正,尽管发生分歧,但团队擅长克服挑战并保持良好的协作。

用这样鲜明的话说,很显然,杰森没有很好地处理冲突,而莉迪亚则在驯服它。虽然杰森的民主风格似乎应该导致一支有权的团队,但他无法拒绝任何决定或对任何决定承担责任,这意味着没有人会感到非常安全。很难知道杰森团队接下来会发生什么,因为他没有指导团队,而是由团队指导自己。

拥有一支不断吵架和意见分歧的团队会很痛苦,而且功能可能非常失调。但是,存在诸如人为和谐之类的事情,避免冲突的管理者倾向于在功能性工作关系之上主张和谐。为分歧解决自己创造一个安全的环境要比假装不存在所有分歧要好得多。

处理冲突的注意事项

不要完全依靠共识或投票。 共识在道德上似乎是权威,但前提是参与投票过程的每个人都是公正的,在各种结果中具有同等的利害关系,并且对上下文具有相同的了解。这些条件很少在每个人具有不同专业知识水平和不同角色的团队中得到满足。当团队否决查尔斯的工作时,共识可能是残酷的。不要让人们为自己知道会失败的选票做好准备,而要承担起自己提供坏消息的经理的责任。

确保建立清晰的流程以使决策个性化。 当你想进行小组决策时,小组需要有一套清晰的标准,用于评估决策。在做出决定之前,首先要对目标,风险和要回答的问题达成共识。当你向团队中的某人分配决策的所有权时,请明确应咨询团队中的哪些成员以获取反馈,以及需要向谁告知该决策或计划。

不要对沸腾的问题视而不见。 避免冲突表现出的另一种方式是无法解决问题,除非问题持续了太长时间。作为经理,如果你在绩效评估过程中给出了负面反馈,那么这对你的员工来说并不应该是一个重大惊喜。在撰写评论之前,你可能会仔细考虑过细微的差别,但是如果某人的工作存在重大问题,那么你应该在注意到这些人后立即知道它们。如果你自己没有注意到这些问题,但是在审核过程中通过几个同行的反馈了解了这些问题,那不是一个好兆头。这可能表明你没有注意,也没有在 1-1 中留出空间让团队与同事讨论他们遇到的问题。

在不求爱的情况下解决问题。 解决冲突和培养功能障碍之间有区别。你想给人们留下挫折感的空间,但要注意放任自流与真正的人际关系之间的区别。根据你的判断来决定应解决的内容和应删除的内容。要问的关键问题是:这是一个持续存在的问题吗?是你个人注意到的东西吗?这是团队中很多人都在努力的事情吗?有动力动态或潜在偏差在起作用吗?目的是找出导致团队合作效率降低的问题并解决这些问题,而不是成为团队的治疗师。

不要把它带给其他团队。 具有讽刺意味的是,避免冲突的经理经常会在涉及其他团队时寻求冲突。他们与自己的团队具有强烈的认同感,并将对外界认为的威胁做出积极反应。当出现问题时,例如跨团队的事件,经理变成了欺负者,要求其团队伸张正义,或将问题归咎于另一个团队。有时,这种行为是经理对自己团队的压抑感的出路。正如一位朋友所说:“我没有告诉我的员工他们需要改进的事情的 10%,因为我担心他们会错过有关 90%的事情的信息,所以我对问责制充满了渴望淘汰其他队伍。我真的只是希望每个人都要完全负责,

切记要友善。 想要被别人喜欢是很自然的,也是很人性的。我们中的许多人都认为,被喜欢的方式应该被看作是美好的 - 善良本身就是目标。但是,作为经理的目标不应该变得友善,而应该仁慈。“好”是礼貌社会的语言,在这里你试图与陌生人或相识相处。尼斯在说“请”和“谢谢”,并为挣扎着书包或婴儿车的人们提着门。当被问到你好吗,尼斯说“我很好”,而不是“我心情很糟,希望你别管我。” 在随意的交谈中,好是一件好事。但是作为一名经理,你将拥有更深层次的关系,而善良更重要。可以告诉尚未准备晋升的人,她还没有准备好,并提供到达那里所需的工作。领导那个人说,“也许你会被提升”,然后看着她的失败,这是不友好的。告诉别人他在会议上的行为正在扰乱小组。这很尴尬,而且不舒服,但作为老板,要进行这些困难的对话也是你工作的一部分。

不要害怕。 避免冲突通常源于恐惧。我们害怕做出决定的责任。我们担心要求太高。我们担心如果我们给他们不舒服的反馈,他们就会辞职。我们担心人们会不喜欢我们,否则我们冒险就会失败。有些恐惧是自然的,对冲突的结果保持敏感是一种明智的习惯。

很好奇。 考虑自己的行为是消除恐惧冲突的最佳方法。我之所以将这个决定推向团队,是因为他们确实是最好的决定者,还是我只是害怕如果我做出一个不受欢迎但必要的决定,人们会为我生气吗?我是不是因为与她的同事真的很难相处而避免与她一起解决这个问题,还是我只是因为我不想讨论这个问题并且可能是错的而希望问题能够解决?我是因为某个员工的日子真不好过而拒绝了他的反馈,还是只是一次过的事?还是我因为怕我告诉他他不喜欢我作为经理而拒绝我吗?考虑一下自己的行为,不太可能会发现不必要的冲突。

充满挑战的局势:团队凝聚力破坏者

建立职能团队的关键要素之一就是建立一支能够彼此幸福愉快地工作的团队。我曾经接受过一个愉快的工程团队的考验:“如果你在晚上购买比萨饼,它们会留下来并一起社交吗?还是他们会尽快出门?”

我对此有些疑问。每天都有义务将员工带出办公室的员工比那些愿意站着聊天的员工或多或少地参与其中。然而,更大的观点仍然是一个好问题。大多数胶凝的团队都有一种友情友善的感觉,可以使他们在一起开玩笑,喝咖啡,共进午餐并彼此友好。他们可能有自己尊重的义务和工作之外的激情,但他们并不认为自己的团队是他们渴望逃避的事情。

此处的真正目标是心理安全 - 即,一个团队的成员愿意承担风险并在彼此面前犯错误。这是一个成功的团队的基础。凝聚团队的工作始于建立导致心理安全的友好关系。你可以花一些时间来认识人,并向他们询问他们的课外生活和兴趣,以此来鼓励这一点。让他们分享自己舒适的分享。询问孩子的生日聚会如何进行,滑雪旅行如何,马拉松训练如何进行。这不仅仅是空谈。它促进了亲和力,增强了人们作为个人的意识,而不仅仅是匿名的齿轮。

除了你个人培养关联性之外,你还希望团队之间具有自己的关联性。当企业谈论以“适合文化”为目的的招聘时,他们通常意味着他们想聘请可以与之友好的人。尽管这可能会带来一些不良后果,例如歧视,但它来自一个明智的地方。友好的团队会更快乐,更快地凝结并倾向于产生更好的结果。我的意思是,你真的要每天与一群讨厌的人一起上班吗?

这就是为什么破坏团队凝聚力的人如此成问题的原因。他们几乎总是表现出使团队其他成员难以感到安全的行为。我们将这些员工称为“有毒的”,因为它们往往会使与他们接触的每个人的效率降低。迅速与他们打交道是做好管理的重要组成部分。

辉煌的混蛋

有毒员工的一个变种是精明的混蛋,正如我们前面所讨论的,该混蛋会产生个别大的结果,但由于自我驱动,她在周围的几乎每个人中都充满了恐惧和厌恶。这位出色的混蛋所面临的挑战是,很长一段时间以来,她的光彩就可以使她获得丰厚的回报,并且她像救生筏一样紧紧抓住它。承认世界上除了纯粹的智慧或生产力以外还有其他价值,这将挑战她在世界上的地位,并且往往对她来说是一个可怕的主张。因此,她以自己的才智欺负他人,以残酷的方式削减了异议声音,无视那些她认为不平等的声音,并让她对任何愚蠢的事物感到沮丧。

这些天来,大多数地方都声称他们不容忍光鲜的抽搐,但我个人并不认为那是真的。对于一个经理来说,要证明摆脱一个能创造出色工作的人是非常困难的,即使她很浪费周围的每个人,尤其是如果这个人只是不规则的混蛋。混蛋太多了吗?你开始围绕这个主意进行尝试,以证明继续坚持下去是合理的。你提供她的反馈意见,她会在一段时间内变得好一点,但随后会变得更糟。

避免突发性综合症的最好方法是根本不雇用一个人。一旦被录用,摆脱辉煌的混蛋就需要一定程度的管理信心,我认为这是不常见的。幸运的是,这些人经常会摆脱他们,因为即使你可能没有胆量开除他们,但你不太可能会愚蠢到无法提拔他们。对?希望如此。

需要一个强大的经理来应对船上的一个笨拙的问题。期望她在所有反馈中与你战斗。你们两个都不容易。困难在于,如果她不认为自己的行为有问题,就不会改变。仅靠你一个人不可能说服她她的行为有问题。世界上所有的证据都无法改变一个不想改变的人。

在具有出色表现的情况下,你可以为团队做的最好的事情就是简单公开地拒绝容忍不良行为。这可能是“公开赞美,私下批评”的少数例子之一。当一个人的行为举止对团队有明显的影响,而又不想让你的文化模仿时,你需要立即说出些什么来阐明标准。“请不要这样对人们说话;这是不敬的。” 你需要对自己的反应进行严格控制,因为在公共场合传递这些信息是一条很好的路线。如果你看起来情绪激动,可能会损害你。违规者可能将你的反馈仅作为情感而写下,或者你可能会因为挑剔该人而离开。保持反馈中立,但如果你要立即提供反馈,则要保持重点,公开的; 当众。请注意,此方法仅应用于你认为对整个团队有害的行为。如果你只是认为此人正在损害你的个人利益,请私下讨论。你的第一个目标是保护你的团队整体,第二个目标是保护团队中的每个人,而你的首要任务是保护自己。

非沟通者

另一个非常常见的问题团队成员是非沟通者,即向你,团队成员或产品经理隐藏信息的人。愿意秘密进行工作并在一切都完成且完美时推出一个神奇项目的人。与其不与队友大声疾呼,而是恢复承诺,取票并为他们做事的人。不想进行代码审查并且不要求对大型项目进行设计审查的人。

这个团队成员惹恼了他周围的每个人。作为非沟通者的经理,你必须尽快消除这种隐藏信息的习惯。如有必要,请明确表示他没有达到对工作的期望。这通常是恐惧的征兆 - 人们害怕自己会被发现缺乏,或者被要求去做他不感兴趣的工作。有时,这表明一个人感到自己应该承担更多责任,不尊重他的经理。不管是什么原因,此人都会破坏团队的凝聚力,因为他没有与其他队友合作。他不安全地分享自己的工作进展,他的恐惧常常为团队其他成员树立榜样。

如果可能,请解决隐藏的根本原因。如果藏人害怕受到批评,你的团队是否有需要处理的严酷文化?你的团队总体上具有这种心理安全性吗?团队的其他成员是否将此人像局外人一样对待,也许是因为他有不同的背景或技能?如果团队拒绝该个人,则需要决定是尝试更正该团队还是将该个人转移到另一个团队。有时候,移动个人是最仁慈的事情。在其他时候,最好的解决方案是与团队整体合作,以改变文化的平衡并打破排斥新人的习惯。

缺乏尊重的员工

第三种有毒的人是根本不尊重你作为经理或不尊重队友的人。与这个人打交道将很困难,你可能需要经理的帮助,但是如果你能自己解决这个问题,那就是很有品味的标志。简而言之,如果你的团队成员不尊重你或她的同事,她为什么要在那里工作?询问她是否要在你的团队中工作。如果她说可以,请清晰,冷静地列出你的期望。如果她说她不这样做,请开始将她转移到另一个团队,或帮助她离开公司的过程。

而已?而已。你不能有一个不尊重你或不尊重你团队的人为你工作。他们会怀疑团队中其他成员的凝聚力,因为他们想知道那个人是否对不尊重你是正确的。你越早使用创可贴越好。

高级项目管理

作为工程经理,你将帮助制定团队的时间表。当大型组织试图弄清楚季度或年度的计划是什么样时,你将估计团队是否可以执行某些项目,这些项目将从事多少工作以及你是否有合适的人来完成工作。你可能会被问到你的团队除了当前的承诺外,是否还可以继续使用旧系统,或者你需要雇用多少人来支持新计划。该组织希望你能够进行即时估算和更具体的项目计划。

在第 3 章关于如何成为技术主管的讨论中,我们对项目管理进行了概述,但是现在我想深入研究一些高级工作。作为团队的经理,虽然你可以将一些项目计划推到技术主管上,但你可能需要自己做一些工作。你可能必须决定要承担哪些项目,以及何时推迟接受项目。可能会要求你粗略估计何时完成工作,甚至以敏捷的方式计划和迭代的工作。

你需要对团队的节奏和节奏有深刻的了解,才能成功地管理其工作负载,但幸运的是,有些捷径可以提供帮助。

项目管理经验法则

这里有一些经验法则要牢记。

这并非是敏捷项目管理的替代品

在开始之前,我想说明一下,我不建议你进入瀑布模式并从头开始详细计划每个项目。但是,大多数团队都具有高水平的长期目标和短期目标,这将使他们能够实现这些目标。当涉及到实际计划较小部分的细节时,团队协作来划分和粗略估计工作的敏捷过程对于平滑和组织日常工作非常有效。作为经理,你不会试图破坏甚至拥有执行过程的那一部分。但是,你需要负责更大的范围(以几个月而不是几周为单位衡量的成就),这是你必须开始进行更高级别计划的地方。

每个季度每个工程师有 10 个生产工程周

一年有 52 周,或每季度约 13 周。但是,实际上,你的团队会浪费很多时间。假期,会议,复习季节,生产中断,新员工入职—所有这些事情都失去了重点。每个团队成员每季度在主要项目上投入的精力不要超过 10 周。第一季度(紧随寒假之后)生产力最高,第四季度(包括冬季和年末假期的季度)生产力最低。

预算 20%的时间用于在董事会范围内进行通用的工程维护

我所说的“一般的可持续工程工作”是指测试,调试,清理遗留代码,迁移语言或平台版本以及进行其他必须完成的工作。如果你养成这种习惯,则可以每季度使用它来解决一些中型旧代码,并获得不错的改进。随时清理系统使这些系统易于使用,这使你的团队不断开发新功能。在最坏的情况下,你可以使用此余量来平滑功能开发中的意外延迟,但是如果你将功能开发的进度表填充到 100%,则由于此过度计划,期望功能开发会迅速变慢。

在你接近截止日期时,你的工作就是拒绝

几乎可以肯定,你有时会遇到截止日期,或者是你设置的目标日期,或者是过高的目标日期。实现这些目标的唯一方法是在项目结束时缩小范围。这意味着,作为工程团队负责人,你将与你的技术负责人和产品负责人 / 业务代表合作,以弄清哪些“必备”实际上并不是必须的。你将不得不对双方说不。有时候,工程团队会说他们不做其他技术工作就无法实现某项功能,因此你将需要弄清楚何时推动 hack 实施以及何时阻止正确的实施。某些产品功能需要实施大量工程复杂性,并且你需要与产品团队合作,找出真正的必备条件,同时说明实现其愿景所需的成本。当推到顶峰时,你将成为团队的选择者,以决定哪些是可以实际实现的,或者需要多少时间才能完成所有准备工作。

使用加倍规则进行快速估算,但按计划时间估算更长的任务

流行的软件估算加倍规则是:“每当要求估算时,请猜测并加倍。” 当要求你进行即席猜测时,此规则是合适的并且很好用。但是,当你谈论的项目可能要花几个星期以上的时间时,请继续进行下去,使预算增加一倍,但要明确你需要一些计划时间才能确定时间表。有时,较长的任务将花费比你估计的两倍还要多的时间,因此值得花一些时间仔细计划,然后再将团队委托给一个未知的大项目。

对你带给团队的东西有选择性的估计

我强调你在估算和规划过程中的作用的部分原因是,让工程师不断要求他们进行随机项目估算会分散精力和压力。作为经理,你负责处理不确定性并限制你向团队暴露的不确定性。不要成为工程师与公司其他部门之间的电话,不要来回传播消息,并分散正在忙于已经完成的重要任务的人的注意力。但是你也不是一个黑洞。尝试建立一个全团队的流程,以讨论新功能和客户投诉,并限制在此流程之外进行的估计。

询问 CTO:加入小型团队

我是一个由五名工程师组成的团队的新聘经理。我之前曾在其他公司担任经理,但是对于公司,技术和团队来说我是全新的。在头几周,我应该如何考虑时间?

加入小团队担任经理很困难。当你从软件工程师晋升为经理时,平衡技术工作是一回事,而引入新的团队来管理和学习新的代码则是另一回事。

有几种方法可以进入软件而又不会惹恼团队。首先,请某人引导你完成系统和体系结构以及测试和发布软件的过程。如果有一个正常的开发人员入职过程,你将在其中学习如何检出代码并部署系统,请执行该过程。花一些时间适应代码库,并开始观看代码审查或请求,如果它们存在的话。

计划在你的前 60 天内至少使用几个功能。采取一项特殊功能并将其添加。与其中一位正在使用的功能的工程师配对,并在你开始自己的功能时与他配对。由团队成员审核你的代码。执行发布,并且如果支持是团队职责的一部分,则至少要轮流支持系统几天。

你可能会说,这意味着你的管理入门速度可能会变慢,因为你还正在学习如何在系统中工作。这种放缓是值得的。通过了解代码,编写代码的过程以及团队日常使用的工具和系统,你将获得管理团队所需的知识以及他们见到你所必需的技术信誉作为有能力的领导者。

评估自己的经历

  • 你现在是团队的经理,你有什么新职责?为了腾出时间来承担这些新职责,你已停止执行哪些任务或将其移交给其他人?
  • 你对团队中编写,部署和支持代码的日常挑战有多满意?
  • 你的团队将工作标记为多久完成一次?
  • 你上一次编写功能,调试问题或与团队成员配对时是什么时候是他或她所苦苦挣扎的代码?
  • 是否有一两个团队成员造成团队的大部分负面情绪?你如何解决向前发展的问题?
  • 你的团队成员似乎彼此互动吗?他们在会议上微笑吗?在聊天中开玩笑吗?一起喝咖啡或午餐?你们什么时候最后一次坐在一起不谈工作呢?
  • 你的团队如何制定决策?你有分配决策责任的流程吗?你认为自己需要做出哪些决定?
  • 你上次查看已完成项目的时间是什么时候?
  • 你的团队对他们为何从事正在进行的项目的理解程度如何?
  • 你上一次削减项目范围是什么时候?你用什么来确定要切哪些块?

下一章:管理多个团队

打赏
支付宝
微信
本文作者:CodingRabbit
版权声明:本文首发于CodingRabbit的博客,转载请注明出处!