当产品很大时，开发人员会走极端：
-代码太漂亮-发行缓慢，
-过多关注流程-很少关注开发，
-快速发送生产中的新功能-代码太糟糕，
-过多关注自动测试-很难进行更改，
-关注界面的速度-避免使用新功能，
-UI改进-很少关注代码体系结构。
在报告中，我谈到了如何避免这些极端情况并实现成功的团队合作。
-我想谈谈如何生活在大团队中。 一个大型团队就是人数超过这个会议室的人数。
我希望他们像在GIF上的这些人一样顺利地工作：
我没有一个非常庞大的团队，但是我只是窥探了整个公司中大型团队的情况，我只想与您分享一下。
要想象规模，您必须说出明显的事情。 Yandex不仅仅是搜索页面。 我们很多人，一万多
在这些“许多”中，大多数是开发人员。 我们生产许多不同的产品，而不仅仅是针对网络。 关于商品，关于汽车，关于饮食，各种铁块，人工智能的一切都有。 开发人员参与其中。 即使看起来似乎我们在谈论汽车或食物。
我们有很多服务。 它们不适合幻灯片。 我希望我说服您Yandex很大。 大事情很难管理。
重要的一点。 我要继续说的是，首先，是非常简单的简化； 其次，我记忆力下降，所以我会解释一些东西。 第三，有些事情我故意为了故事的连贯性而摆弄，等等。 同时，总体思路是正确的。
我将从很久以前开始。 然后我才来到Yandex。 当时的安排与现在大不相同。 该部门是按专业划分的-对开发人员来说很酷。 它看起来像这样。 该公司在结构上分为经理，他们彼此之间有所作为。 还有其他专业。 实际上，当时没有设计师，但传达了含义。 当然，还有开发人员。 然后在该结构内部将其切成更小的碎片。
开发商用锯或钳子。 戴着帽子的人有冰沙，戴着头盔的人更是铁杆，那时还没有设计师，还有为每个人都买得到的经理。 因此，他们做好了准备。
如果您深入研究这个故事，那么在层次结构内部就是这样。 最硬的头盔里有个家伙，他碰到了所有的颠簸。 在他的指挥下，他有一些精明的经理，然后是一些较轻的经理。 我夸大了，但想法很明确。 每个专业都使用相同的层次结构。
带圆滑帽的花花公子玩法也一样，这很有趣。 您是一名开发人员，服从另一位开发人员，他了解您的工作，并为您自己喜欢的东西而称赞您。 太好了
但是，假设某个产品有想法。 而且他只有其他下属的经理-这是如果他很幸运，并且至少有一个下属的人。 所有其他人根本不听从他的意见，但是某种程度上需要实现这个想法。
他说：“首席设计师同志，我有一个很棒的主意。 我需要一个设计师。” 他会回答：“嗯，首先，您的想法很奇怪，其次，所有设计师都忙于我。 快来Q5。”
如果经理此刻相信他，他将一无所有。 如果他坚持不懈，有才华并准备克服所有困难，也许他会说服这位首席设计师。 他会说-好吧，两个月后您将接任这个家伙，他必须有空。 当然，Dude的截止日期将填满并在四个月内发布，但是至少有机会开发该流程。
然后，该经理将去找主要开发人员，说：“我的设计很酷，一个很棒的主意。 我需要一个后端。” 所有这一切将继续：“后退者很忙，您的想法很一般，设计很糟糕。”
最后，他可能会为自己组建开发团队并有所作为。 一方面，只有最酷的想法才能幸存，另一方面，做某件事确实很困难。
但是对于开发人员来说，这很酷。 开发人员由其他开发人员评估。 开发人员当然喜欢技术上的一切。 关于杂货店，首先让经理说服这是一个好主意。 由于所有开发人员都处于同一结构中，因此每个人都有共同的参与方，因此，技术专长的交流非常牢固。 凭借产品专业知识，事情不是很酷，但是谁在乎呢？ 和大量的研究，因为它是给粉丝的。 也会受到其他开发者的评价。 您可以发明高科技的东西。
显然，这种方法存在问题。 开发人员并不十分担心产品的功能，因为他们不服从经理。 如果出现问题，头盔管理者会被嘲笑，但是对开发人员没有特殊影响。 反过来，产品很难更改。 实际上，他们只能说服，说服并以某种方式跳舞来证明他们的想法很酷。 然后，开发人员会相信它，当然会使一切受到伤害。
但是事实证明，在如此庞大的开发人员队伍中，您必须偶然抓住一个人，每个人都做一些有趣的事情-但是组装一个大型而复杂的，不断交互的事物是有问题的。
同时，所有这一切都发生了，该公司每年需要并增长两次。 而且您需要做点什么。 正如Arkady Volozh所说，管理公司就像炸肉丸一样。 它需要不断地翻转。
公司的结构正在发生变化。 与其按专业划分每个人，不如按产品划分。 经理正变得越来越重要。
事实证明，如果大大简化和夸大其词，则大约是这样的方案。 我们有一些很大的产品，在产品内部分解为较小的部分，每个部分都有一个设备齐全的团队脱颖而出。 有设计师，开发人员，管理人员，他们全都生产此产品。
看来问题已得到解决，但是有一个新问题。 团队可能很小，自然会有一个前端，一个后端，一个设计师，一半分析师和其他人。 他们很老套，没有人谈论他们的主题领域，看来这不是必需的。 他们正在看他们的项目，但是他们在过程中收到的所有发明都没有人要传达，也没有人问如何做得更好。 他们不知道自己在隔壁后面正在做什么，也许他们也在做同样的事情。 而且，他们自然会直接做同样的事情。
经理似乎有更多的权力，但他对开发的所有细微之处并不了解。 如果需要，一个有才华的开发人员可以告诉他，如果不完全重写该项目，则什么也没有。 经理的下一个选择是什么？ 他会相信他，或者他会禁止他这样做，每个人都会不满意。 通常，存在问题。
我想以某种方式平衡产品的所有方面。 例如，一个产品有一个团队，例如，它认为漂亮的代码很重要。 尽管他们将此代码磨练到理想状态，但很明显，发布已被推迟。 不酷 或团队认为：“好的，只要有很酷的过程，代码就会以某种方式发生”。 实际上，不，它不会发生。 这也需要有人注意。
或团队说：“我们需要非常迅速地前进，每天滚动功能对我们来说很重要，”但是那时代码的质量正在失去关注。 或团队说：“好吧，上次我们绕过耙子时，我们意识到质量很重要。 让我们用自动测试涵盖所有内容。” 为每个功能编写了自动测试，但是现在这些测试必须在每个池请求上运行，并且它们需要很长时间才能完成，并且一切都变慢了。
或者：“我们知道，如果界面速度缓慢，我们的用户将离开。 让我们快速实现界面。” 但是事实证明，每个新功能都是一个额外的代码，需要通过网络传输并执行，这会减慢接口速度。 “那么我们就不做新功能了，一切都会更快。” 或者：“用户喜欢美丽的时候。 让我们做的漂亮。” 但这里面没有关系。
为了寻求这种平衡，事实证明需要再次更改某些内容。 同时，团队再次急剧增长。
通常如何解决？ 用一个流行语。 我们也接受了。 我们有一个相当普遍的论点，但有我们自己的发明。 说什么 它说，让我们为团队的人员降温，使每个人对最终结果负责，这里有所有必要的专业知识。 然后让该团队选择首先要执行的任务，选择他们应该在内部执行的流程。 通常，产品比过程更重要。 仅此而已。 听起来不错。 看来甚至可以解决部分问题。
但是仍然有一个问题。 例如，假设这样的Scrum团队不断适应周围发生的事情，不断变化（他们的组成不断变化，他们可以不断地形成，解散），并且在原则上，没有共同的地方可以汇总员工的发展历史。
也就是说，有某种开发人员，他有一些长处，他在某个地方燃烧。 因此，他加入了一个新的Scrum团队，他们对这些优势一无所知，也没有立即开始使用它们。 相反，也许他不坚持某件事，没有人知道这一点，确保他被抽中，并确保该项目不会因为他在那儿没有专门知识而遭受苦难。
现在，我们正在尝试将解决方案应用到公司的另一部门中，看看会发生什么。 这个想法如下。 开发人员与其领导者（也包括开发人员）之间存在某种相当稳定的结构。 一切就像刚开始时一样，当领导者了解您的工作并与您分享利益时，他可以就如何更有效地工作并在某个地方为您提供帮助方面为您提供一些建议。 这些链接已经维持了多年。
为了满足产品的需求以及如此稳定的结构，仍然为每个产品，甚至产品的每个方面都组成了快速的虚拟Scrum团队。 现在，我将告诉您更多信息。
这些团队是临时的，快速的，他们可以专注于当前一些最关键的事情。
看起来像这样。 这里有一些小片段，例如网络。 在内部，如果您看到的话，一大堆人正在浏览此网络。
这就是整个故事的平衡过程。 有绿色家伙，他们负责确保接口快速。 他们唯一感兴趣的是，根据速度指标，一切都应尽可能酷。 让其他一切随心所欲。 但是还有其他一些家伙，原则上讲速度并不是那么重要，但是重要的是，在一段时间内，我们设法为生产中的用户推出了许多新的酷功能。 现在，帅哥们不可能说：“速度是最重要的。 不要运行任何东西。” 因为对于那个团队来说，这从根本上是不可接受的。
但是相反，负责这些功能的团队不能再抛出一堆新代码，而是说：“因此，我们不得不启动功能，一切变慢了，但是我们启动了功能”。 他们会彼此同意，以某种方式互相帮助，最终一切都会好起来的。 蓝色帅哥不断疯狂地编写测试。 他们用测试覆盖了所有内容，现在有很多测试，而且它们都运行缓慢。 帅哥不在乎，因为他们只负责报道。
但是很高兴有其他人说：“但是对于我们来说，整个开发过程要快是很重要的。 从我们设置任务的那一刻到用户开始使用它的那一刻，这段时间应该减少。” 他们会同意的，一切都会好的。 他们将帮助编写测试的人使这些测试运行更快。
某人仅负责确保所有内容在结构上都很酷。 而且，他们甚至不必考虑代码中正在发生的事情。 他们可以从以下方面进行思考：“一年半后一切都应该放在哪里？” -现在专注于这个未来。 但与此同时，还会有人收紧圆角，校正阴影并考虑动画，以便用户明天更加快乐。 并且，当有这样的责任分配，并且每个团队相互补充时，就会取得平衡。
这一切都有几个作用。 我已经说了一些有关此事，但是，尽管如此，这很重要。 每个人都有自己的直属上司，该上司对自己一无所知，并确保一个人专业成长，个人成长和快乐。 同时，有一个这样的团队的负责人说测试覆盖范围应该增加，而其他一切都不那么重要。 当这两个角色同时发生时，事实证明或多或少。
还有其他不同的东西。 在这种情况下，事实证明，对于参与同一产品的开发人员而言，他们是从不同的结构组装成这样的虚拟团队，因此，来自不同管理人员的关注度更高。 总而言之，这种经验可以使产品变得更好...
……然后转移到结构经理看待的其他产品上，这是在这个大型团队工作期间产生的一些发明。 反之亦然，也就是说，这些箭头可以朝相反的方向旋转，这也是正确的。 这就变成了溢出和专业知识，并且以某种方式很方便地将团队重组为现在更重要的产品。 因此，公司最有经验的同志对不同产品的关注度增加了。
好的，有点同意一切应该如何工作。 但是，如果我们有一个结构化的老板和一个产品的老板，那么如何评估一切是否顺利？ Sergey Berezhnoy在上周六的前一年详细谈到了这一点。 我将简要重复一下总体思路。
首先，与该过程中的其他参与者进行比较，然后再由所有有关方面共同决定一个人是否运作良好。 就是说，它的结构领导者负责监督他在长期市场中的发展，负责短期产品任务的人并不会根据该人努力工作并且晚上没有睡觉的事实进行估算，而是根据他如何真正实现自己的目标。 这是目前我们认为最公平的一种方式。 如果您脱颖而出，即使没有特别的劳累，也很帅-让我们赞美您。 在我们看来，这种平衡是很好的。
其他好处。 当我们同意我们可以快速组建各个团队，为每个特定需求重组人员时，至关重要的是，这种过渡必须尽可能简单。 只有对所有内容都进行了充分描述和记录后，这才有可能。 这样的构造本身迫使需要文档。 而且，在编写文档时，产品会自动变得更好。 这是两个方面的好处。
除了分享专业知识外，人们的过渡还使得不同的产品在外观和内部布置方面更加相似。 您还可以从中受益-用户了解如何使用系统，因为他们只是在另一个项目中使用了类似的东西。 当然，您最终可以重用最佳实践。
这样的团队分别专注于每个方面：他们要么编写测试，要么对速度负责，要么对美观负责-但他们仍然无法对邻居发生的事情打分。 事实是，他们的领导者对其他团队的开发人员负责，而他们自己可能很快就会转移到另一个团队。 对他们来说显而易见的是，有条件的明天它将影响他们。 因此，在集中精力时，对所有事情的责任不会丢失。 结果，在项目之间切换就足够容易了。
同时，人们有很多成长的机会。 因为在所有事物都用花岗岩模制而成且不会混合的结构中，人们有时会意识到他们已经了解了一切。 他们尝试了该项目的所有工作，并且顺其自然。 他们不需要每次都对自己进行突然的努力。 如果他们不断更换团队，不断改变人才的延续角度，他们的专业知识就会自动增长，所有这些都将增强整个系统。 而且无论如何，它并不无聊。 您不太可能不会同意这一点。
, : « , , ?». , . , , . , - , , .
, . , , . ? , , , , .
,
. , - , , . , . , , — , , , : «, , . ».
, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .
: — , , , , . — . .