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

找到问题

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

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

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

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

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

做好产品改进计划

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

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

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

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

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

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

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

一起庆祝吧！

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

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

注：

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