在文章和报告中，当他们谈论团队管理中的案例时，他们通常将自己局限于讲述问题所在以及如何改变情况。 但是这次我们有一个独特的机会来了解团队如何进一步发展以及一切如何结束-实际上，它并没有结束，而是在继续。

这是有关ivi中的敏捷转换的故事的延续，该故事是“ 如何在可伸缩的scram中使头皮生存并保持对代码质量的控制 ”。 在公司的TeamLead Conf上，公司技术总监Yevgeny Rossinsky（ eross ）解释了为什么可能有必要撤回整个团队的重组，如何不吵架和帮助开发人员，以及如何维持和提高业务效率。

公司背景

ivi-最大的合法互联网电影院，拥有4800万用户，每月总计花费7000万小时。 Ivi拥有62,000单位的内容，可以通过不同的设备获得这些内容，并且始终具有出色的质量。

碰巧的是，在尤金（Eugene）在TeamLead Conf上发表这份报告的那天，正是公司的生日。 9年前，该项目的网络版本首次发布，而两天后，Channel One的强大功能为ivi带来了大量用户。 该公司甚至认为这是DDoS，但能够有尊严地承受。

本文是关于启动新产品的-完全重新启动所有应用程序。

观看视频以了解未经审查的版本，或者以第一人称阅读报告的笔录。



首先，让我们谈谈用于了解损害程度的技术和能力。

能力：

• 后端（Python，Golang，Java）；
• Web（JavaScript，Node.js）；
• Android（Java）
• iOS（Objective-C，Swift）；
• SmartTV（JavaScript）；
• Windows / XBox（C＃）;
• 索尼PS（JavaScript）。

对于2016年的每项能力，我们都有自己的团队，即 iOS小组，Android小组等 还有一个后端团队，另外还有一个产品经理团队，他们提出了新功能。

必须进行转换的主要问题是所有平台都不同，包括它们的积压和优先级不同。 我们真的想在我们的应用程序中建立一个单一的信息空间 。

通常，在构想四个月后，复杂的功能就会出现在所有平台上。 同时，它在3天后出现在一个平台上，然后根据积压的优先级，以不同的速度在不同的平台上推出。 事实证明这是可怕的，原因如下：

• 在4个月的时间里，该功能可能已经具有完全不同的含义，并且对该功能的需求可能会消失。
• 由于通信问题（在这种情况下很明显），人们以不同的方式实现功能。

由于产品具有三种在不同平台上以不同效率工作的货币化模型，因此每个平台上的积压优先级是不同的。 原则上，某些功能永远不能在单独的平台上实现。

简要介绍转型

2017年，我们引入了“ 价值流”的概念-这些是负责特定业务任务的跨职能团队。 为了了解我们的业务有哪些具体任务，我们从整个公司召集了大约25至30个人，邀请了从事灵活方法论的教练，并在2天之内制定了我们应具有的价值–发展方向。

有5-6个价值流。 他们把这些家伙放在一起，给每个人一个产品负责人，他将淹没这个特定的方向（更多详细信息请参见此处 ）。

我们知道痛苦，鲜血，眼泪和喜悦，并达到了很好的指标：

• 在不同平台上同步卸载相同功能 。
• 上市 时间倍数减少 。 许多功能的发布仅停留在每个平台的发布管理周期中，例如，因为Apple不允许单独卸载每个功能。 因此，功能已分组，平均而言，我们每两周发布一次。
• 消除了产品所有者，技术经理和团队负责人的“瓶颈” 。
• 开发人员开始理解为什么他们“锯”新功能。

我们度过了非常出色的一年- 2017年，收入几乎翻了一番 。

但这还不够，2017年底至2018年初的生活给我们一个惊喜。

为什么需要新产品

商业设定了新的目标。 令人惊讶的是，任何软件的开发都是出于某种目的而存在的。 出于利他原因很少编写代码。 为了使公司证明其存在的正当性，其所有者和股东设定了团队必须实现的某些目标。

我们的股东没有说怎么做，而是说他们想要实现的目标。 如何-团队必须决定。

团队面临着提出如何赚更多钱的任务。 我们进行了一次头脑风暴，杂货部门以及技术部门得出的结论是，为了实现雄心勃勃的目标（按照惯例，将付费观众人数增加一倍），我们必须在原则上将重点从免费观看电影转向付费电影。

几乎所有提出的假设都不太适合旧产品的概念。 更确切地说，它根本不适合-用户转换的任何动机流都基于这样一个事实，即在某些平台上实现了这种转换，而在某些平台上却没有限制，而在另一些平台上却存在。 我们的团队已经9岁了，我们已经积累了很多东西，使我们无法自拔。 以一种好的方式，有必要重写所有内容。

多项定性和定量研究表明了旧产品存在的问题 。 事实证明，我们比智者所想到的落后了2-3年。 例如，如果大约5年前在移动设备上将汉堡菜单放在左上角是一种时尚现代的做法，那么随着大屏幕的出现，人们就停止了到达那里。 直到2018年，我们真的有了汉堡菜单，人们以某种​​方式解决了这个问题。

可怜的用户已经习惯了一切，但这并不意味着您需要保留一切。

许多框架都需要重构。 我们发现了逻辑缺陷，并且像在任何长期存在的代码中一样，我们有很多旧的不是很好的代码。 开发人员真的不喜欢它。

例如，雇用想要用Objective-C编写的开发人员非常困难。 我们都会受到时尚的影响，甚至会受到懒惰的影响-如果有任何工具可以让您完成同一件事，但是又更快又更有效，我们希望使用它。 劳动力市场的情况如此，您可以写一个总结：“我想用Swift写作”，即使您不知道如何用Swift写作，您肯定也会有所建树。

必须采取一些措施，这是阻碍发展的问题之一。 因此，我们不得不重写过时的组件并实现现代框架。

目标

我们想要：

• 用单一设计创建新产品。
• 使我们的良好推荐系统负责发布产品中的所有模块。
• 更正逻辑接口错误。
• 清理代码。
• 迁移到新的统计系统。
• 实施设计系统。

所有的挑战都非常艰巨，尤其是设计系统，因为很少有跨平台工作并且与程序代码分离的设计系统。 他们主要生产用于不同平台的JS引擎。 实际上，用于传输有关产品外观信息的机制是在代码内部。

我们做得不好，因为我们要处理视频，而处理视频需要使用或多或少的本地工具。 另外，如果您不使用本机工具，那么从操作系统发行版开始总会有1-2步的积压。 发布后，所有通用框架（如Xamarin）仍然必须赶上。 而且，在加入我们之前，我们非常贪婪-Google和Apple都推荐我们，因为我们使用的是本机工具。

本机工具有助于制作高质量，优质，快速的应用程序。 就视频而言，这仅是必要的。

搜索管理解决方案

确定了目标之后，我们便着手实现了这些目标。 让我提醒您，我们被划分为Value Stream，不同的开发人员坐在不同的团队中，并且我们面对着残酷的现实-怎么办？

似乎我们已经有一段时间习惯了人们的习惯，现在游戏规则已经改变。

当然，首先，我们尝试使用Value Stream像以前一样工作，接受以下逻辑计算：“让这样的业务方向参与的Let Value Stream将重构与这些领域相关的所有组件。”

哦，我们错了！ 大约一个月后，事实证明，要重写每个应用程序的核心，实际上，您需要进入业务规则的所有领域。

区分Value Stream的责任范围非常困难，因为当人们坐在不同楼层，不同房间时，Value Stream承担着什么角色。

最可悲的是，由于开发平台的语言和功能不同，协作的作用已完全消失。

在Value Stream的框架内，iOS和Android开发人员看到了相同的功能，并且他们有话要说，他们正在讨论业务逻辑。 当他们每个人都看到一个低层的框架时，该框架与后来的最终产品之间的关联性很弱， 同步就完全消失了。

原则上，有些人脱离了正在发生的事情的含义。 提姆利德人是第一个灰心的人，因为他们作为负责任的人，需要挫败和不相信人类员工，才能回到真正的教会的怀抱中，以便在正确的方向上编写适当的守则。 结果非常糟糕。

一个半月后，人们意识到Value Streams对于成品非常有用，但是当需要从头开始编写产品时通常无效。

像所有简单的事实一样，只有在赤脚穿过耙子，甚至让电流流过耙子后，您才能理解它们。

一切新事物都被遗忘了。

我们将返回原样

在成功实现敏捷转型之后，我们决定做所有事情，就像2016年一样，因为必须赢得民主权。

为了使每个人都有投票权，并且要求并使用了这项权利，有必要形成规则和将在其中发挥作用的生态系统。

在没有生态系统的情况下，必须独裁地做一些事情，以便以某种方式形成规则。

做了以下事情：

• 他们将人们带回到了钛金属的翅膀之下，将他们从面向功能的编程重新定位为普通的编程。
• 产品经理被分配给流程用户。 在我们的例子中，这是下载，授权等。
• 我们尝试将新产品的所有要求正式化，并在开发之初就达成了一致。

一切似乎都是合乎逻辑的，但是就像两年前一样，我们遇到了同样的问题。

它将无法正常工作，再次是组织中的问题

两年前的主要问题是：集中化和决策。

威权主义导致“瓶颈”的出现，即没有时间向开发传达功能的团队负责人，技术经理和产品经理。 已经锯了8年的产品很难在几个月内重新考虑。 当80％的概念准备就绪并且还没有20％（仅在纸浆所在的位置）时，这并不酷。 这极大地困扰了团队。

当开发人员正式返回团队领导者的管理时，与产品经理的实时沟通就少了很多，并且需要将传统知识正规化。 被口头交流完全取代的东西又变成了形式主义-他回来了，没有人回来。 但是工程师是以这种方式安排的，他们是在研究所受训的：存在问题陈述-需要解决，没有问题陈述-世界崩溃了，算法将无法工作。

在此过程中，发现了逻辑上和体系结构上的错误和错误计算。 想象一下编写代码已经有好几年了，而这段时间你一直梦想着重构它，而当机会出现时，事实证明所有的想法和概念都不是很好，或者根本就行不通。 梦证明是错误的。

同时，就像评估截止日期的通常情况一样，企业听到一件事，发展听到另一件事。 此外，业务仍然分为两部分，然后开始对截止日期施加压力，并希望在昨天获得新产品。 事实证明，在第X小时，开发人员认为还有3-4个月的时间，因此该公司一直在等待昨天的发布。 每个人都很沮丧，团队开始流泪。

你做了什么

我们对我们的生活进行了一次大规模回顾，并揭示了开发人员和团队负责人最担心的问题。

需要重做功能 ，通常是3次。 老实说，问题的一半恰好在问题陈述的一边，后一半在实现方面。 但是，开发人员当然坚信整个问题在于问题的提出。 在任务方面，董事是相同的。 没有人愿意认为自己是错的或有罪的，每个人都说问题出在另一侧。

支持旧的应用程序 。 拥有数百万美元受众的服务不能仅仅被放弃。 在编写新产品的同时，还需要对旧产品进行一些处理。 这太烦人了！

设计系统的实现。 我们为这个方向感到骄傲：它确实使您能够快速完成非常复杂的事情，并且产品看起来统一。 但是我必须训练设计师关于什么是JSON，设计师必须向开发人员传达外观也很重要。 关于这一点，很多副本被打破了。

缺乏信息和“为什么？”问题的答案。 没有Value Stream，一些开发人员将不再理解为什么要做某事。 信息传输中断，因果关系部分消失。 那些有能力问我们为什么这样做的人感到高兴。 不太交流的人认为白痴坐在楼上某个地方，他们发明了无法设计的东西。

缺乏有关新业务规则的文档。 由于缺乏信息，因此缺乏说明应用程序应如何正确运行的文档。

每个人都尝试过扮演建筑师的角色，但并不是每个人都喜欢它。 对我来说，这是最大的发现。 团队负责人首次估计处理申请的截止日期约为一年半，这毫无价值。 之所以发生这种情况，是因为每个团队负责人都希望自己通过系统的所有部分，也就是说，他确实不想委托和分解应用程序体系结构，而是希望将所有内容保留给自己。

使用这种方法，您确实需要一年半来对体系结构进行重新设计。 但是，在这个世界上，有了这样的用语就没有关系了。 因此，经过长时间的讨论，我们得出的结论是，应该将团队负责人的架构功能委派给某些关键领域中来自开发人员的某些经验丰富的战士，他们尤其希望参与其中并且感觉像建筑师。

事实证明，这很有趣-承担责任是不愉快的。

称自己为架构师或团队负责人以及成为团队负责人是两个很大的不同。 事实证明，并非所有人都愿意接受这一点，即如果您保重并浪费转换，那么这仅是您的责任。

我很天真，出于某种原因，我认为我们团队中的每个人都具有这种勇气。 我忘记了在蒂姆利德之前，您需要成熟和成长。 在过去的一年中，我们中的许多人都朝着这个方向前进，有些人意识到他们不想长大，但是广博，也不想成为团队负责人。

如何解决这种情况

除了将timlid的角色分解和区分到各个建筑领域之外，我们还成立了所谓的飞行报复小组（VOC），并吸引了质量控制专家（QA）参加。 首先，它们比所有人都更自由-尚无新产品，您现在可以编写测试用例和测试套件以用于后续回归。

事实证明，业务规则尚未完全制定，并且该公司没有多少人知道新应用程序应如何工作。

我们为质量检查设置了以下任务：

• 我们需要有关业务规则和应用程序工作逻辑的最新文档。
• 不仅需要经理和技术经理，还需要新业务逻辑的支持者。

由于我们有一个新的应用程序，因此我们需要重新做一遍，因此我们需要可以提出诸如以下问题的人员：如何处理此类错误，应用程序在这种情况下应如何运行。 我再说一次，主要的案例已经描述过了，但是魔鬼在细节上-那些相同的20％需要关闭。

我们开始创建动态微命令。 尽管人们没有被移植到任何地方，而是依附于特定方向的产品，但是来自QA的一位有条不紊地从事项目工作的人负责：

• 收集开发人员的问题，创建问卷；
• 会议的组织和记录；
• 正式文件；
• 提前编写测试用例和测试套件。

当我们到达终点线时，它使我们可以连接外包商，外包人员进行测试，以提高发布准备的速度。 我们有大量的平台，我列出的只是我们使用的工具。 例如，在SmartTV中，有6-7个平台，您需要分别释放每个平台，进行单独的回归等。如果您有预定义的业务案例，则可以在此处轻松地连接外包商和外包商。

挥发性有机化合物的引入极大地减轻了提姆利犬的负担。 他们有机会不被管理任务分散注意力，而是有机会根据已开发的材料来制定有关代码的战略决策。

“惩戒飞行小队”项目达到了预期，我们进入了发布线而没有互相残杀。

接下来是什么？

2018 , — , , . . , , . «, ,» — .

, , 2016 Value Stream. , . , , . .

, , .

, , . , , , 2018 4 . , , , .

.

.

— . , , , , , . -, , .

: , , , . . .

TeamLead Conf . , , , . 23 24 .