一个刚孵化的创业公司可以只有一个团队，但是，当公司逐渐走向正轨，聘用了更多员工，形成更多部门，如何领导不同团队完成一个项目就成为一个新难题。
光涧实验室翻译了Asana的这篇博客，希望帮助大家学习到一些跨团队项目管理的方法。
每个软件公司都会遇到需要对应用程序做出较大修改的时候，可能是要实现国际化、大幅提升性能，或者在我的案例里，是要降低app崩溃的频率。其中棘手的问题是，这样大范围的修改经常需要多个工程团队合作，才能达到预期的结果。这篇文章就是讲我如何领导跨团队的工程项目，实现app崩溃率可控的目标。
过去的四年里，我在Asana公司负责Asana应用的稳定性工作。在我刚刚接手这个工作时，我们用维护模式在运行。每次我们发现产品中的P0 [1]级别错误和阻碍了Push推送的bug，就会用「5 Whys」[2]方法来找到出错的根源。我会回溯每次故障产生的缘由，并且每6个月与来自不同工程团队的相关人员进行一次会议，汇报应用稳定性情况。在这些会议上，我们讨论是否需要做出改动。直到 2016年末，我们一直认为事情进展得足够顺利，不需要较大改动。
然而，在2017年2月，我正在准备我们下次的应用稳定性汇报会议时，看到了下面的表格，它展现的是在某一天碰到故障的用户百分比。
哦！我压根没有想过7月的故障率会这么高。在Asana，我们为自己有一个优化得当、运行流畅的app而自豪，而这样的数据不应该出现。因此，我开始全力解决这个问题，想把我们的故障率降到红线以下。
为了开始这项工作，我想要设立一个可量化的关键结果（KR，Key Result）来帮助我呈现要做的工作。有了清晰的目标，我们达到目标就可以庆祝，或者没有达到目标时就可以反思原因。设立KR也意味着这个故障率目标将会更容易被注意到：它将会和我们的其他KRs（例如发布新功能）一样被列为同等级的任务，不会轻易被忽视掉了。提升这项工作的重要性可以帮助我们有所权衡，最终，我们必须能够明确什么是重要的事情。
之前的经验告诉我，我不能在没有征求其他人意见的情况下，就代表团队定下我们的目标。事实上，我之前试图设过类似的KR，但是没有事先征求团队意见。当它成为优先工作的时候，团队对于这个我们之前完全没讨论过我又设立的目标非常惊讶。这次之后，我知道了，要把所有的意见和争论都摆在台面上进行讨论，说服团队为共同的目标而努力。
最初，我不知道该如何跟团队讨论这项工作。我情感上的本能反应是想责怪他们搞出了这么多bug，但是我知道我不会到处跟他们说我很失望。所以，我向我的经理寻求指导。他建议我将此视作一个平衡问题，如果我们把精力都放在快速发布功能上，产品故障率就会上升；如果我们将精力集中在修复所有故障上，产品发布速度就会慢下来。我们之前主要集中在快速产出东西，而现在需要转向稳定性。
这种看待事物的方式简便又巧妙，我立即就感到针对这个问题可以对症下药了。这个观点，也帮助我让团队里的每个人都能更理解我们要做的事情。接下来，我必须为我真正想要大家做的事情做出一个计划。
抱着转变故障率和稳定性之间平衡的想法，我制订了一个计划，我们要实现应用稳定性并在实际工作中进行变革。这是我的计划：
在团队决定一个bug是否需要修复方面：之前，如果一个bug每天影响不超过20个用户，我们就不会关注它。现在，我要求每个人都要看所有的新bug，并大致估计它修复的难度。如果它容易修，那么它应该被修复，即使它对于大多数用户没有影响。
发现产品的新故障时要更加积极地回滚。我也要求网站监控人员花更多的时间进行故障分类，并且将故障分给合适的人。我注意到，当一个故障被分配给合适的人时，它修复的更快。在另一方面，如果它被分配给错误的人，他们对处理它毫无头绪，所以他们更可能就把它扔在那。所以我要求网站监控人员花更多精力在分类上。
增加一个网站监控的工作流：因为网站监控人员被要求做更多的工作，我将这个新的工作流当做网站监控的后援。他们可以快速修复比如容易修复的bug，这将帮助减少总故障数。但是，我必须得确定这不会成为所有bug的「垃圾场」。为了实现这个，我们都同意，只有没有分配给具体工程师的bug才可以进入这一工作流。
团队同意了这些改进计划，认可共同的KR，之后我们开始工作。看到大家都团结在这个KR之下，向着降低故障率的目标发起挑战，真是太棒了。
当背后没有一个支持团队的时候，制定一个KR并放上我（Leader）的名字有点让人恐慌：负责这个KR意味着我要对它的成功负责任，实际上我自己不做任何修复bug的工作。但我必须这么做，必须成为应用稳定性和这个KR的直接负责人。即使我不做任何bug修复工作，每个人都知道他们可以直接跟我商量。他们也知道这个KR可能有风险，而且，如果我们以产品里存在bug结束，我就会感到沮丧。
现在我们的成绩怎么样呢？虽然依旧不完美，但是，我对我们新的、bug少少的、相对稳定的状态非常自豪。
更重要的是，我做到了，而且没有搞砸同事之间的关系。我的一位同事给我留言：「我被我们的能力所震惊了！在如此之短的时间里，我们就完成了从计划到设定和执行跨团队的KRs并取得这样巨大的成功！」
[1]在产品管理中，P0代表最高优先级的意思。
[2] 5 Whys指Asana团队在发现问题根本原因时使用的方法，一般经过5轮对问题追根究底的来回迭代才能够发现，详细见：https://wavelength.asana.com/workstyle-ask-5-whys-to-get-to-the-root-of-any-problem/
原文：https://blog.asana.com/2018/06/leading-cross-team-eng-changes/
作者：Bella Kazwell，Asana Engineering Lead
翻译：王子颖
校对：郝晓茹，王文超
光涧实验室专注于实践和分享「创造美好产品的系统化创业方法论」。
我们希望帮助那些有同样愿景的团队掌握创业方法论，并为他们提供切实可行的解决方案。
联系客服
