这篇文章将尝试把从0到1的游戏项目管理过程抽象成标准sop，尽可能把需要做的事情标准化，希望能通过这种方式探索出一条合适的游戏项目管理之路。
游戏项目的一大特点在于立项初期追求敏捷，这时相较于工具&规范，PM应该更多关注如何快速响应变化和产出demo，因此以下会从两个方面实操PM参与项目的过程。
Part1 亲身参与项目的管理方式(项目内)
当项目经理亲身参与项目时，对项目的目标和实现目标的方式会有更多参与的空间，除了基础的项目管理工作外，需要分出一部分精力参与到思考项目的实际设计中来，和团队成员一同思考论证项目方向的可行性。
初创团队
①明确项目范围和成本，制定预研计划
对于新的项目，相对于流程和工具，最开始让项目运转起来更重要的是大家有着明确的目标，方向一致。
一个不到5人的小团队，期望做一款运动品类的游戏合集，在正式开工之前，项目经理和团队一起确定了里程碑计划，明确关键时间节点和需要交付的内容范围。
②制定工具&规范
工具&规范这块，只需要几个简单必要的晨会周会等轻量化流程能让项目正常运转下去即可。
由于项目体量不大并且有明确的目标，立项初期大家通过teambition给自己/彼此开单的方式记录每日的工作内容，每周五固定时间做一次当周的进度总结，体验目前的版本(PC/手机)，记录问题并讨论解决方案。不断重复这个过程直到demo review会。
③承担一些项目内的公共任务
在研发过程中，项目经理需要跟着团队一起成长，从各方面为团队提供帮助，调整工作重心以适应团队需求。
在demo阶段项目经理不需要对流程和工具投入太多精力，可以将空出来的时间投入到项目研发中，比如项目可能需要更多调研竞品，收集目标用户反馈。这时项目经理可以和团队一起参与调研的过程，打入竞品/论坛内部了解玩家的真实想法，尝试访谈一些核心玩家，为明确项目方向提供助力。
④根据项目进展适当引入新的流程机制
当项目运转发现问题或痛点时，考虑适当引入合适的流程，由浅入深逐步推进，如果一开始就实施完整流程sop，不但影响效率，也很容易引发大家的抵触情绪。
项目demo进度稳定，到了需要背景音乐/音效的阶段，这时项目经理可以参考已有项目的规范，适当裁剪，形成适合目前团队的音效提需/回收流程。
中途加入团队
①团队访谈了解情况
项目经理中途加入团队，首先需要了解团队成员的情况和团队目前的运转方式，收集各自的痛点，包括团队负责人和团队成员各自关心的问题(通常位置不一样面对的问题同样也会不一样)
团队负责人认为团队的沟通效率不高，感觉美术需求一直爆单但是实际上做出来的资源最终实装至游戏内的却不多。项目经理通过和团队成员逐一访谈，发现是因为需求确定时间较晚，美术同学做的时候是根据提需求的顺序做的，而不是需求的优先级，因此会出现实际做出来的低优先级资源因为程序带宽不足无法实装至游戏内。
②将信息整合在一起，将收集到的问题排列优先级，先处理高优问题
在访谈的过程中能收集到各种各样的问题，这时项目经理需要判断这些问题的影响范围，优先处理影响范围大的问题，下面简单列一些过往访谈收集到的问题，因为每个团队的情况不一样，大家可以自行判断应该优先处理哪个问题(已做模糊处理)。
团队成员策划A：验收流程不明确，缺少自测，提交验收的内容有明显bug;美术资源在实装后还出现对效果不满意需要反复调整的情况，并且改动也没有对应的单子追踪，大多是口头需求，无法跟进最终效果。团队成员程序B：人手不足，按编制我们团队应该有10人，但是实际上目前只有8人，其中包括两名校招生;开发时间比较紧张，出现过策划案还没完全定下来就抢先一步宣讲的情况;有时会出现开始功能开发但是前置美术资源还没做完的情况，也不知道对应的资源什么时候做完。团队成员美术C：插单和临时需求多，并且提的太晚了;信息同步有问题，有时候策划改了需求但是美术同学没被通知到;不清楚同组其他同事手上在做什么;主美审核返工比较多，特别是到交付节点的时候，经常卡在审核这边。
③处理问题的过程中观察并记录团队的状态
一些问题的解决方案往往需要团队成员的配合，在方案确定后提前和重要干系人沟通讨论方案可行性，确保得到足够的支持后再落地推进方案。每天记录下当日发现的问题，对于需要额外支持的问题有计划地寻求帮助。
推进方案的过程中也是了解每位团队成员的好时机，利用这个机会逐步建立信任。
④定期(版本、sprint或自然月)回顾团队的工作总结，根据实际反馈调整策略
每达到一个关键里程碑节点，最好根据实际工作产出和计划做对比，观察团队的需求完成情况，并以此为依据作为未来版本需求承接能力的参考。
每个人都有自己的估时习惯，也许过于乐观、也许过于保守，过程中项目经理需要尽量了解每个人的估时偏好，做到自己心里有数。
⑤每一到两个季度重新对团队进行访谈，再回到第2步开始
不同阶段团队面对的问题可能是不同的，定期访谈(通常是年中和年终两次绩效考核之前)一方面是了解大家的工作状态，另一方面是和团队成员沟通对过往反馈问题的解决情况。
Part2 作为中台支持项目的管理方式(项目外)
作为中台支持项目管理的特点之一是不实际参与项目内的管理或只是协助团队成员制定项目的大计划，对接的项目数量通常较多，且每个项目团队的情况各异，不一定有完全符合所有团队的标准流程，这时一方面需要通过访谈，了解各个团队目前遇到的困难和核心诉求，拆解各个团队的业务链路，看看过程中哪些是特殊的，哪些是可以共用的，可以考虑制作一套完整的流程，针对不同团队的特点做裁剪和适配，每个团队只用这个流程中的一部分，有这份流程作为底子在，最终目标是能用一套流程应对各种情况。
①和每个团队负责人访谈
对于了解团队现状来说，访谈总是一个好的打开方式，通过和不同团队的负责人聊天，项目经理在建立联系的过程中还能收集到一手信息，其中最重要的是团队的业务目标和遇到的实际问题。
业务目标是团队存在的意义，遇到的实际问题是项目经理需要投入精力解决的方向。接下来还是举几个实际存在的栗子，分别代表这三种不同的问题类型，让读者有个基础概念(已做模糊处理)。
团队A主打休闲竞技品类，希望打造移动端的糖豆人体验。目前遇到最大的问题是使用的自研引擎，对3C的支持不够完善，引擎底层还在打磨3C的体验，但是项目等着用，出现了卡脖子的情况。团队B主打社交品类，希望打造一个绝美的场景，并在场景内加入各种互动元素，让进入其中的玩家能通过游戏中的内容实现社交的目的。目前遇到的问题在于美术资源产出速度不达预期，并且因为对美术品质要求较高，经常出现资源返工的情况。团队C主打家园养成品类，希望打造一个有趣的生态，通过设计足够的目标和激励，让玩家有动力建造自己的家园并和好友们分享，最终实现正向循环。目前遇到的问题是上层虽然对项目的最终形态有一致预期，但是对于实现的路径有各自的看法，导致项目方向迟迟无法确定，产生了一些开发资源浪费，影响了整个团队的节奏。
②尝试为每个团队定制解决方案
之前已经收集了每个团队的信息，下一步可以case by case地处理每个团队的问题，这么做是希望减少外部因素干扰，单纯为当前团队做出最有利的方案。下面针对上面三个团队，尝试给出一些解决思路。
对于团队A，如果自研引擎接受定制需求，那么可以参考成熟的商业引擎整理一份需要的3C功能清单，和引擎团队共同讨论引擎的后续发版规划;如果自研引擎不接受定制需求，那么需要考虑是团队A的业务目标重要，还是使用自研引擎开发更重要，做一次取舍。
对于团队B，需要考虑项目目前处于验证阶段还是铺量阶段。对于验证阶段的项目，美术的问题可能是资源管线还没完善，可以从流程的角度看是否存在优化空间;对于铺量阶段的项目，如果流程管线都没问题，则可以看是不是人出了问题。
对于团队C，可以考虑设置每个版本的关键里程碑，XX/XX确定需求、XX/XX封版提测、XX/XX发布，通过时间节点的压力倒排上层需要给出结论的时间。
③还原各团队完整流程，并尝试抽象成一个包罗万象的“超级流程”
现在已经针对各种类型的问题给出了一些解决方案，我们可以从解决方案作为切入点，还原各个项目优化后的完整流程，形成自己的流程库，并在过程中尝试抽象出一个包容不同团队的“超级流程”。比如在需求准备阶段，哪些职能需要在什么节点做哪些事;在封版提测阶段，如何定义封版，提测的条件有哪些等。
④裁剪出适合的流程给新团队使用
上面我们已经有了一个“超级流程”，如果有新团队需要，可以考虑为其挑选其中适合的部分。
⑤不断迭代
在各个团队实际运作过程中迭代各自的流程，反哺至“超级流程”中，不断循环。
-从0到1的项目经历对每个人来说都是一笔宝贵的财富，也是项目经理职业成长的必经之旅，上面的内容不一定适合所有项目，掌握自己的方法论，以不变应万变，拥抱这个充满变化的世界~
京公网安备 11010802030320号