团队协作与团队内部竞争

团队协作与团队内部竞争

TrustYou is the largest feedback platform in the world. We analyze hundreds of millions of hotel reviews, we do it for more than half a million hotels, and we have tens of thousands of hotels using directly our platform as the company’s customers. We have achieved this without ever receiving considerable funding and although this is something that we are proud of, this has also affected our engineering journey in a way that, well, we are not always that happy about. To get where we are, there were often times when we had to cut corners to deliver our products faster than the competition.

TrustYou是世界上最大的反馈平台。 我们分析了数以亿计的酒店评论，为超过50万家酒店进行了分析，并且有数以万计的酒店直接使用我们的平台作为公司的客户。 我们已经实现了这一目标，却没有获得可观的资金，尽管这让我们感到自豪，但这也以不总是让我们感到高兴的方式影响了我们的工程历程。 为了到达我们自己的位置，通常我们不得不偷工减料才能比竞争对手更快地交付我们的产品。

Around the year 2016, our growth speed increased and within two years we have doubled the size of our engineering department. It became clear that we not only needed to make sure we follow industry best practices in our teams but we also needed to start paying our technical debt aggressively. After some easier or more difficult discussions, we got buy-in from the management, we got buy-in from our product team, and … nothing really changed, at least initially.

在2016年左右，我们的增长速度有所提高，并且在两年内，我们的工程部门规模扩大了一倍。 显然，我们不仅需要确保我们遵循团队中的行业最佳实践，而且还需要开始积极地偿还技术债务。 经过一些轻松或更艰难的讨论之后，我们从管理层那里得到了支持，从产品团队那里得到了支持，……至少在最初，什么都没有真正改变。

It turns out that introducing such a fundamental change like adjusting the balance between delivering new features and paying the technical debt cannot be achieved merely by hinting product owners and team leads. It turns out that there are engineering specific changes that require the whole organization to adapt. If you don’t explain top-down why we introduce the change, how the planning and prioritization rules change, there will be friction between departments that will either stop the change or will make parts of the organization inefficient.

事实证明，仅通过暗示产品所有者和团队领导者就无法实现引入这样的根本性改变，例如调整交付新功能和支付技术债务之间的平衡。 事实证明，有一些特定于工程的更改需要整个组织进行调整。 如果您没有自上而下的解释我们为什么引入变更，规划和优先级规则如何变更，那么部门之间将存在摩擦，这将阻止变更或使组织的某些部分效率低下。

In our case, I think, it was the pressure from sales and key account management that stopped us. There was always this next important customer whose new feature seemed to be more important than a technical improvement. You cannot blame these guys for that because their job is to sell and “refactoring of our data processing pipeline” will never ever sound more important than winning the next customer. And as mentioned above, we didn’t really try to explain to anyone what that thing about the technical debt was. We have spent quite a while turning circles in this dead-lock, experimented with different management techniques, e.g. enforcing technical debt dedicated capacity on a team level, trying things out with the dedicated task forces but in the end, a systematic and sustainable solution came from an unexpected direction.

我认为，就我们而言，是销售和大客户管理的压力阻止了我们。 总是有下一个重要客户，其新功能似乎比技术改进更重要。 您不能责怪这些人，因为他们的工作是销售，而“重构我们的数据处理管道”听起来永远比赢得下一个客户更重要。 如上所述，我们并没有真正试图向任何人解释技术债务的含义。 我们花了相当长的时间在这种僵局中转弯，尝试了不同的管理技术，例如在团队层面上加强了技术债务专项能力，与专职工作组一起进行了尝试，但最终有了系统的，可持续的解决方案从意想不到的方向。

In 2018, we decided to introduce OKRs to improve the visibility of our work and alignment between management and the teams. We defined technical improvement goals for every development team for an upcoming quarter but … we didn’t even get to the point where we reviewed the achievements, not mentioning defining the new goals for the next season. The same thing happened as before — we were so busy delivering new features and working around our technical problems, that we didn’t find time to start fixing them. From the perspective of time, I believe I can indicate pretty clearly the mistakes that we made back then:

在2018年，我们决定引入OKR，以提高我们工作的可见度以及管理层与团队之间的一致性。 我们为下一个季度的每个开发团队定义了技术改进目标，但是…我们甚至没有达到要回顾成就的地步，更不用说为下个赛季定义新的目标了。 与以前一样，发生了同样的事情-我们非常忙于提供新功能并解决我们的技术问题，以至于我们没有时间开始修复它们。 从时间的角度来看，我相信我可以很清楚地指出我们当时所犯的错误：

We didn’t go full in with the OKRs. We decided to cover only engineering topics with them and leave the product prioritization the way it was. And I think introducing the OKRs requires not only the alignment between product and engineering but it is also critical to make such a change visible to the whole organization.

我们没有完全了解OKR。 我们决定只涵盖工程主题，并按原样保留产品优先级。 而且我认为，引入OKR不仅需要产品和工程之间的协调，而且对于整个组织来说，这样的改变也是至关重要的。 We didn’t define the consistent and iterative process for OKRs tracking and renewals. That’s true that our teams were busy delivering yet another feature but we didn’t really have a clear process telling us, e.g. that “this is a day when all the teams need to start drafting their OKRs for the next season”.

我们没有为OKR跟踪和续订定义一致且迭代的过程。 确实，我们的团队正忙于提供另一项功能，但是我们并没有一个清晰的流程告诉我们，例如“这一天，所有团队都需要开始为下一个赛季起草其OKR”。 We decided to introduce OKRs both for the teams and for individuals which seems to be too much to achieve in one go. I don’t think it was a killer for our change but it is always better to focus on one thing when introducing a deeper change in how your organization functions.

我们决定为团队和个人引入OKR，这似乎一口气就无法实现。 我不认为这是我们变革的杀手，但是在对组织的运作方式进行更深刻的变革时，最好只关注一件事。

Looking back at this first attempt, I wouldn’t say though that it was lost work. People at TrustYou learned what OKRs were, the idea got instilled in our minds and we got the foundation for our later success.

回顾第一次尝试，我不会说那是丢失的工作。 TrustYou的人们了解了什么是OKR，这个想法已经渗入我们的脑海，并且为以后的成功奠定了基础。

Two years later, at the beginning of 2020, we were struggling with some other problem: we were discussing how to improve the visibility of our midterm plans to our engineers. It doesn’t sound like the main promise that you get from OKRs proponents, but yes, our thoughts went back again to quarterly goals-setting for our teams. This time we did a little bit better than before. We took some time to describe the process, from the very beginning we worked on this change together with our product team, we clearly explained the change to the whole organization.

两年后，即2020年初，我们遇到了其他问题：我们正在讨论如何提高中期计划对工程师的可见性。 这听起来似乎不是从OKR支持者那里获得的主要承诺，但是是的，我们的想法又回到了为团队制定季度目标的想法。 这次我们比以前做得更好。 我们花了一些时间来描述流程，从一开始我们就与产品团队一起致力于这项变更，因此我们向整个组织清楚地解释了这一变更。

We are now in the third iteration of our OKRs process and we still have a long way to go to stabilize and improve but this time, the attempt seems to have been successful. What did we change comparing to the first attempt? I have very shortly indicated this already above but let’s take a look closer at it:

现在，我们处于OKR流程的第三次迭代中，并且要稳定和改进还有很长的路要走，但是这次，尝试似乎已经成功。 与第一次尝试相比，我们做了哪些更改？ 我已经在上面简短地指出了这一点，但让我们仔细看一下：

We decided to go all-in and cover both product and technical work with OKRs, giving this way a consistent set of priorities to our development teams. Honestly, this sounds now like the only way to go but we didn’t do it this way the first time so apparently you can go wrong about it.

我们决定全力以赴，并与OKR一起涵盖产品和技术工作，从而为我们的开发团队提供了一致的优先事项。 老实说，这听起来似乎是唯一的方法，但是我们第一次没有这样做，所以显然您会出错。 From the very beginning, we created a document describing how we understand OKRs at TrustYou and the actual procedure to set up and renew OKRs quarter by quarter. I admit that the first version of the document was not that great and we improved it a lot over this year but yes, having such a thing was the way to go.

从一开始，我们就创建了一个文档，描述了我们如何理解TrustYou的OKR，以及每季度设置和更新OKR的实际程序。 我承认该文档的第一版并不是很好，并且我们在今年对它进行了很大的改进，但是，是的，要走这样的路。 We invested more time in reading about OKRs, finding good resources, and sharing them with our engineers. Again, we started with a limited set of learning materials but we improved over subsequent iterations.

我们花了更多时间阅读有关OKR的知识，寻找好的资源并与我们的工程师共享。 同样，我们从一组有限的学习资料开始，但是在随后的迭代中有所改进。 We decided to keep it as light as possible. We understand that all the teams have their processes already in place so the OKRs needed to be organized as a thin layer above these processes giving focus points to the teams, affecting their priorities, but not affecting the way they have already worked.

我们决定保持它尽可能轻。 我们了解到所有团队都已经制定了流程，因此OKR需要在这些流程之上以薄层的形式组织，以便为团队提供重点关注点，从而影响其优先级，但不影响其工作方式。 We decided not to introduce personal OKRs for our engineers. But we didn’t ban them — our team managers can phrase growth goals for their team members the way they like but personal OKRs were not our focus and we decided not to regulate this.

我们决定不为我们的工程师引入个人OKR。 但是我们没有禁止他们-我们的团队经理可以按照自己喜欢的方式为他们的团队成员制定增长目标，但是个人OKR并不是我们的重点，因此我们决定不对此进行规范。 We decided to apply the continuous process improvement principle. Every quarter we try to gather feedback about the OKRs process from all the team members using a dedicated survey, we analyze the results and discuss how we can adjust the process. This way we made the document describing the actual process clearer and simpler, and we are now experimenting with the coordination of the cross-team OKRs.

我们决定采用连续过程改进原则。 每个季度，我们都会尝试通过专门的调查收集所有团队成员对OKRs流程的反馈，我们分析结果并讨论如何调整流程。 这样，我们使描述实际过程的文档变得更加清晰和简单，并且我们现在正在尝试跨团队OKR的协调。

The most prominent effect of introducing OKRs is the improvement that we didn’t even think about when kicking things off and this is the improved steerability of our engineering department. Suddenly, it turned out that we have in our hands a single tool that makes it possible to pass both product and technical strategy directly to the teams, get feedback about the strategy from the teams, and coordinate cross-team efforts in the execution phase of OKRs.

引入OKR的最显着效果是，在启动时甚至没有想到的改进，这就是我们工程部门的改进的可操纵性。 突然，事实证明，我们手中只有一个工具，可以将产品和技术策略直接传递给团队，从团队那里获得有关策略的反馈，并在执行阶段协调跨团队的工作。 OKR。

As we became nicely steerable and transparent some things turned out to be easier than before. It didn’t really take us a lot until we decided to use our new weapon against our old good friend — the technical debt. We started asking all our development teams for technical debt related OKRs and suddenly we found ourselves in the third quarter in a row where all our engineering teams beautifully dedicate an important part of their capacity to clearly defined technical challenges.

随着我们变得易于操纵和透明化，某些事情变得比以前更容易。 直到我们决定使用新武器来对抗我们的老好朋友-技术债务，这并没有花太多时间。 我们开始向所有开发团队询问与技术债务相关的OKR，突然间，我们连续第三季度发现自己，我们的所有工程团队都将其能力的重要组成部分专门用于明确定义技术挑战。

Yes, sure, our codebase didn’t change that much yet but we are pretty early in the process. We still have sometimes and will probably have forever the heated discussions about priorities. But the strategy is transparent, the prioritization rules and plans are visible. Within minutes, everyone who is interested can understand how all the teams contribute to the strategy, and we are talking here about more than 10 software development teams.

是的，可以肯定，我们的代码库还没有太大变化，但是我们还处于开发的初期。 我们有时甚至可能永远有关于优先事项的激烈讨论。 但是策略是透明的，优先级规则和计划是可见的。 在几分钟之内，所有感兴趣的人都可以了解所有团队如何为该战略做出贡献，我们在这里谈论的是10多个软件开发团队。

On the other hand, we are not fully done with the process yet but actually, we never want to be, so let me explain shortly things that we are looking into these days and want to improve in the upcoming iterations:

另一方面，我们还没有完全完成该过程，但是实际上，我们还不想这么做，所以让我简短地解释一下这些天我们正在寻找的事情，并希望在即将到来的迭代中有所改进：

Helping the teams with defining cross-team OKRs. We originally assumed that the teams need to talk to each other to understand if they want to work together on shared goals or not. We learned over time that some kind of basic support in this area will be helpful.

帮助团队定义跨团队的OKR。 我们最初认为，团队需要互相交谈，以了解他们是否希望为共同的目标而共同努力。 我们逐渐了解到，这方面的一些基本支持会有所帮助。 Helping the teams with the execution of cross-team OKRs. We are experimenting with a very light project management structure for such initiatives but it is supposed to work, again, as a super-thin layer above the processes that the teams already follow, completing these processes with cross-team communication and coordination instead of changing them.

帮助团队执行跨团队的OKR。 我们正在为此类计划尝试一个非常轻便的项目管理结构，但是它应该再次发挥作用，作为团队已经遵循的流程之上的超薄层，通过跨团队的沟通和协调来完成这些流程，而不是进行更改他们。 Last but not least, we need to improve how we define company goals that our engineering teams would be aligning with. We have had them already in the previous iterations but we need to look into it again as we learned from our quarterly survey that the direction was not clear so we either didn’t do it well with the communication or the actual goals were not phrased that well.

最后但并非最不重要的一点是，我们需要改进定义工程团队将要遵循的公司目标的方式。 我们在先前的迭代中已经使用过它们，但是我们需要从季度调查中了解到，方向并不明确，因此我们要么在沟通方面做得不好，要么实际目标没有表述为好。

In the end, I am pretty much convinced that our case with two attempts of introducing OKRs makes our story a little bit more interesting because I believe we know pretty well why we failed in the first attempt and why we succeeded in the second one. Taking these into account, these would be the points that I suggest to keep in mind when introducing OKRs in your organization:

最后，我非常相信，通过两次尝试引入OKR的案例使我们的故事更加有趣，因为我相信我们很清楚为什么第一次尝试失败以及为什么第二次成功。 考虑到这些因素，在组织中引入OKR时，我建议牢记以下几点：

Make sure that the OKRs process is the only mechanism defining priorities for your teams.

确保OKR流程是定义团队优先级的唯一机制。 Educate yourself and educate your people about what OKRs are. Prepare a presentation, collect resources, choose a book — whatever feels best in your organization.

教育自己并教育您的员工了解什么是OKR。 准备演示文稿，收集资源，选择书籍-在组织中感觉最佳的事情。 Prepare a document explaining how your organization understands OKRs and a document explaining step by step your process for the OKRs renewal process.

准备一份说明您的组织如何理解OKR的文档，并逐步说明您的OKR续订流程的文档。 Focus on repeatability in the first iterations. Sure, the OKRs are super important from the very beginning but repeatability is the key to your success.

在第一次迭代中着重于可重复性。 当然，OKR从一开始就非常重要，但是可重复性是您成功的关键。 Make it transparent. Make sure that both OKRs and the actual achievements are visible to whoever is interested in them in your organization.

使它透明。 确保对组织中的人都可以看到OKR和实际成就。 Keep it light and make sure people know that you want it this way! As mentioned already earlier, the teams have already their processes in place, and adding heavy things on top will not win you your people for the idea.

保持轻便，并确保人们知道您想要这种方式！ 正如前面已经提到的，团队已经建立了自己的流程，并且在最上面添加沉重的内容并不能使您的想法赢得您的员工。 Think explicitly about how you want to address cross-team OKRs, detecting them, and then coordinating work on them.

明确考虑您要如何解决跨团队的OKR，检测它们，然后协调它们的工作。 And last but least, necessarily introduce some kind of continuous process improvement mechanism, e.g. quarterly survey for bigger teams, retrospective sessions for smaller ones.

最后但并非最不重要的一点是，必须引入某种持续的流程改进机制，例如，对较大的团队进行季度调查，对较小的团队进行回顾会议。

Summarizing, the OKRs may seem like yet another management buzzword but for us, at TrustYou it was a game-changer. We got improved steerability, improved transparency, and better horizontal and vertical alignment. Sounds great but well, keep also in mind that the OKRs are not a silver bullet. Your capacity will not magically increase, your priorities will not get magically resolved, your engineering challenges will still be on your engineers to solve. But I dare to say that there is some kind of magic touch that you get and this is increased motivation of your people who will be happier once they get all the good things that I indicated above. And I hope that with this article I am helping you bringing this tiny piece of magic to your organization too. Enjoy the ride!

总而言之，OKR似乎是另一个管理流行语，但对我们来说，在TrustYou，这是一个改变游戏规则的人。 我们提高了操纵性，提高了透明度，并改善了水平和垂直对齐方式。 听起来不错，但请记住，OKR不是灵丹妙药。 您的能力不会神奇地增加，您的优先级也不会得到神奇的解决，您的工程挑战仍将由您的工程师来解决。 但是我敢说你有某种神奇的感觉，这是你的人们一旦获得了我上面指出的所有美好事物后就会变得更加快乐的动力。 我希望通过这篇文章，我也能帮助您将这小小的魔术带入您的组织。 享受车程！

翻译自: https://medium.com/trustyou-engineering/from-individual-teams-to-competitive-organization-772a7f382e0a

团队协作与团队内部竞争