Belka Games的研发部门如何运作：流程和小技巧

奥列格·图佐夫，公司 Belka Games 的项目经理，分享了他们启动研发部门的经验，如何构建相关流程，并为有兴趣在公司启动类似部门的人提供了一些建议。

奥列格·图佐夫

首先，我想简要分享一下我们在研发方向上三年的成果。

我们验证了数百个假设。其中两个经过软启动，最终发布了完整版本。这两个假设都变成了出色的项目，成为真正的热门游戏。

第一个是——《纸牌旅行》。该项目在去年十月满两岁。截至本文发布时，它在全球最畅销的纸牌游戏中稳定排名前五。

第二个项目是——《百慕大探险》。我们在一年半前发布了它。现在它进入了全球畅销游戏的前十名。

1. Belka Games研发部门的关键运作原则

三年前在形成研发部门时，我们遵循以下原则：

部门内部的新产品开发不得影响现有产品的开发和支持；
开发本身必须快速；
产品的扩展发生在研发部门之外。

2. 组建研发团队的方法

如今，研发部门由几个团队组成。每个团队验证不同的假设。

在组建和建立每个团队的工作时，我们努力遵循四条规则。

A) 开始时团队应保持小规模

每个团队的初始成员为八人。我们与他们一起启动对新假设的验证。这样可以更快地讨论和分配即将发生的任务，便于管理开发的各个方向。只有在看到产品潜力时我们才扩展团队。

B) 开始时每位员工必须尽量参与开发

在原型制作的初期阶段，我们希望每位员工在研究和开发中都有完整的投入。产品的假设由部门所有成员讨论和实现，因此在这个阶段我们都充当制片人。

C) 团队应由多面手组成，能够应对多任务

每位研发团队成员都是自己领域的首席或负责人。每个人都有自己的专长，但在这个范围内，他们是通才。

D) 研发部门必须准备好放弃项目以及与之一起的员工

软启动后，项目会交给主要部门。每位研发员工可以和项目一起离开，我们始终对此做好准备。此外，我们部门的每位专家都能快速在项目间切换，并不感到沮丧，若决定终止某个假设的工作。

3. 管理研发部门的实践基础

在运营中，我们依赖一系列实践，以尽量减少错误并建立高效的操作开发。

这些实践包括：

建立模板；
按统一标准进行文档记录；
详细制定路线图；
每周冲刺；
任务的正确制定；
强制性跟进；
一对一会议；
员工想法的待办事项清单。

我们将逐一分析这些实践，并在此提供一些工作建议。

3.1 模板

对于许多常规流程，我们准备模板，这为经理在重复或类似的任务上节省了大量时间。

例如，我们在Belka Games也使用模板来处理以下任务：

A) 新员工入职

通常情况下，所有员工的首要任务都是相同的，无论他们的专业是什么。这包括与团队、文档、项目的熟悉。那么每次都创建相同的任务有什么意义呢？我们使用一个包含所有必要信息的模板，这些信息会为每位新员工重复。

B) 开发类似内容

一个项目中可能有按照一个流程开发的内容。例如，章节或事件，它们仅在艺术上有所不同。实际上，我们准备了一次性模板，包含完整的任务列表，条件是将万圣节替换为圣诞节。

建议：每2-3个月检查一次模板，以更新其中的信息。

3.2 文档

合理编写的文档对于开发至关重要，它能使所有参与者的工作更加顺利。在编写文档时，我们始终从明确的目标和建议出发。例如，当我们编写技术规格时，始终依据以下内容：

A) 制定技术规格的总体结构

所有技术规格的章节结构必须一致。这样我们能确保文档的完整性。此外，结构化文件更便于在草稿阶段阅读。

B) 技术规格的完整性

开发的功能应尽可能具体全面地描述。这能消除在讨论、分解、执行和测试任务阶段的疑问。

C) 可读性和理解性

我们的技术规格应书写得足够清晰，以便任何员工在阅读后都能明白该特性或机制的工作原理。

建议：

引入统一且贯穿的术语，并在发生新术语时添加。
避免使用虚拟语气——可能、也许等。这些是清晰工作特性或机制的最大敌人。特性应该是这样的，如何工作，如果需要——提供参考。
在文件中使用固定单位——小时、分钟、秒。不要说半小时，而说30分钟。活动结束前不是两天，而是48小时，依此类推。
建立技术规格的模板，涵盖所有必要的部分。

此外，我们还记录了关于叙事的总体方法。如果项目中有对话，必须制定一个工作指南，依此类推。

建议：仔细考虑文档编写的目标和建议。这大大节省了团队的时间，最小化了收到不符合要求内容的风险。

3.3 路线图

在开发的初期阶段，路线图通常会详细到项目的第一次技术发布。

通常，我们会经过三次迭代来制定路线图。

在第一轮中，项目制作人、部门负责人和开发总监形成产品功能和KPI的列表。

在第二轮中，我们将这一计划展示给负责各自方向的员工，并共同完善文档。

在第三轮中，我们将路线图展示给整个团队。如果没有问题的话，就可以开始工作了。

通常，在我们的路线图中，每个游戏版本都会注明其：

日期（何时开始，何时完成工作）；
目标；
关键功能；
次要功能；
改进（艺术、用户界面、用户体验等）；
内部开发工具；
文档。

某些条目可能会根据版本而有所不同（例如，项目刚开始时可能没有改进！），但是在模板中，它们都是存在的。

建议：第一版的开发时间不应超过两到三周。这将保持团队的活力。

第一版不一定要有技术发布。这里的主要任务是获得报告构建。

3.4 每周冲刺

从标题中可以看出，在Belka Games，冲刺的持续时间为一周。

在研发部门，我们以以下方式进行冲刺：

项目经理基于路线图准备每周的工作初步计划；
然后在与团队的电话会议中进行调整；
冲刺确认后，项目经理会将其发布在项目的聊天中；
在周末，项目经理会总结（实现了什么，未能完成什么）。

冲刺本身类似于来自路线图的游戏版本描述：

冲刺日期；
冲刺中的关键内容（版本启动、发布等）；
将进到每周构建的内容；
不会进到每周构建的内容，但仍在工作中；
分析；
文档；
问题（例如，某些事情需要注意，
解决相关问题或调整流程）。

建议：如果发生了意外情况，请不要调整您的每周计划。移除多余的功能，延长截止日期，只在构建中保留关键解决方案，去掉次要内容。并分析原因，以避免将来发生类似情况。

3.5 任务

在任务形成过程中，我们通常遵循以下模板：

A) 任务名称

名称应明确任务所需完成的内容。不要写得过于复杂——保持简洁。还可以 указать优先级和/或专业性。

B) 任务描述

在描述中尽可能全面（但不罗嗦）地阐明需要完成的内容。根据任务附上所有必要的链接——如技术规格、对话指南和所需原材料的路径。您还可以提供相似任务的链接作为例子。

C) 任务之间的依赖关系

务必注明任务之间的所有依赖关系。这样您可以直观地了解需要优先推进的开发内容。这有助于制定每周计划。

D) 指派执行人 + 到期日期

谁将负责实现该任务，何时需要结果。如果您有大型开发团队，所有任务都应指派给领域的负责人。他会将任务分配给各位专家，并根据负荷设定合理的截止日期。

E) 跟随者

在Belka Games，我们遵循共同决策的文化，但这并不意味着每个任务都需要包含大量跟随者的名单，并在每个问题上引发激烈讨论。

每个任务都应有一份紧凑的跟随者名单。在大多数情况下，没有必要在任务中分配不相关的专家或整个艺术团队——照顾他们的邮箱。

F) 任务定位

项目版本的结构始终与我们的路线图相对应。任务应始终处于其功能模块中，并在正确的部分下。不应将任务放在错误的部分，例如动画任务放置在战斗通行证的分析部分。

建议：自己主动创建任务——不要将任务甩给他人。这有助于全面了解整个功能/版本/项目。

3.6 跟进

如今，大多数IT公司都在远程工作，因此确保信息不会被淹没在Google Meet中显得尤为重要。因此，在我们的研发部门，我们积极使用跟进制度。

当我们在会议上讨论重要问题时，项目经理会记录关键信息。之后，他会将其整理成可读的文本并分享给所有团队成员。通过这种方式，我们保持开发团队在同一页面，确保对决策达成共识。

通常，每周项目经理会回顾跟进，并为其实现设定任务。

建议：如果您无法参加会议，请务必请求组织者为您准备会议的跟进记录。这样，您肯定能始终了解发生的事情。

3.7 一对一会议

我们每月至少与员工举行一次一对一会议。这让我们能够掌握整个团队的动态，并关注每位开发人员的心理情绪状态。

项目经理为每位员工建立一个单独的文档，在会议上与之共同查看。文档中项目经理会重复一些有用的链接，包含开发项目、员工所在国家的生产日历等。这里面还会记载员工的KPI、需要在会议上解决的相关问题，以及已解决问题的档案。

建议：建议每月初进行会议。关于会议的最佳书籍有：《商务中的反馈》 安吉拉·莱恩，《所有上司都这么做》 布鲁斯·图尔根和《高效能管理》 安德鲁·格鲁夫。

3.8 员工创意的待办事项清单

在文章开头，我提到过我们需要最大程度上让每位员工参与。待办事项清单在这方面对我们帮助巨大。我们的研发部门拥有一个工作空间，员工可以在其中记录他们对当前产品或其他任何产品的创意。

这样，团队成员明白他们的意见很重要，他们也积极参与项目和部门的生活与发展。此外，当需要实施新功能时，我们随时可以参考这一文档。

4. 结论

在Belka Games的研发部门，我们认为，最终结果的主要责任落在项目经理的肩上。因此，开发错误的责任主要也在于项目经理。

当然，没人能免于错误。因此，项目经理的主要任务之一就是将其最小化。仅在这种情况下，才能妥善管理团队，以获得成功的产品。

最小化错误意味着：合理设置透明且不过于复杂的流程，以及正确选择团队成员。