在今年的TeamLead上，Sergey谈到了敏捷如何转变成一个大型组织，并因此谈到了您的环境（团队领导者和团队）如何变化以及对您作为领导者提出了哪些新要求。他用照片展示了整个敏捷过程。
敏捷入门
如果您已经有了敏捷，您是如何决定的？您是否已自行决定是否有意识地确定此过程（Scrum或看板）需要什么，它究竟将对解决您的问题有什么帮助？您是第一次这样认识敏捷吗？
...还是发生了这种情况？
在大型组织中，通常的故事是经理进来的：“就是这样，明天每个人都是Scrum！没有时间弄清楚了-您是Scrum管理员还是产品负责人。”此外，从“俄罗斯的敏捷”研究中得出的数字表明：规模越大，这个故事发生的频率就越高。但是，无论您如何设法参与敏捷，我们都要弄清楚您要去哪里，该环境是什么以及它对您和您的团队有什么要求。如果不解决这一问题，那么敏捷的实现通常会变成功能工厂。
过去，开发人员从吉拉（Jira）购票。现在他们做同样的事情，但是它们取材于现在称为积压的积压：积压的积压归您所有，您取而代之-传送带继续运转。同时，在某个地方，您的产品向用户介绍了最终发生的情况：用户和产品，亲！
真的很敏捷吗？我们不是为此而做的。
什么是敏捷？为什么？
您知道敏捷是面对巨大不确定性如何执行项目的一种方法。这是Stacy的困惑矩阵：
在存在两个大不确定性的情况下，敏捷可以很好地发挥作用：
- 您需要为消费者做些什么，以便他们用钱投票支持您的公司和产品；
要么
- 你不知道用什么技术来实现这一点，
那么您会发现自己处于一个复杂的环境中，在该环境中您会得到：
- 放弃认为您知道用户需要什么的意见；
- 提出假设；
- 进行一系列实验；
- 获得最终用户的反馈（起初不满意，将来我们希望找到一种解决他的问题的方法）。
因此，您的团队以及整个组织都有两个重点：
- 什么是客户价值？您需要学习如何通过系统地处理客户的价值来衡量它。
- 快点做 有时有人说，团队的韧性是通过每单位时间测试的假设数量来衡量的。
如何将这一切放到我们的现实中？
领导者的任务是什么？
系统中有两个参与者：您（作为主管）和您的团队。考虑一个简单的例子：一个团队生产产品，但是客户不满意。作为领导，我们应该做什么？在这个故事中，我们的任务是什么？当然，要找出问题所在：作为专家，您去解决问题。假设开发团队在最后一天提交了测试，因此用户遇到了很多问题。接下来我们要做什么？
我们已经知道问题出在哪里，我们已经找到了问题。现在最容易做的就是来到团队，说：“听着，伙计们，你现在正在做这个-不要那样做！我们做对了。”这通常是由儿童完成的。我告诉我的七岁儿子：“弗拉基克，请不要这样做！”顺便说一下，这确实有效-他停止这样做了。是的，后来我的妻子告诉我，他只是不在我面前这样做。当我在工作时，一切都会像以前一样继续。
因此它不起作用。那我们该怎么办？我们更改流程，向团队询问有关可以做什么的问题，以免做得不好。基本上，作为领导者，我们所能做的就是自定义决定团队行为的环境。我们创造一种环境，使否定行为成为不可能，并激发人们采取不同的行为方式：
例如，您正在实现Scrum。从现在开始，不可能每两周至少发送一次结果。不，开发人员可以做到这一点，但是当您作为领导者邀请人们查看Sprint时，他们将收到激励和激励性的反馈，Sprint会毫不犹豫地表达他们对产品的所有想法。出于某种原因，他逐渐感到羞愧，因为每天拖延同一任务-每天他必须向Daily Scrum回答他昨天所做的事情，他今天将要做的事情，甚至是“冲刺目标内”的恶意添加。
也就是说，您创建的环境会逐渐改变人们的思维方式，并开始表现出不同的行为。我们的任务是不断思考如何设置环境。从这个意义上讲，我们不是成为人们的领导者，而是成为建立系统的机制。想象一个系统-齿轮螺栓自己旋转（这些是我们的聪明专家），并且它们之间存在摩擦。您带着油罐到处乱跑，并添加一些开始破裂的地方-您建立了一个可以独立运行的系统。
我们中最酷的人做到了，以便系统出于某种原因开始发展。例如，您创建了一个环境，使团队知道如何看待他们的工作结果，并按照他们的说法进行自我训练：还有什么办法可以使自己变得更酷？没错，如果您建立了这样的系统，那么这对您来说就是麻烦（悲伤（或喜悦））-您不再需要该系统（至少每天都不需要），该系统就会开始发展。这就是所谓的自组织团队。
但是，如何实现呢？
Scrum团队负责什么？
让我们自下而上-只需一支Scrum团队，还没有规模。给您的问题是：在冲刺结束时，哪些团队负责？冲刺结束时，您要骂他们什么？
通常的答案是功能。如果团队是功能工厂，那么功能之间如何关联？我们为什么要执行这些功能，而不要执行其他功能？这些问题没有答案-尚未创建这样的环境。一个典型的例子是大约2.5年前来自Avito的团队董事会。可以看出，在sprint结束时，许多任务仍未完成-只有大约40％的任务准备就绪：
让我们找出问题所在。开始时最常见的问题之一是团队不知道如何评估。我们需要教他们什么是Story Point，如果团队中有支持者，前锋等等，如何正确地处理故事。通过示例向他们展示如何执行此操作。
还有另一个问题-他们可以做到所有，但是他们没有重点。然后，我们带团队进行回顾，并问：“您的工作目的是什么？” 作为回应，山羊神看着按钮式手风琴和一个问题：“冲刺目标是什么？” 好，让我们把一个大盒子放在过去两个星期的工作中。他们听起来，你写道。此后，每个人都匿名在贴纸上加了一个等级：“作为一个团队，您达到了这些sprint目标有多远？” 也就是说，团队必须回答问题，回顾已完成的一切：
让我们看一些示例。
冲刺目标-8
从本质上讲，这些是常见的任务。此外，我创建了一个环境，该环境表明每个员工都有自己的目标（任务）。当另一个人回答时，我用了不同颜色的记号笔：
可以看出每个人都有自己的作品。团队对我们如何实现目标的理解是完全不同的。此后，通常会问一个问题：“我们一个团队多少钱？” 因为看起来每个人都只看到了自己的作品。那个花了两个钱的家伙可能真的在完成一项艰巨的任务，而且似乎没有人帮助他。排名前9位的同志并没有特别帮助-他完成了他的任务，并且可能在冲刺结束时从事自我发展，尽管在团队的另一部分，他们轰炸并需要帮助。
冲刺目标-6件
这是一个不同的团队，但是情况是一样的。对现实的理解已经接近8-9，但是只有6。这正是团队负责人-他比任何人都更了解他们离目标的距离：
冲刺目标-5件
压缩目标。这很有趣，但是已经存在正态分布。3-4-5和7-8-9是团队中三个人的两个子团队，他们一起拖了一份工作，他们或多或少都取得了成功。3-4-5的球员有一个困难的特征，他们没有应付。但是他们大致相同，他们抱怨。三个六岁的老人最了解发生的事情，因为他们在两个方面都帮助了Juns：
冲刺目标-2-3个
如果您捏了怎么办？冲刺目标越少，对现实的理解就越多-我们实际做了什么以及我们实现了多少现实-在人们的头脑中开始吻合：
为什么我要展示所有这些？如果团队有一个目标，为什么会很棒？
目的在敏捷中的重要性
因为敏捷与经典有所不同：
在经典中，我们承诺提供一系列功能，因此我们可以继续发挥作用：要么在开发上投入更多资源，要么出售最后期限。只有这两个参数，因为您需要完成整个卷。
在敏捷中，我们提前了解到我们处于不确定性领域，并且不知道我们的消费者真正需要哪些功能：我们只有假设。有时他们会说幻觉，其中最大的专家是我们的产品负责人。他在两个极限内产生幻觉：资源投入（全职团队，全部100％分配），并且sprint会在结束时准确地结束，而不是早于也不晚。两个参数都是固定的，但我们希望范围是浮动的。这不是一件坏事，这是一个很酷的功能：无论我们是否在做，我们都希望能够更改范围并接收反馈。但是您需要一个仪表-这是目标。目标什么时候射击？
Sprint审查的目的是什么？
进行冲刺审查有两种选择。
团队在冲刺结束时向产品所有者展示了一个有效的产品。看他如何看他。它问了一个最关键的问题：“产品负责人，请给我们反馈：我们已经达到了sprint目标多远了？而我们又该如何改变积压的积压呢？”产品负责人有一个封闭的姿势：“我在这里能告诉您什么？好吧，是的，这些按钮似乎起作用。”产生了一个困惑：如果没有真正的信息，产品所有者如何在工作按钮上提供反馈，也就是说，最终用户没有反馈：
第二种选择是我最喜欢的一个Avito团队故事，也大约2年。这个团队将信使中的买卖双方联系起来。它具有两个关键指标：
- , , , ..
- , .
冲刺中的团队已实施了一项平庸的功能-圆形，这表明在该行的另一端，买卖双方现在在线上：您可以快速写信，他会立即回答。在sprint审查中，他们展示了A / B测试的结果，并为有限数量的客户推出了该功能，并查看该功能是否确实与这两个指标相关。没有明显的相关性，团队要求再过一个星期来收集数据并了解：如果仍然需要此功能，该如何修改？
这是两个不同的选项。当您不仅将其作为口号，而且将其制定为可以衡量的指标时，您的目标也将发挥作用。否则，这又是一种亵渎。
冲刺的目标是什么？
您可以根据里程碑设置目标：在某个日期之前发布，等等。这里再也没有什么信息了：您如何衡量这就是您的消费者想要的？
OKR提供了另一种方法：我们根据指标和特定于客户的目标来设定目标。客户如何与您的产品互动？这如何影响他更快，更好，更好地解决问题的事实。准备用钱为您的业务投票？因此，您必须具有仪表。
正如OKR所说，目标的属性之一应该是抱负。也就是说，我们不仅要提高冲刺客户的生活水平，还希望提高冲刺的速度-最多提高80％，52％等。这是您要跳转的仪表：
底线：我们正在创造什么样的环境？
产品积压只是一组假设。作为团队中这个系统的机制，我们必须在思想上改变人们对积压的态度。您的积压中有幻觉。因此，请务必向产品所有者，企业等提出问题。 - 我们为什么这样做呢？您为什么确定这是我们客户所需要的？如果不确定，我们如何衡量这确实是他们想要的？改变团队和您的业务客户的心态，以便共同放弃对事前了解的感觉。
团队致力于冲刺的目标。请不要对团队进行任何承诺。尽管您将其称为Scrum，但这实际上是将它们推入Waterfall的方式。这与完成sprint中的所有功能无关。不，如果Scrum流程冲刺中的团队突然发现您一周前的幻觉并不是使您离目标更近的话，他们甚至可以更改您的产品积压。当然，两周是很短的时间，到最后，也许对您来说变化不大。尽管如此，从思想上改变-从规模上讲，这个问题全是浮出水面的。
产品和冲刺积压只是实现目标的计划。应定期检查计划的结果，并在拒绝的情况下进行更改。我已经说过，在Daily Scrum中，您每天都需要问一个问题：“我们与总体相关目标在做什么？”逐渐地，您将训练人们去思考目标而不是范围。但是首先您需要重复几次，以便人们最终了解我们为什么这样做。
重点更多地放在最终结果上，而不是交货时间的可预测性上。我们将重点更多地放在更改某些指标上，而不仅仅是引入功能。甚至有可能不完成某些功能：也许，在完成了sprint积压的2/3之后，您将在客户端的关键指标方面得到改善，并且不再需要完成2个功能就不再重要了。目标是另外一回事。
Sprint审核-根据客户反馈评估实现目标的进度。而且，来自真正的客户。对于与您的团队使用的工程实践相关的所有员工来说，这都是一个挑战：持续集成，持续部署等。这就是当前正在席卷敏捷正在尝试应用的其他行业的原因。
例如，制造饺子的新西伯利亚的西伯利亚Gurman公司决定尝试不确定性领域：如果更改饺子或包装纸的调味料怎么办，这将如何影响产品的购买力？凉！ -现在我们将进行实验并获得反馈。但是实验是什么意思？他们以一种新的饺子形式来到零售商那里，但是零售商不想少量采购，而是提供六个月的大量供应-这就是实验持续一年的方式。因此，Sibirskiy Gurman开设了自己的商店，您可以在其中快速获得反馈，但是商店是该项目中成本很高的一部分。
如您所见，在IT中，一切都变得更加简单。一切都已经被发明了。在其他行业中，人们很有创造力，希望尽快获得反馈。但这发生在每个人身上。
在规模上会发生什么？
图片中的某个地方是您的团队。它开始了：每个团队都有自己的待办事项，自己的目标，您了解您的客户是谁，但是由于某些原因，很多人（承包商，利益相关者等）向您奔跑，他们想要您提供其他东西（例如，将幻觉留
在积压中），由于某种原因，您还必须这样做：在最终症状的层面上，我们有以下几点：
- 大量的依赖项。
- 我们通常不事先知道我们依赖谁-这是我必须与谁协商才能推出某些功能的低透明度。您开始在sprint中执行此操作，然后您会发现：事实证明，我们无法自己更改API，必须运行到该API；但是在这里您需要就法规，信息安全等达成共识。也就是说，事先不知道要去找谁。
- , . , . , . .
- — . - , , ? , , , . .
- — . : « , ! !» — « ?» .
所有这些都是从哪里来的，为什么会出现呢？让我们考虑一个经典的获得贷款的例子，所有这些依赖都来自银行。
银行应该做的第一件事就是告诉人们它有良好的贷款条件：高质量，快速等。实际上，与客户合作始于营销。然后是评估，注册等，直到贷款完全清算为止。该公司的运营服务可直接为客户服务并与他进行沟通：
然后是支持，加速和自动化的IT系统-通常，它们这样做是为了使客户能够迅速而冷静地获得贷款。这是我们的员工和组织结构出现的地方。这是一个人为的例子：莫斯科的IT部门有310个开发人员，爱沙尼亚有30人，而美国的另一个供应商（有150人）：
一个关于我的真实例子。当我在我最喜欢的银行获得第三笔抵押贷款时，在第二阶段（快速评估申请），我被拒绝了。在同一天晚上，我的VIP经理给我打了个经典问题：“谢尔盖，我们银行的服务对您有好处吗？也许我可以帮你些忙吗？”当然，我遇到了他：“老兄，发生了什么事？我是您的VIP客户。为什么当我一切都好时我的抵押权被拒绝？”他要求超时，并在晚上打电话给我-他无法立即回答问题，因为他查看了CRM，甚至根本看不到我什至提交过申请的任何信息。
原因是在那几年，该银行将运营服务的第一部分外包给了合作伙伴。也就是说，有一个母行和一个合伙人银行在入口处为客户提供服务-粗略地说，不是爱我的母银行，而是拒绝我的合伙人。由于一家银行的责任终止于另一家银行的责任，因此整合失败。一个小错误使母银行不知道合作银行对他心爱的客户没有很好的对待。在这样的交汇处，企业经常失去其客户，并因此而损失金钱。
我为什么要这样做？想象一下，您的Scrum团队-在支持，前端等方面具有跨职能-在这种结构内。关键问题是：您的团队在解决客户问题方面有多大职能？理想情况下，交叉功能应使您可以在客户与公司的沟通生命周期的任何阶段为客户提供帮助。您能想象一个Scrum团队需要11个团队才能具备多少能力？
不幸的是，这在很大程度上是主要问题：团队不再对客户具有交叉职能。解决方案是这样的：让我们组成一个大型团队，这些团队将尽可能地跨职能。
这是一个示例（两个红色标签）。标有“ Mortgage”的标贴意味着我们正在改变组织结构，以使抵押贷款部门出现（流，部落，火车等，在不同的公司中被不同地称为）。我们将业务（负责发放抵押的财务指标）和团队（居住在莫斯科和爱沙尼亚）结合起来，在此流程的第一部分中开发系统，修复任何集成错误等：
在我的故事中，无法将供应商拖入这个主题。他们说：“给我们写一个TOR，我们将竭尽所能。” 但是无论如何，您都可以组建一个部门，以尽可能广泛地关注其客户。通常会有一个敬酒：“关注客户，价值”，但要计算此单元关闭的步骤数。关闭的越多，温度越低，更精确地说，它将逐渐变得陡峭，并能够解决客户的所有问题。
我为什么要告诉这个？主管的任务不仅是为团队发展营造环境。首先，您需要了解：
- 你在什么背景下？
- 您的团队或部门可以解决哪些步骤和客户问题？
- 你是谁
- 您的业务部门的最终客户KPI是什么？也就是说，您不仅要改善团队，还需要改善整个回路。
作为示例，我为跨职能部门提供了三个选项。
选项1：带平台的每个渠道
其中之一就是整个Web提要，所有Web开发人员都在其中。例如，对于一家银行，主要指标是吸引，因此客户尝试使用贷款计算器进行计算，然后变成抵押借款人。
移动应用（iOS，Android等）已具有与激活和维护相关的指标。也可以有一个平台部门，即制造一个组件，该组件的使用者是其他部门：
选项2：按平台产品分类
第二种方法更酷：更改组织结构，使每个部门在渠道方面都可以跨职能。我们需要修改信用额度-我们在网络渠道和手机中都这样做，就像借记卡一样。该部门可以完全更改任何渠道。但是您需要这样做，以便部门可以对同一代码库进行更改。
这是一个更困难但更酷的选择。企业非常喜欢它，因为借方流正在赚钱：您可以了解我们的收入，再加上开发团队的薪水。结果，您将收入与成本结合在一起。您的部门变成了一个庞大的公司，因为它拥有自己的P＆L，您可以看到自己作为一个微型组织的效率如何：
选项3：逐步进行价值流
复杂的案例有大量的部门，每个部门负责一组指标。在大型组织中，这是最受欢迎的选项：
我们大规模创造什么样的环境？
在规模上，我们创建与一个团队相同的环境。实际上，它的作用是相同的，但是在整个客户旅程中，我们正在跨功能地发展。因此，存在许多难题：与业务，其他团队的沟通，更复杂的周期（不是两周，而是每季度）：
共享季度目标计划：OKR计划（PI计划）
好的。您的团队已经了解到您无法在所有阶段帮助您的客户。但是您了解到有一家企业需要计划以更改客户指标。您会看到仍然有很多人：大约150位其他专家（10至12个团队）。似乎必须与之沟通，因为您依赖他们，而他们-也取决于您。
如何沟通？在所有方法中，敏捷都给出了一个简单的配方：“简单地说：您与某人成瘾，就去和他聊天。”开发人员，尤其是那些喜欢与显示器进行交流而不是与其他人进行交流的开发人员说：“好吧，我做不到，我怎么能说话？”因此，所有框架都提供了交流强制性：“好的，您无法交流。现在，您将按照以下算法进行通信。”
协作式OKR计划（以另一种称为PI Planning的方式）越来越受欢迎。我们的想法是，在很长一段时间（四分之一）内，我们与整个人群一起了解我们的业务范围和内部依赖性，以计划共同的目标。这是一个为期两天的活动，但是如果团队已经学会了彼此之间的交流，那么有些人可以一天举行一次。粗略地说，这是为期两天的便利问答活动，例如：
-我们依靠谁？
-这个季度我们要做什么？
-我们想要获得什么财务指标？业务，请回答。
也就是说，我们确保每个人都与每个人达成协议，并在本季度末前确定我们要经营的地方。这些是三年前Sberbank首次尝试发起此类活动时的真实照片：
联合OKR计划或PI计划是分阶段进行的。
简报
在开始时，需要一个简介。商家应该说：“我希望在本季度末看到这个……”例如，上面是3年前的Sberbank，下面是洛杉矶的GameDev公司Xsolla。顺便说一句，美国人讲了一个简单的故事，他们在激活新客户方面没有任何问题：激活指标很不错。但是重复购买存在一个问题：由于某种原因，重复购买的百分比非常低。第二个问题是由于某种原因他们不购买额外的服务，平均支票价格很低。该业务部门问：“请注意，本季度的所有功能都是针对重复购买和平均支票（附加服务）的增加”：
这是一个良好愿景的样子之一：当我们谈论业务环境和财务指标时。但是我们不知道该季度将要做什么。接下来发生什么？
建筑师的演讲
在IT公司中，我们一定会听听架构师的意见。给他一个有趣的故事！-环境也在变化。在这样的会议上，架构师最终了解了他们的客户是谁（大多数公司架构师认为这是一家企业）：
这位架构师想要快速报告Sberbank的“可怕”情况并逃之run：“我告诉了你一切！此外，他给出了50-100页的概念体系结构。我还能在这里做什么？仍然可以理解，但如有需要，请致电。” 但是在演讲之后，团队的一位领导问了他一个问题：
-亲爱的建筑师！右上角的第三个-您是否知道该系统尚未运行？
- 我当然知道。我自己画了这些立方体。
-您知道它将在六个月内投入使用吗？
- 当然是。
-现在请记住，我们正处于一个季度目标的计划会议中，并且企业希望我们提供功能，理论上应该通过此系统。
在这里，架构师了解问题所在。团队请他留在他们身边，以便他们在规划功能时会共同思考如何做出不合适的决定。
成群（目标生成）
然后，团队出发免费游泳。他们有三个小时，他们必须制定自己愿意每季度负责的目标。这就是所谓的成群（成群，嗡嗡声）。这是一种网络，但在工作框架内：
当然，并非所有事情都那么简单。给孩子们一种算法，以达到他们在该季度可以达到的适当目标。他们制作活动挂图，显示预计的冲刺积压了四分之一。这是必要的，以便他们在考虑到可用性之后，大致填写他们的积压工作，并与其他依赖项团队（谁，向谁，做什么/不做什么）进行交谈，向他们询问以下问题：您将要实现的目标，并且可以用什么度量（度量）来度量成就程度？”
也就是说，我们计划工作积压，然后为它们制定目标，然后我们拒绝这些积压。这只是一种如何达到适当目标的技术。在任何情况下，都不要以为这些人将为这个季度的所有工作投入所有团队：
-团队，提出一个目标！
- ... 而已！
-确定要达到吗？
-不，您只是要求提出。
不，我们正在促进，也就是说，我们帮助实现或多或少的适当目标。
照片中有被迫交流的团队代表。他们有时会带着这样的感觉来到本届会议：“是的，我们了解我们将要做什么，而且似乎我们甚至知道对其他团队的依赖，因为我们上周与他们进行了交谈。”但是，当您直接问我该团队在本季度将要做什么时，这些依赖关系终于暴露出来了：
我们为他们提供了一个工具，使他们在谈论他们的成瘾之后，可以展示他们的成瘾，并查看谁依赖谁。垂直跳跃是一个区块中的冲刺，水平跳跃是团队。在十字路口处，团队提出了它将要执行的功能，并用红色箭头绘制了该功能：“但是他们答应我们在API之前先做一个冲刺，然后在前面做一个按钮。” 这是我们已经与您，谁，与谁，何时何地达成的协议协议：
产品负责人介绍
在演示中，产品所有者进一步展示了他们团队的结果：
唯一想将端到端方案如何发挥作用的人就是企业。在产品类型开头向产品负责人提出的任何问题：“哪种端到端方案都可行？”-常常无法回答：“等等，我们对此组件负责。它将对我们有用，您的问题不适合我们。子弹从我们这边飞来，请其他小组寻找您问题的答案。” 刚开始时，企业一无所知，但它试图将这张照片粘贴在脑海中。
外部依赖
Xsolla具有倒数第二条Tech Ops。伙计们已经知道，有必要分别参加DevOps来为团队内部的环境提供支持。但是那时（六个月前）它是一个外部设备。运营经理还介绍了他-走过红色标贴并确认：“是的，您在这里向我推了我们需要部署这样的环境。我承担责任，我们会做到的”：
有趣的是，当他在一个贴纸上说他们将要做什么时，他的团队纠正了：
-等等，伙计，我们不是问您这个问题，而是其他问题。得到它了？
- 得到它了。
- 你会做吗？
- 我会做的。
- 好。
他们在律师，市场营销，设计师方面遇到了问题-这些人在美国（在洛杉矶），他们没有参加这次会议。因此，对它们的依赖关系被吊死了，但是却感到恐惧：也许他们会做到这一点，但是您需要单独调用，进行通信等。该公司的结论是，他们还邀请他们参加下一个季度计划。
风险处理
对于如何处理风险，存在某种算法。关键思想：事实证明，我们创建了一个环境，高层管理人员可以在其中设置任务。而且它甚至都不可怕，他们已经准备好接受它们。他们看起来：“如果我与这里的外包商签订合同，事实证明我们可以做更多我想做的事，”因此他们参与其中。
这些是解决问题的示例，如果您参加本次会议的所有内容都可以接受：
手指投票
最后一步是检查团队是否真的准备对他们制定的目标负责。我们请您举起手指：
- 5根手指-笔直，对自己的目标很有信心；
- 1根手指-一般而言，目标是一场灾难，需要重做。
您放眼大局，如果您对公司抱有低信心，请他们环顾四周：“看，您自己似乎不相信自己的目标。重做它，使它使您自己相信自己的计划。没有人将它们推入您的体内（至少他们尝试过）“：
联合回顾性季度末：OKR审查（检查和调整）
在本季度末，我们再次召集大家。实际上，这是一次大型回顾（在OKR中称为“ OKR评论”）：
我将通过一个真实的例子向您展示发生了什么。团队在本季度实现的目标已列出。他们有计划地评估对度量的影响，即对企业从团队和公司想要的目标的影响。评估实际成绩：
在这里再次开枪：您是否知道如何评估计划事实，不仅是因为“在我们看来，此功能可能会受到影响”，还包括与业务相关的产品是否从A / B测试中收集了一些实际指标？接触客户。
另一种选择：如果团队还没有建立工程师，不知道如何快速联系客户，他们就像在《规划扑克》中一样，只用手指评估：“在我们看来，我们已经实现了很多目标”：
他们从本质上为自己设定了成就百分比：您可以看到团队在本季度达到了88％。想法是这样的指标显示：
- 您为公司设定的宏伟目标；
- 您知道如何轻松携带它们：
最后，定期进行回顾，每个团队分别工作。关键点：排除了常见问题：不是每个团队分开，而是一次射击多个。通常，我们将标准设为3个以上的团队。如果他们有一个共同的问题，那么有必要在整个单位的水平上解决它：
概要。领导者的问题是什么？
在整个故事中，我们面临的挑战是什么？似乎很清楚该怎么办。但是，您处于一个更大的环境中：其他团队，业务部门，了解您决定为客户旅程的哪个部分以及为哪个客户进行的旅行。实际上，我们中有很多人，例如潜在客户和团队潜在客户：
从规模上对我们有什么要求？领导者有什么问题？大小很重要的事实... :)
Cheburashka突变成鳄鱼，可以在大公司的严酷环境中更好地生存。换句话说，您需要发展自己。这句话很伤人，但实际上，如果您不发展自己，那么您下面的人也不会这样做。在一家大公司中，对您应该成为什么样的领导者的要求是残酷的。您需要能够为大量团队设置环境，即更积极地自我开发很多次。
领导者在敏捷中生存什么
基本上，您需要停止管理人员。形成人们自治的环境。停止成为专家，成为谈判者。
这里值得验证您在所有这些方面的发展情况：
今年，我们将在莫斯科举行第二届TeamLead Conf，而不是在圣彼得堡举行Saint TeamLead Conf。我们已经在11月16日和17日举行了现场会议，讨论这段时间发生了什么变化。我们已经渴望举办真正的面对面会议。这样您就可以在舞台上看到演讲者的魅力，然后在大厅里再问他一个小时。每月喝一杯标准咖啡，并立即看到所有团队领导。然后再过一个月，整理出包含联系人，书籍和关键字的记录。
, , , , . : , , -, , .
. . . 2019 .