如何在规划中融合创意和管理——Natalia Popova来自Overmobile的案例
关于如何在规划新功能时避免混乱，App2Top特别采访了Overmobile游戏团队的经理及WN Academy游戏项目管理课程的主持人娜塔莉娅·波波娃。
这篇文章得到了教育服务平台WN Academy的支持，该平台积极邀请领先的专家为其课程和企业培训提供指导。
娜塔莉娅·波波娃
我叫娜塔莉娅·波波娃，从事游戏开发管理工作已经超过15年，主要专注于移动游戏。在这篇文章中，我将分享一些关于如何结合创造力与管理的观察。避免官僚主义，但也不陷入无序状态。
在游戏开发中，创造性的混乱与结构之间的冲突非常明显。两者都很重要，但偏向任何一边都是危险的。许多团队常常面临的问题包括：
无成果的研究与开发
长期的创意工作没有结果，但却消耗了大量资源。这样的安慰并不能替代实际成果。
无灵感的内容工厂
团队不断扩展，流程僵化，报告定期，但创造力几乎为零。「没有创意」似乎成为游戏成功后附带的一种状态。
自由掩盖下的混乱
表面上拥有创造自由（团队会产生新颖的想法并发布版本），但内部却存在着过度劳累、领导力枯竭、时间无谓浪费以及沟通不畅。这并不是创造力，而是缺乏有效流程的证明。
这种做法常常被浪漫化：“我们很灵活”、“我们有动态流程”、“我们不想要官僚主义”。实际上，这只是混乱，人在这种环境中容易消耗殆尽，而产品则频频出错。
真正的创意环境不是无政府状态，而是一个想法可以诞生并顺利实现的地方，不需打破和妥协。
经理的任务不是单纯控制，而是处理项目上不断发生的事件和想法。接下来我们就来谈谈如何管理想法。
处理想法时，我推荐以下链条：想法存储 -> 待办事项列表 -> 迭代开发。
我想任何项目经理在学习Agile时都尝试过创建待办事项列表，但很快这样的待办列表就会变成堆积如山的杂物，最后变成想法和笔记的坟场。
在多年的游戏开发管理中，我找到了解决这一问题的方法：在处理待办列表前，应加入一个我称之为”想法存储”的环节。
想法存储是一个分为以下列的卡片板：
收件箱 / 需要思考 / 已批准 / 小批准 / 取消-暂停
- 收件箱 — 记录团队的所有想法。
- 需要思考 — 对于那些存在疑问和不确定的想法。比如技术风险、引入旧玩家的方案、整体平衡的疑虑等。我还把看似工作量过大的想法放在此列中。这是一个适合存放暂时还不能被割舍但需要进一步思考的想法池。
- 已批准 / 小批准 — 可以转化为技术规格的提议。我喜欢交替处理大型和小型想法。程序员的工作表中常常需要一些“小任务”来过渡大型功能。
- 取消-暂停 — 有时候团队很难放弃没有明显弊端的想法，但想法一直停留在存储中，从季度到季度，从年到年。这意味着更高优先级的想法一直在出现，理应删除。这个列帮助保持想法存储的整洁，但不用让游戏设计师立即删除想法。对团队来说，一年后放弃这些想法要容易得多。
团队和项目决定详细计划的周期。通常，这是三到四个月。在移动市场中特性趋势常常变化。半年时间的计划可能在实施时已经过时。因此，我倾向于季度计划。稍后我们将讨论如果公司要求填写一年的路线图该如何处理。
在想法存储中，根据季度（或者半年的）发布量，添加列数。在移动游戏中，版本通常在每一到两个月发布一次。因此，季度需要添加三个列，我将它们添加到上述列的左侧。
然后，与GD/制作人一起将Approved和Small Approved中的卡片填入这三个发布列中。在某些情况下，可以从需要思考中的卡片中选取些加入“远期”版本中。这使得哪张卡片需要在什么时间点解决得以清晰可见。
这种方式可以在一个可视化空间中同时保有：
- 高层次的功能计划；
- 可撰写技术规格的想法列表；
- 需要思考的想法列表；
- 所有进入的想法列表。
经过多年实践，我发现将这些东西同时保存在眼前是非常重要的。
可能会有人问，如何无需估算时间就可以将想法卡片分配到各个发布批次？
通常来说，有经验的项目经理能够大致估算大多数功能的时间。很少会出现一项功能需要一个季度，而项目经理评估其为一个月的情况。
无论如何，该计划的目标是为团队确定工作的优先顺序。这就是产品计划。
如果公司要求一年计划，同样可以将存储中的卡片分配到整年计划中。然而经验表明，即便如此，季度后还是有必要重审计划。
使用这个计划和存储系统有哪些额外有用的操作？
在好的卡片表管理工具中可以在卡片上标记表情符号。例如，我使用以下标识：
- 金钱表情符号 — 对于直接影响货币化的功能（至少在我们的认知中）；
- 箭头 — 对于预计会影响用户留存的功能；
- 蝴蝶结 — 对于参与整体产品价值但不直接产生影响的功能（例如，“聊天回复”或“在某排行榜显示玩家等级”）。
通过在卡片上标注表情符号，可以确保发布计划中不会全是蝴蝶结。这类任务很容易使人沉迷——尽管产品价值毫无疑问很重要，但这样的任务并不会显著改变项目的指标。
第二个需要注意的发布列方面，是新老玩家功能的比例关系。
通常来说，这种利益冲突中人们更容易“忘记”新手及其用户转换漏斗的改进需求。
总体而言，相较于老玩家的货币化及活动，新手的首日留存和转换工作更难且乏味。
老玩家已经在那里，他们会给客服或者社群发反馈。在情感层面，游戏设计师更倾向于应对他们，而非期望通过改善首日留存而增加的玩家数量。
当然也有较少的几率团队忘记老玩家的需求，但这种情况也是存在的。因此一定要用老玩家的视角看待发布列：游戏能否提供新的挑战和新的兴奋吗？
通常两项检查会发现计划功能的不平衡：在这种情况下，再次关注Approved和Need To Think列以“重新平衡”发布。
为什么在想法尚未成熟时就要组织计划工作呢？
我想提到一个由皮克斯创办者之一艾德·卡特马尔在其书《创新公司：如何管理创意型团队》中给出的概念。
随着时间推移，团队中会出现一个“野兽”："以此指代任何需要持续新内容和资源的庞大作业群体......它无情、贪婪，总是渴求下一个大项目的素材。”
在实际中，热门项目团队面临类似的情况：公司扩张和成长危机如同野兽降生，此时经理们忙于喂饱野兽，给所有人安排任务。
等到游戏设计师冒出新的功能想法吗？没时间！30位画师和10位程序员等着任务呢！
探索想法？放弃失败尝试的功能？虽然我们不是汽车工厂生产线，常落入的陷阱是惧怕团队的时间空窗，开始以“人”而非“想法”来计划。
艾德∙卡特马尔描述刚冒出的团队想法：不成熟、笨拙，就像不受欢迎的孩子。此时的想法尤为脆弱：可能被否定、低估、破坏或冻结。因此，它需要被保护，给予成长的时间和空间。
我很喜欢这些形象鲜明的比喻，它们对游戏的开发与支持都适用。项目经理应思考如何保护“受人遗弃的孩子”免遭“野兽”的摧毁。不然项目将变成仅靠老玩家维持而最终日渐式微的循环生产线。更多的项目甚至都活不到培养出核心忠实付费玩家的阶段。
优秀的想法很容易夭折。有时是因为“野兽”的侵蚀，或者因无人查看的待办事项列表沉沦。珍惜、组织和管理团队的想法，即便它们还不美观、不明确、未用数据支撑——在很多方面，创造这样的环境就是项目管理的真正工作。