告别996？资深游戏PM：游戏项目开发的高效秘诀

作者：陆拾肆院 游戏陀螺 2019-04-30

市场环境

手游行业类似于风潮行业，需要观望当前的游戏风向。但是信息的获取都有置后性，一款游戏的研发周期为1~2年，当厂商跟进风潮的时候，往往是其他厂商已经成功收获大量红利的时候。这样就会面临项目上线时风潮是否已过，以及能否吃到被成功产品洗过剩下玩家的红利等等，种种问题。

手游行业的研发厂商不得不用加班、赶工、反复变更方向适应风潮等方法，用庞大的人力、时间成本，去追赶那稍纵即逝的风潮，与其他研发厂商厮杀，觊觎能在尚未变成红海的蓝海中争取到一席位置。这也是导致游戏行业加班的其中一个原因。

卡牌、回合制、FPS、MMORPG社交、二次元、MOBA、SLG、传奇页游风、吃鸡、沙盒…跟随风潮席卷而来的就是这么一堆堆品类彼此相似的手游产品。

也存在有研发厂商试图引领风潮，这些团队需要不断的试错重做，进行内测市场验证，长时间的积累沉淀设计经验。其中耗费的试错成本难估计，上线之后的疯狂买量刷榜的成本，团队承担的巨大心里压力，在这些因素的影响下成功者寥寥可数。

当然厂商也可以跟随着经过市场验证的成功方向去制作游戏，即成熟IP+成熟品类的方式。此模式下的主流思路，在可量化的方向上，达到最优。

比如，美术上达到高质量，在shader、纹理、渲染上表现出极致；

比如，IP版权购买，世界一线大IP；

比如，文案设计包装，足够新奇创新，拥有吸引力；

比如，基础玩法上的高标准，战斗突出强烈爽感打击感，枪械模拟真实弹道，极为舒适的玩家付费体验，流畅的即时反馈体验… …

整体游戏的制作方向即在已经成熟的框架品类基础上加上这些高标准，并进行微创新。日后游戏的发展的趋势也会不可避免地走持续精品化道路。

游戏成功上线之后，还要面临着手游行业获取用户成本上升，传统买量策略不能起到预期中效果的问题。18年初，安卓仙侠类游戏买量CPA 50~60，19年游戏CPA 150左右并不遥远，另外19年各投放渠道腾讯、百度、字节跳动等，开启收割模式，CPA势必会直线上升！在如此高的CPA下，ROI回本关键：抢夺大R高付费玩家群体。

期望管理

期望管理是领导力的体现之一，这也是管理工作中最难的部分，管理好期望可以有效的增加团队凝聚力。达成统一的项目期望，形成明确目标。

由于游戏研发需要三个团队的共同协作，但三个团队的职业技能、思维方式又各不相同，致使每个部门的期望也不同，也容易造成各部门之间沟通的阻塞。

以一个系统模块功能的制作为例，下面是三个部门的思考方式。

策划团队：体验合理性、设计趣味性等

程序团队：逻辑严谨性、技术应用性等

美术团队：美术表现力、美感程度等

不仅部门之间期望互相不同，同部门中的期望也不尽相同，战斗策划与系统策划，在思考设计功能上的侧重点就不同，服务器程序和客户端程序在互相配合阶段，思考的侧重点也不同。不禁感叹，如果我们都像三体人一样，思维透明，那么我们的工作体验就会截然不同，效率异常高效。

期望的混乱会严重拖后团队的工作效率，影响团队内氛围。管理好期望即统一思想，以最优的力量完成目前最需要完成的任务，减少人力及项目资源的浪费，好钢要用在刀刃上。当成功统一思想之后，团队的整体效率也会提高。

管理期望的关键，保持信息的及时共享同步，以及确认策划、程序、美术真正能理解核心思想并且统一认同。给团队成员同步信息，这一点其实很容易做到，但是让团队成员认同共同的期望却很难，这里面考验制作人、管理人员的管理水平，人际关系技能，话术技巧等等。这过程中注意一点，如果双方在统一思想过程中都各退一步达成妥协，那么最后的结果普遍是“双输”。

需求收集

由项目发起人或者制作人确定项目或者里程碑的目标，然后根据目标进行拆解需求，这些需求的目的是使项目或者里程碑最终的目标达成并通过相关方的验收，最后所有的需求需要最终通过制作人或者发起人的审核。

游戏面向的使用者是玩家，不同玩家对游戏的需求点也不同，有一些需求是否可以满足游戏特定玩家的特点呢？游戏用户经过这几年手游环境的洗礼，划分出了不同的玩家群体，典型一点的卡牌玩家、二次元玩家、MMORPG玩家等等，这些群体普遍对应上文中提到的游戏类别。这些游戏玩家各有个的特点，这些总结下来就是玩家用户画像。

从需求角度出发，某些需求可能会直接偏离原有游戏方向上对应的目标用户，这样的结果可能导致游戏的整体风格类别产生偏移，致使出现这两个类别用户都不接受的现象。

比如，海战类游戏中，加入MMORPG的元素，这虽然不失为一种创新，但是在体验上海战玩家可能并不买账。

比如，MOBA游戏中，加入了游戏外装备饰品强化这类对局之外为玩家战力挖的坑，会导致MOBA失去原有的公平性原则。

但是，这类的创新也有成功的一面。私以为这取决于能否抓住游戏类型的核心，即这类玩家玩游戏的核心追求点究竟是什么，在合理融合玩法元素的基础上，不破坏核心追求点，就是成功的创新。

这里既然说到了玩家追求，提一下利益交换原则，玩家玩设计者的游戏或者设计的时候他究竟会得到什么？

这里暂时分成两层，一层，游戏中对自我情绪的影响，比如以自己画符抽卡，妄以此来预测这一段时间的运气，如果能抽中集齐全部SSR，就证明自己欧气爆棚，使得玩家达到自我的满足；另一层，游戏对现实生活的影响，比如最强王者带妹上分，奔现成女朋友，满足自己的社交需求。如果想细化，还可以继续深入划分。

上面提的这些其实是觊觎希望可以验证需求的正确性，做正确的事情远比正确的做事重要，减少不必要的甚至是错误的需求，可以节省团队开发的时间，避免推倒重来、反复修改的噩梦。但是，在实际开发中，这种情况真的很难避免，只能极力去减轻。

项目规划

管理进度的前提是，根据需求列出具体的执行条目，这样才能逐步的推进，这个在PMBOK(项目管理指南)中有专业的术语，即创建工作分解结构，把获得的需求分解成更容易执行的任务事项。

比如一个游戏的大系统，按照团队工种可以分解成：策划——系统设计、程序——程序需求、美术——美术需求。

按照具体执行人还可以细分为：数值设计(数值策划)、规则及配置表(系统策划)、UI交互设计(UI策划)、战斗内设计(战斗策划)、关卡设计(关卡策划)；程序：底层框架设计(主程)、客户端UI逻辑(客户端程序)、服务器协议逻辑(服务器程序)、战斗内逻辑(客户端程序)；美术：特效设计(特效师)、原画设计(原画师)、模型物件设计(角色建模师)、动作制作(动作师)、动画制作(动画师)、场景设计(场景)。

然后根据分解之后的事项，各个组开始分配人员，最好每一项任务分配一个人，如果硬要分配多人完成任务的话，一定要确定对这项任务最终负责的人。

执行任务的执行人要反馈真的确切理解了任务内容，以及完成任务之后要交付的成果。

这样我们就得到了一份这个里程碑或者这个阶段具体可执行的任务条目表，接下来就开始估期了。管理大师彼得德鲁克提到有一类工作者叫做知识工作者，他们脱离了机械化的工作，比如1分钟拧10个螺丝，他们学习新的知识，并且在工作中应用知识。

游戏行业从业者就是知识工作者，学习-消化-应用，是知识工作者的工作模式。每个人的学习接受知识水平不一样，有的人快，有的人慢，有的人天赋高，有的人天赋低。这也是造成了估期不准确的原因之一。

讲价式估期(专家判断)，可以保证一定的估期准确性，先让执行人评估完成时间，然后再让组长(专家)评估完成时间，双方达成共识，这里的关键是组长(专家)对于组员能力的了解程度，越了解估期越准确。

经验式估期(类比估算)，也可以保证一定的估期准确性，以之前做过类似功能的完成时间为参考，对本次功能模块进行估期，参照越相似估期也就越准确。

组长对于团队成员的培训，也可以提高估期的准确性，知识经验的传承，统一的规范，通用的方法论，有助于团队成员提高自身能力的同时，准确把握自身能力范围。

拥有估期之后，就可以按照任务先后进行时间排序，任务之间有的拥有前后置关系，我们可以缕清这些关系形成甘特图。甘特图是可以清晰看出任务之间的关系及与时间的关系，在发生延期情况时，可以清晰看出受影响的关联任务。

至此项目规划阶段算是告一段落了，这里面需要着重记录的信息点是：明确的任务执行项、具体的负责人、准确的时间点。

进度管理

这部分比较程序化，跟进项目进度，强调任务的时间节点，强调什么时间，完成了什么事情。

每日的控制进度审查，一般分为每日站会(Daily Scrum)和每日工作总结。

每日站会(Daily Scrum)，基于小组形式的15分钟小型会议，属于敏捷开发中的一种管理方法，团队成员只说今天做了什么，将要做什么，遇到什么困难。每日站会的原则是高效沟通，减少一切可能浪费资源的行为。

每日工作总结，是一种信息收集的方式，每天的结尾收集团队成员今天任务的完成情况及遇到困难，是一种拉式的沟通方式。

每周的控制进度审查，一般为项目周会，一般安排在每周的开始或者结束阶段，主要为各个组，程序、美术、策划进行同步目前进度状态，主要主旨为同步展示目前项目组的进度状态，同步信息。

估期节点审查，在估期的节点进行询问此任务的目前状态，主动管理、主动询问、遇到问题解决问题、持续推进，保证任务可以持续的推进下去。这个节点可以是任务开始节点、也可以是任务执行中的关键节点、也可以是任务的完成节点，这个度需要在具体情况下具体分析。

这些审查的核心作用是，收集正确信息掌握目前项目状态，确切了解目前团队的状态才能更好的控制进度，管理进度，推进项目，有效决策。

有一些工具软件可以很好的帮助项目组进行项目管理，像Teambition、JIRA、TAPD、Microsoft Project等等，各种软件也拥有各有各的优点。

Teambition较为通用，有多种模版，满足日常的项目管理需求，其基本思想加入了敏捷方法，可以把任务具象化，强调任务的流转过程，主要结构为任务 + 执行人 。操作方便，可视化程度高。

JIRA开源，团队可以根据自己的需求来定制属于自己项目的功能，满足项目管理的基本需求，缺点是使用交互较为死板，操作可视化程度较低。

TAPD是腾讯推出的项目管理工具，应用了腾讯特有的敏捷方法，如果想体验腾讯敏捷方法论，可以尝试一下。

Microsoft Project是微软推出的项目管理软件，功能强大，完全支持项目管理的需求，包括项目预算的计算，人力资源的分配整合，操作比较复杂，设置变量偏多，可视化程度低。

这些软件都提到了敏捷方法，在互联网行业中，敏捷方法是较为推崇的开发方式。敏捷方法的核心是迭代。敏捷的需求承载体为故事，但是故事其实是一个朦胧的概念，需要通过频繁变更迭代来让故事变得清晰与明确。从这一角度来讲其实很适合应用到游戏开发中来。

如果流程偏离了原有的作用——收集正确信息掌握目前项目状态，最终变成了形式化，任何流于表面的形式化流程都是无效的。

总结

在项目管理中，时间、成本、范围和质量等指标历来被视为确定项目是否成功的最重要的因素(S-TQC)。这四个因素互相拉扯紧密联系在一起。

游戏开发过程中，总会突然冒出大大小小的问题，这些问题可能会引起时间的增加、成本的上升、范围的扩大以及质量的下降，项目管理或者项目管理流程或许就是为了避免这些问题、解决这些问题而存在的。

问题解决方法通常包括以下要素：

定义问题；识别根本原因；生成可能的解决方案；选择最佳解决方案；执行解决方案；验证解决方案的有效性。

高效的开发过程不可能一蹴而就，也不存在标准通用的流程规范，这些都是需要一步一步去迭代优化剪裁而成。当然还要团队成员的集体配合磨合才能达到最优的效果。

希望可以借鉴剪裁项目管理体系中的知识框架来提高完善游戏开发过程，如果有写的不严谨或者思路不正确的地方，欢迎提出纠正。

作者：陆拾肆院
来源：游戏陀螺
地址：http://www.youxituoluo.com/521048.html

参与评论