血、汗与小团队。在Belka Games中，项目结构是如何变化的及其原因
在改变团队结构的过程中，Belka Games如何成功提高了更新频率，并创下了两项日收入记录，——开发公司总监维塔利·库兹明讲述了这个故事。
维塔利·库兹明
距离我们勇敢地尝试重组“计时器”团队已经将近两年了。从职能分工转向了一种时尚、在某种程度上神秘、尚未完全理解但又如此诱人的迷你团队结构。
显然，每种结构都有自己的优缺点。一种结构在一家公司中可能会非常成功，而在另一家公司中却可能无法奏效。这篇文章是一次回顾我们与迷你团队相关的历程，汇集我们的经验，并呈现给同事们。如果能对你有所帮助，我们会很高兴。如果你决定分享自己的经验，那就更好了。
促使我们做出这一决策的问题
让我们回到两年前。那时我们还在使用老旧的职能结构。
这种结构使得项目开发在不同的职能部门之间分配（例如，测试部门、开发部门、游戏设计部门等等）。我们每个部门都有自己的职能领导。项目经理协调他们的工作，而最后（就像项目的命运）则由制作人负责。
那时我们正将“计时器”移植到新的引擎上。开发路线图已经固定。当然，我们想考虑到所有因素，但此时项目已经八岁，积累了相当的遗留代码，因此我们常常面临不可预见的任务。结果，版本范围不断扩大，发布的时间安排也时常被推迟，项目经理们则愁眉苦脸。
作为这一混乱局面的“樱桃”，更新的关键功能的开发比预计的要长，且在过程中进行了多次重做。
对情况的分析揭示了，形成我们目前这种情况的关键问题是开发结构。它有两个主要缺陷，这使我们决定进行转变：
- “瓶颈”。在运营期间，团队的规模增长到了60多人。这个规模让项目经理、制作人和职能领导无法高效工作。每个领导负责的任务数量大大超过了他们的能力，导致需要从管理层获得批准的任务长期拖延。
- 对于不同的功能，每次都有不同的员工参与，团队之间缺乏团结感。
令人惊讶的是，即使在这种情况下，项目的收入仍在稳步增长。成功在某种程度上让我们放松了警惕，使我们对尖锐而明显的问题视而不见（正如我们现在所认为的那样，然而当时却认不出来）。
飞得越高，摔下来的痛苦就越大。在我们的案例中，第一波疫情结束了。收入开始受到调整，而问题并没有消失。当前的市场形势悄悄告诉我们需要进行改革。
解决方案，或者说“万岁革命！”
此时市场上的竞争对手每月发布更新，刺激财务指标增长，几乎将新内容填充到他们的项目中。
我们决定也参与这一竞赛。目标明确。同样明确的是，凭着目前的结构达到这个目标几乎是不可能的。
我们决定将未来的新结构定位为迷你团队。
在很大程度上，我们受到了Spotify轰动一时的做法的启发。简单来说，他们将团队分为自主的小组，一些小型跨职能的自组织团队，每个团队由八人（或更少）组成，他们一起工作，负责他们所开发的功能的整个阶段（包括支持和运营）。有关这一方法的更多信息可以在这里查看。
在我们开始构思的时候，这一方法暴露了一些缺陷，因此我们与它相距甚远。考虑到Spotify本身也没有使用它的结构，我们的做法是合理的。
当我们首次了解未来结构时，我们在向首席执行官的演示中固定了它。
在演示中，我们解释了如何通过转向新的结构来解决我们的难题。
- 消除项目经理和职能领导造成的“瓶颈”，我们为每个团队引入了团队领导，团队领导负责所有运营事务（每周计划的制定、任务的创建和分配、一对一的会议）。
- 要消除制作人作为“瓶颈”，我们需引入功能所有者（实质上是能够做出产品决策的游戏设计师，他负责从概念到发布的整个功能）。
- 为了建立团结的团队，我们将员工分配给特定的迷你团队，通常是一起致力于新功能的团队。
- 为了促进迷你团队的自主性，我们鼓励他们在内部做出决策和任何倡议。
- 为了更好地理解团队的工作量，并更好地调整优先工作的节奏，我们设定了期望的更新节奏（至少每月一次）。
主要的问题在于迷你团队被设计为自主和自给自足的业务单元。每个组需要有足够数量的各类专家，以便在工作的过程中无需向其他团队借用人员。这意味着我们必须大幅增加员工人数。
我们必须准备扎实的论据——并了解如何以最低的成本调整模型。提前说一下，并非每个团队都达到了最初设想的100%配备。但我们达到了某种混合结构，在这一结构中，我们在Slack中分享未被利用的资源。迷你团队中的团队领导会在此渠道中发出对专家的请求。
对首席执行官的简短陈述、系列问题以及收到了领导的绿灯。我们开始采取行动。
我们对迷你团队的理解
我们认为迷你团队是自给自足的（几乎）自主业务单元，每个团队都有明确的专业化和在即将到来的更新范围内的责任。它们是自给自足的，因为它们能够通过自身的组成将功能从构思推进到发布。在团队成员中，通常包括：
- 游戏设计师（即功能所有者，负责文档并确保功能的愿景在开发过程中不分裂）；
- 开发人员；
- 艺术家和UI设计师；
- 动画师；
- 测试员。
每个团队由团队领导负责。团队领导全权协调开发过程，并负责人员管理：一对一的会议、目标、发展计划。
管理领导者也是必须的，因此结构中项目经理位于团队领导之上。项目经理负责协调团队领导的工作，将迷你团队交付的各个元素整合在一起，并监督其实施的时间。
我们将迷你团队分为三个责任区。
- 实现主要关键功能。重大产品增量通常是带有新游戏机制的临时事件。
- 对现有的事件武器进行运营，使用旧的、经过验证的游戏机制。
- 处理技术相关事项。通常这些事项与业务逻辑无关，隐藏在“引擎盖”下，但对产品同样重要。
也有一些按功能划分的团队。例如，叙事设计师不隶属于“功能”迷你团队，只按需加入，因为在这些团队中，他们没有全职的工作量。
职能领导并未消失。他们获得了“专家”的光荣头衔，并置身于迷你团队的结构之外。他们的主要任务是提高本专业人员的工作质量。换句话说，首席开发人员审核开发者的代码，首席UI设计师审查设计稿并提出修改意见，首席QA负责测试用例的完整性等等。为了让他们能够专注于专业人员的发展，我们尽量减轻他们的运营负担，因此任务分配和管理工作由团队领导负责。
以下是我们组织结构的示意图。
我们并非在每个项目中都实现迷你团队。这里的主要标准是员工人数。在我们看来，如果团队总人数超过50-60人，引入迷你团队是有意义的。在其他情况下，我们保留职能结构。
请注意：对团队的整个理念进行推广并不简单。我们也是人，因此我们非常喜欢抵制变革，反对一切与习惯性现状相违背的事情。我们召开了多次会议，详细解释变革的价值，并阐明我们所追求的目标。有些人对此理念表示认可，但有人至今仍抱有抵触情绪。在这里，可以给出几个建议。
- 首先争取团队领导和专家的支持，让他们成为你的盟友。通过意见领袖向普通员工推广理念将更为容易。
- 对团队诚实。我们坦率地说这对我们而言是一次重大实验，可能会失败。我们没有排除“回退”至旧结构的可能性，并与团队讨论了这一点。
- 让员工明白结构不是“铁板一块”，专家之间的流动是可能的。这对不希望陷入单一任务的员工很重要。
重要细节
有一个重要细节帮助了整个迷你团队的构架充分发挥作用，满足了我们对发布频率的需求。我们称之为“平行开发”或“交叉开发”。
其核心在于，迷你团队“阿尔法”正在开发更新1，而迷你团队“布拉沃”同时努力开发更新2。在此过程中，他们不会争夺资源，也不会在任务上交叉，因为每个团队都在开发自己的功能。完成这样一个功能的完整开发周期平均需要两到三个月。在合适的节点开始开发，我们成功达到了每一到两个月发布一次的频率。
迷你团队的弱点和问题
当然，每个系统都有缺点，我们构建的这一系统也不例外。让我们走过主要缺点。
较高的“交易成本”。每个迷你团队都必须有同步点，以便协调工作并理解其目标及当前阶段。我们的团队通过Slack聊天、Asana项目管理工具和Google Meet会议进行同步。恰恰是这些会议的数量成为一个痛点。我们最初的安排如下：
- 周一早晨的所有团队领导和专家的通话；
- 每个工作日（周一至周五）的十五分钟晨会；
- 周五晚的总结和计划。
随着时间推移，迷你团队变得越来越独立，因此我们开始每周召开三次晨会——周一、周三和周五。在某些团队中，我们尝试将周五的晨会和计划会合并为一场会议。我们还允许专家选择性地参加晨会和计划会（如果他们受到个人邀请或认为有必要提出某个重要问题）。
需要提前写出两到三个更新的任务书。如果不这样做，团队会无所事事。理想情况下，团队应该顺利高效地连续推出版本。例如，当UI专员完成功能“A”的设计时，关于功能“B”的任务书应该早已得到制作人的批准。
我们有没有做到？同样，不是完全做到。但我们认为在这一点上我们有了显著的进展。当前项目的“计划范围”为六个月。这意味着我们知道在接下来的六个月里，我们将要制作哪些功能，并且每个功能都有已准备好的任务书。
灵活性不足。首先，在持续的生产过程中很难调整计划，因为功能一个接一个地被开发。移动游戏环境是不稳定的，有时不得不放弃即将完成的功能，如果对它的信心降低或对更好的功能有了新的想法。其次，有些功能的成功不是第一次就能实现的，需要进行重大修改。我们尽量将这些修改交给最初做该功能的团队，因为他们具有最高的专业知识和最低的入门门槛。由于团队的发布是轮流的，修改有时需要等待两到三个月，而在此期间，某个制作人则会感到失落。
让我们来谈谈优点
我们已经提到了旧职能结构的弱点：领导、项目经理和制作人任务繁重，团队之间缺乏合作，流程缓慢。在新的结构中，我们希望通过让团队更加紧密合作，实现稳定的发布节奏，并尽可能减轻领导和管理的工作量。以下是我们所取得的一些成果。
团队协作。在我们的迷你团队中，成员固定，这使得内部流程不断优化。动画师总是知道如何将动画最好地传达给程序员。程序员也提前为动画师准备基础工作。由于团队协作，问题得以减少，集成得以顺利进行。
参与感。在大公司中，员工在团队扩展时往往难以感受到自己对产品的影响和在整个目标中的贡献。当你的部门有20个测试员时，很难意识到自己做着重要且有益的事情，很多人会开始简单地“完成任务”。而在迷你团队中，目标感回归：团队核心有明确的KPI，一个成员的工作直接影响到其他人的工作，这使每个人都更充分地参与到工作中。
瓶颈减少。现在所有运营任务通过团队领导分配给团队。职能领导不再是瓶颈——而且现在他们有更多时间来改善流程并培养自己领域的员工。
发布频率提升。每个团队独立工作于自己的任务列表，它们的责任区域不重叠。在截止日期到来时，每个团队按时交付自己的功能，这样构建版本可以及时发布。
总结
我们达成了目标吗？毫无疑问，是的。转向新结构，加上其他一些变更，帮助成熟的“计时器”找到了新的财务潜力。在很大程度上，这是因为新内容频繁投入生产。需要强调的是，我们从较长的开发周期转向了每一到两个月发布一次更新。结果，我们两次打破了单日收入记录，创下了历史新高。
迷你团队是否是万灵药，能解决所有问题？当然不是。对于成熟团队来说，转变一定会是痛苦的。而且，这一转换必须是有理由的：你必须清晰理解你所解决的问题。如果已有成熟的组织结构能让你解决业务问题，最好在“动手”之前考虑十遍。
我们决定这种机制是有效的，目前正在尝试将其应用于另一个项目——借鉴先行者的经验，采用行之有效的做法，同时对其进行优化和调整，以适应当前的现实。
