本帖最后由 odysseus1982 于 2014-11-29 10:09 编辑
在项目进程中，一旦遇到挫折，团队内部很容易发生矛盾。各种矛盾的根源，可以归结为三类： 1）、权责不明 我认为你没有做好你应该做的事情。——什么？这件事情不是应该你来做吗？ 2）、对决策不知情 你们策划的决定真的是对的吗？ 3）、未能充分表达意见 你们当时要是听我的就好了。 这几个问题在新团队中尤其容易发生，平时看起来团队一团和气。但这只是表象，在游戏刚刚开放对玩家测试时，各种玩家意见反馈到研发部门。各种矛盾都会爆发出来，不稳固的团队可能这个时候就散了。 一个团结具有战斗力的团队如何建设？绝对不是等到问题爆发之后再解决。团队成员之间的默契和信任，是在工作中一步一步建立起来的。 建设团队的关键在于策划。因为策划是衔接各个部门的纽带，又是需求的提出者，出现问题的时候，往往是矛盾最尖锐之处。 为了避免问题的集中爆发，需要在平时的开发过程中维持良好的协作氛围，因此撰写以下工作心得。 本文不是全方位的开发流程说明，更偏重的是对策划工作的启发和帮助。
一、权责划分 不同的团队的职位安排略有不同，以下仅对常见情况进行说明。 划分责任的重点并非在于事后追责，而是授予责任人相应的资源并激发其主动性，以保障其责任能够准确达成。 若制作人对ARPU值负责，则可以调动相应资源对此进行改进（比如让主策划增加付费点）。 当各种责任出现冲突时，按优先级进行判断，若团队内部对留存率作为第1优先之事无异议，则在和进度冲突之时，可以牺牲进度。 1、制作人 制作人对产品结果负责。 留存率（优先级1.1） ARPU值（优先级1.2） 进度（优先级1.3） 在设立项目经理的场合，进度一般由项目经理负责。 除产品之外，制作人对各部门之配合情况有协调的责任。 2、主策划 主策划对游戏体验负责。 战斗（优先级2.1） 对基础战斗的手感、策略、平衡性负责。主要参考标准：横向游戏比较。 成长（优先级2.2） 对玩家升级节奏、前期引导、数值成长、成长系统玩法（如装备系统）负责。主要参考标准：玩家反馈。 付费（优先级2.3） 主要参考标准：付费率、渗透率、各商品贩卖量。 世界观（优先级2.4） 策划提交给美术的各种人物、场景设计，是否相互之间有足够大的差异？若提交的场景需求表现力雷同，主策划应对此负责。 玩法内容（优先级6.1） 游戏应该有一些具有特色的玩法，如果创新不足。主策划应对此负责。 便捷性（优先级6.2） 主策划不对具体的UI负责，但项目整体操作复杂、系统难以理解，主策划应对此负责。 社交（优先级6.3） 游戏中玩家群体的粘着度，此条在端游中较为重要，手游相对弱一些。 经济（优先级6.4） 商品和货币的流通情况。此条在端游中较为重要，手游的经济流通较少。 资源管理（优先级6.5） 游戏所有美术资源、配置资源之目录结构、文件命名，主策划应做出详细规划。 数值 游戏中的数值工作，其实在以上各点中均有体现（比如战斗平衡、成长曲线、付费额度、玩法难度、经济系统等），因此不单独列出。 除此之外，主策划需对策划制作的进度负责。 3、主程序 主程序对代码质量负责。 服务器效率（优先级3.1） 客户端效率（优先级3.2） bug总数（优先级3.3） 主程序不对具体的bug负责，但在项目整体bug数量过多的情况下，主程序应对此负责。 工具易用性（优先级3.4） 地图编辑器、特效编辑器、脚本工具、各种表格配置项之易用性。 在制作过程中，若有明显的证据证明由于工具不易使用而导致进度缓慢、bug较多、制作精度低，主程序应该为此负责。 除此之外，主程序需对程序制作的进度负责。 4、主测试 主测试对放出版本质量负责。 放出版本的bug数量（优先级4.1） 在版本制作过程中出现的bug数量主测试无需负责。但放出版本之后发现的bug，除非是难以重现的bug，主测试应对此负责。 5、主美术 主美术对美术表现负责。 制作精度（优先级5.1） 美术风格见仁见智难以评判，但制作精度可以横向比较并且加以评判。 风格统一（优先级5.2） 无论采取何种风格，主美术需对风格之统一性负责。 除此之外，主美术需对美术制作的进度负责。 6、策划、程序、测试责任划分 如果一个系统放出之后发现了问题，那么谁来负责？ 方向——主策划 如果系统方向出现了较大问题，比如玩家行为和预期行为完全违背。在此情况下应该由主策划负责。 规则漏洞/偏差——执行策划 如果系统方向没有明显的问题，但玩家利用规则漏洞达到预期之外的效果，或者由于策划计算失误造成偏差。在此情况下应该由执行策划负责。 程序漏洞——执行程序 如果策划规则没有漏洞，但程序在代码中留下了漏洞。在此情况下应该由执行程序负责。 明显Bug——主测试 如果出现明显的bug。在此情况下应该由主测试负责。
二、会议
项目的最终成型，和每一步决策都有关联。在各种决策之中，哪些人对哪些事有发言权？哪些人并且必须了解决策的原因？ 要求团队中每一个人都参与游戏的每一步决策，是不现实的。下面将对各种会议的议题，以及所需要参与的人员进行介绍。 规定参与人的意义在于：确保其对项目决策的知情权，以便于其后续工作，同时也承担了向其下属解释决策原因，维护团队团结的义务。 除了正式列出的参与人员之外，团队其他成员也可以列席会议。但列席会议成员之意见会议主持者可以不予接纳，因为非相关成员的意见往往缺乏专业性。 以下只列出跨部门会议。部门内部会议，比如策划内部的数值讨论、文案讨论不在其中。 1、游戏框架方案会议内容 游戏简介：战斗、成长、世界观、付费 游戏特色：战斗特色、特色成长系统、特色玩法 介绍游戏框架，确定开发方向 本会议并非立项会议，而是针对团队内部的游戏介绍。因此市场分析不作为必需项，若有特殊需求，可以增加市场分析环节。 参与人 制作人、主策划、主程序、主测试、主美术、所有策划 2、核心系统规划方案会议内容 以下系统（任意一个）： 战斗、成长、付费、经济、特色玩法、工具 确定该核心系统的运行机制，但不涉及具体细节。 比如，成长系统中的装备系统，需确认装备的生成、获取、升级、拆解等环节。但一共有多少件装备，装备的属性如何，不在此会议讨论范围内。 参与人 制作人、主策划、主程序、主测试、所有策划、执行程序 3、核心系统执行方案会议内容 以下系统（任意一个）： 战斗、成长、付费、经济、特色玩法、工具 确定该核心系统的具体设计细节、实现方法、配置方法。 比如，成长系统中的装备系统，需确认装备的生成、获取、升级、拆解等环节，各个环节的配置方法。以及装备属性种类、随机波动范围的配置方法等等。 参与人 主策划、主程序、主测试、执行策划、执行程序、主美术（美术相关工具） 4、世界观设计方案会议内容 场景、角色设计方案 确定各个场景/角色之特色、故事背景等信息。 参与人 制作人、主策划、主美术、所有策划 5、非核心系统设计/执行方案会议内容 周边系统：聊天/组队/婚姻…… 这些系统相对简单，重要性也不那么强。 参与人 主策划、执行策划、执行程序、主测试 6、UI设计方案会议内容 各个系统的UI 参与人 主策划、执行策划、执行程序、执行美术、主测试 7、会议参与表
实心五星代表一定要参与的部分。 空心五星代表不强制参与，但有权作为正式成员参与的部分。 三、决策与质疑 和策划开会是最累的一件事情，各种意见纷争不休，各种方案来回讨论反复推倒重来。在这里，我简单向各位分享一下我对于开会决策的一些心得。 1、盲人摸象共识
对于游戏设计，不同的人有不同的观点，策划希望“好玩”，美术希望“好看”，程序希望“简洁”。即使是在策划内部，对于一个系统的设计也会存在不同观点。在会议讨论的时候，经常会陷入这样一个误区： 不是为了解决实际问题，而是陷入对错之争。 在会议中，你随时可以听到这样的对话： “不对不对，玩家不是像你说的那样如何如何，而是如何如何……” 然后，两个人就开始了针锋相对的辩论。 我曾经也想当一个公平的仲裁者，让两个人自由辩论，最后决出胜利的一方，但往往费时费力。后来，我发现了一个更好的方法：两个人根本不用辩论，我们只需要有三条共识，即可迅速解决绝大部分争端： 1、每个人的观点都是对的，因为他代表了一部分玩家。 2、每个人的观点都是不全面的，因为他不能代表所有玩家。 3、各种观点之间有轻重，需要与会人员针对各种观点的重要程度投票。 以上三条我称为“盲人摸象共识”，每个盲人都摸到了大象的一部分，他们都是对的——部分是对的。 讨论游戏设计时，就是几个盲人摸象。与会者应该是合作起来拼凑出大象的整体形状；而不是相互冲突，争论对错。 这要求与会者在发言上应用一个小小的技巧。当你觉得其他人“不对”的时候，最好这样发言： 我的思路和XX的不太一致，因此提出一个新的观点供大家参考。 当与会者就两个观点进行争执时，主持会议者应该敏锐的意识到，两个观点都是有价值的，这个时候应该立即让与会者对优先级进行投票，而不是让他们继续辩论。 当与会者提出自己观点并且获得认可之后，主持会议者应当立即加以记录，作为接下来的“决策标准”。 2、决策标准与投票 一个方案未必能够一次制定完美，因此需要多次讨论。推翻方案是可以的，但是，不能随意推翻。对方案进行决策的依据，是大家在讨论中确定下来的“决策标准”，以及对“决策标准”的轻重排序。 1）、反对——提出新决策标准 当一个与会者反对某一个方案时，不应该继续陷入“对错之争”的陷阱。根据“盲人摸象共识”，反对方案的人其实意味着他想要“提出一个新的决策标准”，或者想要“改变某个决策标准的权重”。 在这种情况下，反对者应该详细介绍其决策标准，然后让与会者表决是否同意。如果同意，那么可以进入下一步。 2）、提出新方案 提出新决策标准并不意味着立即要修改方案。应该首先考虑：新决策标准是否和现有方案冲突。若有冲突，则需要请与会者提出新的方案。 如果无法提出新的方案，甚至发现新决策标准和现有方案不冲突，那么现有方案就不必调整。 3）、利弊分析 当提出新方案之后，应该和旧方案一起进行利弊分析，比如： A方案在决策标准1上有很大优势，在决策标准2上有中等劣势。 B方案在决策标准1上有较少劣势，在决策标准2上有很大优势。 分析完毕之后，需要让与会者综合考虑各种决策标准的轻重进行投票。 4）、投票 投票中的各种方案，我从不直接称之为“同事甲的方案”/“同事乙的方案”；而是总是给与一个中性的代号：A方案/B方案。这种做法是为了避免各种人情世故的问题，在此不赘述。 5）、会议记录 在“会议”一节中可以看到，每个策划会议都是针对某个具体文档的讨论。 因此，会议记录一般记录在文档中，比如“核心系统规划方案”，需要专门开辟一页对会议的讨论进行记录。记录也不用太详细，只需要记录所有“决策标准”以及各种方案的优劣即可。之所以要记录所有方案，是因为有可能采用以前的方案。这时候进行重新决策会节省大量时间。 3、不能全体投票的场合 如果你问我游戏设计最难的地方在哪，我会告诉你，最难的是一个游戏同时要满足不同类型的玩家需求：大R玩家需求、大时间玩家需求、中R玩家需求、小R玩家需求、小时间玩家需求。 在为不同玩家进行专门设计的时候，不能采用全体投票的方式进行决策。举例而言，现在你们正在为大R设计一个功能点，而整个策划团队中只有一个深入了解大R心态的策划。那么这个时候，应该以他的意见为主。只要他能够说服主策划/制作人，即使其他人全部反对，也应该采取他的决策。
从这个角度来说，一个策划团队里面，最好尽量覆盖各种游戏经历的玩家类型。 4、决策授权 在成熟的团队中，当上级因故不能参加会议时，会议仍然可以继续进行。但是，上级需要对会议进行授权，简单的说就是两个列表：必需内容和禁止内容。 如果会议决策没有违反上级的禁止内容，也没有遗漏上级的必需内容。那么该会议的决策应该得到通过，同时由上级承担决策责任。 如果上级因故不授权，建议休会。 5、质疑 现在策划已经听取了各方面的意见，也尽量让相关同事都了解了每次决策的原因。但是，项目还是可耻的遇到了挫折。这个时候，团队内部开始有了对策划质疑的声音，此时应该如何处理？ 简单的说，堵不如疏。但跟水库泄洪是一个道理，疏要控制规模。 解决方法如下： 1）、允许项目的任何成员对策划决策提出质疑，但仅限于向自己的直接领导提出质疑。 2）、若直接领导难以解释的质疑，向制作人汇报。制作人可以要求主策划立即或者择日安排会议答疑。 3）、任何成员都不应当在会议外的公开场合直接对策划决策表示质疑（私下沟通交流不在此例），无序的公开质疑会让团队氛围迅速恶化。 在这个时候，控制泄洪最关键的是制作人。 如果制作人一味的禁止团队成员质疑，团队的稳定性会越来越差。如果能抗过这个阶段，让策划改好游戏还好说；如果策划一时改不好游戏，最后问题还是会暴露出来的。 如果一次性释放团队所有的质疑，主策划可能会OT，导致团队崩盘。
因此，如何合理释放团队质疑，是一件考验领导艺术的事情。 四、开发平台和文档 写到这里最关键的部分已经完了，下面只是对一些工作规则的补充，良好的工作规则，也能够减少团队内部的摩擦。 1、文档更新与跟踪
所有的团队都会用一些项目管理软件。我曾经用过bugzilla和redmine。redmine的功能更强大一些，可以对事务加以评论、搜索等等。我并不想介绍redmine的功能，而想介绍一个我对redmine的使用细节。 1）、所有的策划需求都要提单。 2）、所有的策划需求，除了在单中说明需求简介之外，都要附文档路径。 3）、没有文档路径的单，程序可以拒绝制作，测试可以拒绝测试。 4）、某个单的文档维护责任在最后经手该单的策划身上。 5）、任何需求单，一旦测试并且放出，责任在最后的测试者身上。 这个规定是为了督促程序和测试了解文档、了解设计思路。也是为了保证策划文档和实际实现的一致性。 2、程序反复修改 大的方案策划可能改，小的数值，策划也经常不厌其烦的改。你经常可以听到程序的抱怨：“你们怎么又要改？” 要缓解这个问题，还有一个技巧：策划在写文档的时候，一定要清楚的注明，哪些部分是可能需要调整的。 在我所在的团队中，很多配置项都是由脚本控制，比如装备的生成规则，因此策划可以很方便的修改这个部分。 对于需要大量配置的数据，则一般采用表格来配置。 在这里需要向程序约定：策划和程序共同确认，可能会调整的部分，程序尽量写得灵活；不得拒绝修改。 结语
好了，以上就是我对策划在工作中，如何避免摩擦，增进团队团结的一些心得。不对的地方请各位指正。对于游戏研发，我也只能说是摸象的一个瞎子而已，只能力求自己多摸一摸，多想一想，以期了解大象的全貌。与各位共勉！
| 
[复制链接]
发表于 2014-11-28 18:44:49
