搜索 | 会员  
如何领导跨团队的项目?「团结一心」实现目标
来源: 36氪   作者:网友  日期:2018-7-9  类别:人力资源  主题:团队管理  编辑:Estelle
一个刚孵化的创业公司可以只有一个团队,但是,当公司逐渐走向正轨,聘用了更多员工,形成更多部门,如何领导不同团队完成一个项目就成为一个新难题。

每个软件公司都会遇到需要对应用程序做出较大修改的时候,可能是要实现国际化、大幅提升性能,或者在我的案例里,是要降低app崩溃的频率。其中棘手的问题是,这样大范围的修改经常需要多个工程团队合作,才能达到预期的结果。这篇文章就是讲我如何领导跨团队的工程项目,实现app崩溃率可控的目标。

找到问题

过去的四年里,我在Asana公司负责Asana应用的稳定性工作。在我刚刚接手这个工作时,我们用维护模式在运行。每次我们发现产品中的P0 [1]级别错误和阻碍了Push推送的bug,就会用「5 Whys」[2]方法来找到出错的根源。我会回溯每次故障产生的缘由,并且每6个月与来自不同工程团队的相关人员进行一次会议,汇报应用稳定性情况。在这些会议上,我们讨论是否需要做出改动。直到 2016年末,我们一直认为事情进展得足够顺利,不需要较大改动。

然而,在2017年2月,我正在准备我们下次的应用稳定性汇报会议时,看到了下面的表格,它展现的是在某一天碰到故障的用户百分比。

image.png

过去的四年里,我在Asana公司负责Asana应用的稳定性工作。在我刚刚接手这个工作时,我们用维护模式在运行。每次我们发现产品中的P0 [1]级别错误和阻碍了Push推送的bug,就会用「5 Whys」[2]方法来找到出错的根源。我会回溯每次故障产生的缘由,并且每6个月与来自不同工程团队的相关人员进行一次会议,汇报应用稳定性情况。在这些会议上,我们讨论是否需要做出改动。直到 2016年末,我们一直认为事情进展得足够顺利,不需要较大改动。

然而,在2017年2月,我正在准备我们下次的应用稳定性汇报会议时,看到了下面的表格,它展现的是在某一天碰到故障的用户百分比。

哦!我压根没有想过7月的故障率会这么高。在Asana,我们为自己有一个优化得当、运行流畅的app而自豪,而这样的数据不应该出现。因此,我开始全力解决这个问题,想把我们的故障率降到红线以下。

设立清晰的目标并让团队认同

为了开始这项工作,我想要设立一个可量化的关键结果(KR,Key Result)来帮助我呈现要做的工作。有了清晰的目标,我们达到目标就可以庆祝,或者没有达到目标时就可以反思原因。设立KR也意味着这个故障率目标将会更容易被注意到:它将会和我们的其他KRs(例如发布新功能)一样被列为同等级的任务,不会轻易被忽视掉了。提升这项工作的重要性可以帮助我们有所权衡,最终,我们必须能够明确什么是重要的事情。


image.png

之前的经验告诉我,我不能在没有征求其他人意见的情况下,就代表团队定下我们的目标。事实上,我之前试图设过类似的KR,但是没有事先征求团队意见。当它成为优先工作的时候,团队对于这个我们之前完全没讨论过我又设立的目标非常惊讶。这次之后,我知道了,要把所有的意见和争论都摆在台面上进行讨论,说服团队为共同的目标而努力。

最初,我不知道该如何跟团队讨论这项工作。我情感上的本能反应是想责怪他们搞出了这么多bug,但是我知道我不会到处跟他们说我很失望。所以,我向我的经理寻求指导。他建议我将此视作一个平衡问题,如果我们把精力都放在快速发布功能上,产品故障率就会上升;如果我们将精力集中在修复所有故障上,产品发布速度就会慢下来。我们之前主要集中在快速产出东西,而现在需要转向稳定性。

image.png

这种看待事物的方式简便又巧妙,我立即就感到针对这个问题可以对症下药了。这个观点,也帮助我让团队里的每个人都能更理解我们要做的事情。接下来,我必须为我真正想要大家做的事情做出一个计划。

做好产品改进计划

抱着转变故障率和稳定性之间平衡的想法,我制订了一个计划,我们要实现应用稳定性并在实际工作中进行变革。这是我的计划:

  • 在团队决定一个bug是否需要修复方面:之前,如果一个bug每天影响不超过20个用户,我们就不会关注它。现在,我要求每个人都要看所有的新bug,并大致估计它修复的难度。如果它容易修,那么它应该被修复,即使它对于大多数用户没有影响。

  • 发现产品的新故障时要更加积极地回滚。我也要求网站监控人员花更多的时间进行故障分类,并且将故障分给合适的人。我注意到,当一个故障被分配给合适的人时,它修复的更快。在另一方面,如果它被分配给错误的人,他们对处理它毫无头绪,所以他们更可能就把它扔在那。所以我要求网站监控人员花更多精力在分类上。

  • 增加一个网站监控的工作流:因为网站监控人员被要求做更多的工作,我将这个新的工作流当做网站监控的后援。他们可以快速修复比如容易修复的bug,这将帮助减少总故障数。但是,我必须得确定这不会成为所有bug的「垃圾场」。为了实现这个,我们都同意,只有没有分配给具体工程师的bug才可以进入这一工作流。

团队同意了这些改进计划,认可共同的KR,之后我们开始工作。看到大家都团结在这个KR之下,向着降低故障率的目标发起挑战,真是太棒了。


确保每个人都知道你在意什么

当背后没有一个支持团队的时候,制定一个KR并放上我(Leader)的名字有点让人恐慌:负责这个KR意味着我要对它的成功负责任,实际上我自己不做任何修复bug的工作。但我必须这么做,必须成为应用稳定性和这个KR的直接负责人。即使我不做任何bug修复工作,每个人都知道他们可以直接跟我商量。他们也知道这个KR可能有风险,而且,如果我们以产品里存在bug结束,我就会感到沮丧。

一起庆祝吧!

现在我们的成绩怎么样呢?虽然依旧不完美,但是,我对我们新的、bug少少的、相对稳定的状态非常自豪。

image.png

更重要的是,我做到了,而且没有搞砸同事之间的关系。我的一位同事给我留言:「我被我们的能力所震惊了!在如此之短的时间里,我们就完成了从计划到设定和执行跨团队的KRs并取得这样巨大的成功!」

image.png

注:

[1]在产品管理中,P0代表最高优先级的意思。


德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
广告那些事
我们的推荐
也许感兴趣的
干货
了解一下吧