• Tech Lead 如何应对团队发展不同阶段


    现在你已经成功组建了你的团队。看起来人员搭配合理、个个精兵良将、人人充满干劲。貌似只差一声枪响,就可以在赛场上呼风唤雨、连创佳绩!

    但当真的投入到交付中,却发现完全不是这么回事。

    团队成员各自为战、缺乏信任、效率低下、犹豫不前。

    糟了,刚起步就遭受当头一棒。

    别慌,其实这是团队发展的必经之路。

    早在1965年,Bruce Tuckman发表了一篇16页的论文《小型团队的发展序列》(Developmental Sequence in Small Groups),把团队发展分成了四个阶段。这四个阶段不可逾越。在1977年他又加入了第五个阶段休整期。这就是著名的Tuckman Model。
    在这里插入图片描述

    组建期

    在这里插入图片描述

    组建期的团队,成员们刚刚集合,彼此之间还都比较陌生。此时团队成员间缺少安全感,目标感也很弱,每个人倾向于各自为战。

    作为 Leader,这个时期应该通过组织活动来带动气氛,让成员尽快相互熟悉起来。可以刻意让成员配合工作,增加默契和信任。此外可以通过 team building 的形式让成员尽快熟悉,打破个体间的壁垒。

    这个阶段和团队谈技术愿景可能有些空洞。可以先尝试设定一些具体的团队目标。比如准时完成一个迭代所有 Story 开发。甚至可以再小一点,比如团队保持测试覆盖率80%以上。这样可以让团队成员意识到大家是一个团体,一起努力才能达成团队的目标。

    激荡期

    在这里插入图片描述

    从组建期走过来,团队成员慢慢熟络起来,但是还远远称不上有多高的默契度。

    碰到问题的时候,大家由原来的不说话,变成积极表达己见,甚至争吵起来。这个阶段应当让团队成员充分表达自己的想法,然后形成团队规范。

    组建期只是有了一个队伍,而激荡期才是让队伍过度为队伍。

    我曾经在一个项目上亲身经历过印象深刻的激荡期。Code review 经常拖堂到 2 个小时。好多问题无法达成一致,长时间陷入讨论和争执。当时我的感觉糟透了。但现在想想,这其实是团队发展的必经阶段。

    激荡期是团队形成规范的必经之路。作为 Leader 应当鼓励成员进行讨论,并得出结论。这个过程中需要注意如下几点:

    1. 制定时间限制,不要无休止的纠缠在某个问题上,消耗团队太多精力
    2. 控制讨论的气氛,让成员们专注在问题本身,避免过分冲突
    3. 争执不下时需要Leader带领团队得出结论。很多问题并没有 100% 的对错,重要的是讨论的过程而不是结果。
    4. 需要对团队中强势的 “意见领袖” 稍加控制,尽量让团队所有成员都能参与讨论,发表自己的看法。避免每次都是 “声音大” 的一方占据优势,而让其他成员心里不爽。

    这个阶段我们需要团队成员激烈 “争吵”,但也要适当控制时间和情绪,否则会扩大负面影响。激荡期不可跳过,但我们可以帮助团队安稳、快速的度过这个阶段。就像上面的插图,风暴终将过去,迎接我们的将是万里晴空。

    规范期

    在这里插入图片描述

    度过激荡期后,团队进入规范期。经过激荡期的磨合,团队成员在大多数分歧上已经达成了一致,姑且不谈达成一致的结论是否合理,但总归大家有了共同的规范。团队不需要再花费大量精力在讨论和争执上。此时的团队会更加团结。大家在这个时期会逐步建立起团队的目标。

    作为团队的Leader,在这个阶段需要考虑如下事情。

    制定团队目标

    此时团队成员已经比较熟悉,相互的信任感也在增强。为团队制定更为宏大的目标的时间已经成熟了。

    制定团队的技术愿景,统一团队的标准和决策。让团队越来越像一个人在工作,而不是一团散沙。

    制定和完善规范

    你的团队在激荡期已经产出了一些规范,但这远远不够。这个时期我们要趁热打铁,逐一制定出执导团队行为的规范。比如技术使用规范、代码提交规范、项目活动的流程及会议等等。

    执行期

    在这里插入图片描述

    团队成员已经相互熟识,规范也逐渐丰富。此时团队进入了高效产出时期。团队已经可以在达成共识的框架中开展工作,有条不紊,井井有序。

    这个时候 Tech Lead 是不是就高枕无忧,可以松一口气了?答案当然是否定的。

    在这个时期,TL 要考虑下面几件事情。

    完善规范

    经过规范期,团队已经有了很多规范。产出这些规范你们付出了大量的时间、精力,甚至争吵。

    但是这些规范中又有多少是迫于时间线不得不作出的选择?又有多少是因为某些团队成员嘴上功夫了得而被采纳?又有多少是凭空想象而得出的结论?

    在执行期,我们有了大量规范执行的事例。哪些规范是合理的,哪些有问题,现在都可以用事实说话。我们可以不再单单基于经验和假想制定规范。我们应该通过事实来纠正、改善、补充规范。

    给予团队信任

    这个时期的团队成员已经渐入佳境,个个都摩拳擦掌想要一展实力。

    根据社交 HRT 原则(谦虚、尊重、信任),Leader 应该充分给予团队成员信任。信任的建立是需要过程的。盲目信任不能称之为信任。这只是偷懒,或者称之为散手不管。

    只有每个团队成员都充分发挥自己的主动性,争相成为某项事情的leader,团队才会朝气蓬勃快速前进。如果所有事情都是 Tech Lead 冲在最前头,那么 Tech Lead 的能力和精力将会成为团队的天花板。

    打造团队文化

    所谓团队文化,其实就是团队的性格。团队文化发源于团队的创始人,形成于初始团队。后面有新成员加入时会潜移默化的被团队文化所影响。新成员会带来一些小的改变,但是不会对文化构成大的冲击。除非团队更换Leader。

    新的团队成员要么融入团队文化,要么就会离开团队。团队自身不允许有和团队文化不合的成员存在。

    如果团队文化过于孱弱,也有可能被强势的新成员所影响。这种变化可能是好的,但对团队来说有很大的破坏性和不确定性。团队接受新文化的成本非常高,会产生不和谐的声音。这里建议 Tech Lead 应该强化团队文化,并守护团队文化。

    即使团队文化需要发生变化,那么也应该是在Tech Lead的主导下,以团队能接受的方式发生变化。

    从某种意义上说,团队文化其实是 Tech Lead 自身性格的体现。

    休整期

    天下没有不散的宴席。作为一个团队,终将会解散。可能是团队目标已经达成或者组织需要变革。

    当项目完成时很可能意味着团队的解散。大家可能离开加入新的团队。也可能团队还在,但要做大范围的人员调整。当然也可能很幸运,团队直接承接下一个项目。

    在这个时期,团队成员面临对未来不确定的恐慌以及对分离的不舍,效率难免会有所下降。Tech Lead 在这个阶段应该主动疏导大家情绪,开诚布公的沟通团队未来的变化以及大家的可能去向。避免谣言和小道消息在团队蔓延。最后,作为 Leader 应当组织团队总结在项目上的收获,以及给成员未来发展的建议。

    总结

    在团队发展的不同阶段,团队效率和氛围有着明显的不同。作为 Tech Lead,应当随着时间推移分析团队目前所处的阶段,有针对性的采取行动,提升团队效率,促进团队成长。

  • 相关阅读:
    Java——break、continue(学习笔记)
    【SpringBoot学习】44、SpringBoot 集成 Elasticsearch-7.6 实战
    在Vs-Code中配置“@”路径提示的插件
    react中使用Modal.confirm数据不更新的问题解决
    Netty——ByteBuffer的内部结构
    React + Antd 自定义Select选择框 全选、清空功能
    【从零开始学微服务】01.微服务的过去与现在
    【Web前端面试】葵花宝典(2022版本)——React 篇
    解决redis在centos上部署
    百度文心一言与谷歌Gemini的对比
  • 原文地址:https://blog.csdn.net/liyiming2017/article/details/126132636