你可能玩过小游戏“羊了个羊”、“跳一跳”、“泡泡射手”，但是你可能不知道，在一家游戏公司，可能有上千个“羊了个羊”在同时开发。相比大型游戏，单个小游戏的开发周期短、人员少；但同时因为竞争激烈，需要大量开发，敏捷试错。这就意味着，小游戏的项目管理方式，不同于传统项目。游戏项目很多，管理人员很少，如何破解挑战，确保游戏上线的“量”和“质”？
小游戏一个月上线，同时管理上千个非典型项目
什么叫非典型项目？大家去年可能玩过一个微信小游戏，叫“跳一跳”。在游戏行业，这种小游戏的研发，就是一种非典型项目。
首先，这类游戏玩法很简单，所以整体产研周期短，涉及人员也不多。有时候，研发甚至就一个人
然后，市面上有很多这类小游戏，所以竞争很激烈，不确定性很高。有很多小游戏你压根没听过；有的游戏甚至都没机会出现在你面前，一个项目从立项到结束就一个月，发现效果不好就不试了，这种情况非常多。
所以，哪怕是一个不大的游戏公司，一年做几千款游戏都是很常见的。这时就会出现一个问题：游戏项目很多，但是管理人员是有限的。
传统项目，不论是面向政府或企业的大项目，互联网产品或大型游戏项目，团队成员都相对固定，项目目标和时间都有约束，发布节奏也是定好的；相比之下，小游戏就是非典型项目：项目周期短，人员少；并行项目多，人员切换频繁；业务流程长，涉及信息繁多。
举个例子，做一款小游戏，要发布4-5个渠道；如果同时有100个项目推进，这个事情就要乘100，信息量就会很大，管理成本就会很高。
调整目标，梳理项目管理的“三条线”
一个小游戏公司有10个研发、10个测试、10个美术、10个策划。这些人，接下来两星期要做的所有事情和任务，就是项目组的管理对象。也就是，把团队成员的时间安排，当成项目来管理。
传统的项目怎么管的？情况可能是，研发人员小明正负责项目A 1.0版本的开发，做着做着需要切换到项目B，做一个发布任务；然后项目C来了用户反馈，问题很严重，他也要紧急处理。这种管理就导致，研发人员在各种任务之间切来切去，很多项目进度都不理想。
那么，将人员和人力当作项目来管理，项目和任务变成资源分配给人呢？一切都迎刃而解。让项目围绕人运转，让人围绕工具节奏运转，成功实现了“干掉项目经理”的愿景。
现在，我们把项目拆成三条线：价值线、产研线、发布线。
-
价值线主要是产品经理负责，从需求分析、评审到产品规划，要确保大家做有价值的产品。
-
产研线需要项目经理和产研的协作：研发专注具体的交付任务，在固定周期内完成开发，项目经理更专注协作效率和持续交付。这个过程中，项目经理把大家的时间当作管理对象。
-
发布线主要是市场人员来协调，确保交付内容一定可以发布，并根据市场需求来安排发布节奏。
这样，驱动我们的都是外部因素，而不是我们自身的规划。这其实要求大团队，对市场有更前置的思考。
非典型项目的标准化、透明化
传统的管理就是很多张表：验收反馈、用户反馈、发布渠道、发布计划......很多时候，我们在表里找到一个产品名字，但是在另一张表换了个名字，就找不到了。
使用飞书项目，就把这些七七八八的表，转成了一个工作空间：有需求、有发布、有bug、有迭代......而且，这些信息都能联动，当你看到产品某一个维度的数据，就能顺着了解整个项目的数据，确保有清晰的上下文。
节点流模式，可以根据业务场景灵活拆解和裁剪，帮助项目经理横向把控项目进展。
项目经理通过配置不同团队的人员视图，能够全面了解当前人员占用情况，快速为团队分配项目和任务，也能更加公平地衡量每个人的投入与产出收益。
通过建立跨部门的关联关系，将渠道、版本等与产研流程一对一绑定，横向拉通多方信息，跨部门、跨业务、跨项目各自独立又互通有无；同时，字段、人员、排期自动同步，不再需要费劲扒表格、人肉追踪来定位责任人，真正实现产研与市场流程“你中有我，我中有你”。
