还是谈软件管理－从零开始3.0
部落格连结(有需要各连结请看部落格)：
https://tinyurl.com/22xapu7h
回到台湾先后从两间 Hyper-Casual 的公司服务后，2022 年初与触宝的同事一起加入
Bloxmith 作自研案<Raiders Rumble(时空突袭)>(link)。这个自研案的特色已经在此篇
"These facts let’s shout out loud. 大乡共出来！"(link)说明。
加入此案最初设定的目标是 A)协助该公司将团队建立起来，B)协助产品上线。此案在
2023 第一季送上商城进行公开测试（玩家可直接从商城下载游戏）。
这个案子（团队）的属性是Ａ）自研，Ｂ）无IP，Ｃ）非续作，Ｄ）整个团队在开案之初
大多数不互相认识，Ｅ）玩法声称要特殊。为避免赘述以下简称相同属性的案子为：非续
作自研案。
多年以来，如同"从零开始2.0〃 (link)所论述，我关注的领域是软件工程，软件管理，
或称制程。
我个人遇到一个困难。大多数从业人员即便每天照三餐抱怨，但其实对这领域感触不深/
兴趣不大。大多数的从业人员比较专注在其专业及设计上（在个人能够改变的范围）。即
便是同为管理人员，不同的专案内容（代理，本地化，续作开发），其实也都会对此领域
产生不同的结论。（我们可回忆某年的研讨会上曾出 IP王道 vs 玩法王道 同场比拼，处
理的问题不同，导致开发者得到不一样的 Best Practice）
对我的演讲内容比较有感触的比较接近现役管理者，或是公司管理层。也就是能体悟：游
戏专案管理相对于游戏开发的各环节是唯一不容易也“很难用资源能砸出成果”的领域。
这也是为何我把此领域认为是每个团队/成员/管理者都应该要好好思考，因为终究会遇到
困难。
当然先贤曰：一人靠毅力，两人靠忍让，三人以上才需要管理。这点我认同。
在"These facts let’s shout out loud. 大乡共出来！"(link)说到，本案开案之初就
到部的程式人员中共五位（其中一位服务器端，四位客户端），全部都是没有作过"游戏
商业作"的开发者。其中有几位甚至是毕业后第一份工作。说明到此，读者可停下一口气
深思估量自己曾经做过的案子中是否有类似的经验。遇到这样的情况时该作何反应。（块
陶啊？）
补充：本案在开发后期服务器人员最高扩增到 4.5 位（其中包含一位的短期约聘，一位
两端双栖）客户端则是最高 5.5 位。
不过在我从业生涯中，这已经是第二次面对这样的情况。生涯中我也看过不少同公司同业
的专案在类似情境面对各种困难。所以我并没有生出”惊讶“这种情绪。
破题说明我的感想：唯一的问题就是时程评估
从我的观察，非续作自研案很有机会一作作三年。而这些案子都不是一开始就知道或计画
要作三年。大多数最初的规划都可能过分乐观估算三个季度应可完成（其中也许有些是为
了讨好金主而只好评估出这样的预想，但本人认为这样的预想也许更会恶化投资人与开发
团队的关系，此为题外话）。不过只要持续推进确实大概半年左右会完成到主要战斗画面
（做玩法验证），整体专案会在第一年期作到可上架的里程碑。
这时（一年期）的产品可推估是：可执行，是一个完整（什么都有）的产品，但应不到
Product Owner 心中的标准。接着就会开始以下的循环：设计变更，时程延展，人员流失
，重新补进新人（甚至是更换制作人），新人会带来更多的设计变更，时程再度延展，新
旧人员在设计上出现歧异再度流失，回到重新补进新人的循环。这样的循环会到第三年期
， Product Owner 终于无法信任开发团队，最后会找来一个救援投手，负责收拾残局，
产品能上线止损就好。
专案时程如何接近原先规划
第一重要
要将专案浓缩到如原先规划，其实最重要是 Product Owner 的意志是否坚定。不会在中
途增加看到画面之后产生原先规划之外的规格变更。当然以一个"玩法声称要特殊"的案子
来说，这点并不容易。即便是独立游戏有着极小化的人员配置及管理成本，都很常看到结
果发现先前设计有问题，规格需要变更一作作三五年的情况。而这三五年绝对不是用砸钱
换人力可以缩短的时程。多出来的人力会带来多余的管理问题。反而会将专案开发时间延
长。请谨记软件开发不是制造业，而是服务业，很难透过买断技术或素材来缩短开发（很
难换一个/多一个发型设计师，理发的时间会变短，多半是剪得更好看。买断人力资源做
人月神话不能说是不可行的方法，但必须完全专用）。
如前述，方向修正这个问题在商业作品及独立游戏专案或小专案都会发生，不能专说这是
商业游戏的问题。不过有个绝对的差异是来自心理层面。独立游戏的决策几乎是团队内自
己决定，而商业作品的这种变革是必来自于 Product Owner，所以领薪水的工作者会有被
改变的不安全感，这种感受在以作品为 credit 的游戏产业又特别强烈（在以公司名气
为 credit 的科技产业就比较感觉不会这么强烈）。在科技产业烂主管烂老板都是上层的
问题。只要公司有名，底层员工心态上比较能够跟案子切割清楚。游戏产业容许部分的自
主性（组织鼓励大家贡献点子）反而带来了灵魂无法与专案切割的被改变不安全感。
当然华人界也有其独特不理性的情形，也就是过分期待希望自己遇到的是明主及高明的团
队。但其实任何高手也都是普通人。也都要面对普通人会面对的资讯不足，资讯饱和，人
际关系，七情六欲，以及人生家庭问题。
此处插入职涯锚定关于人和的议题
我在"从零开始2.0〃 (link) 中提到职涯锚定。也就是工作者对职涯的追求其实不同。找
寻同伴或同事时如果不是有长时间的相处磨合进入平衡。多半最后都会走向因为职涯锚定
的不同（价值观不同）导致鄙视链。因为人生的意义不同，所以人与人相处之间会产生摩
擦。我在 2017 年专心在软件人员招募的议题(link) 在招募时我也尽量能关注合作性而
非技术力。合作造成的效率低落是巨大到时程呈现两倍到三倍的成长。网红创业家 Gary
V 曾有一个演讲标题是这样的：“有时候你必须让团队中的高手离开”。我能与他理解了
类似的东西。如何在技术与合作性间找到平衡点至今对我仍是一个考验，特别是资源及选
择有限的情况下。
第二重要
回到上述要将专案时程如原先规划，第二重要的就是团队成员互相理解功能组的每个人中
：自己应该负责的部分，以及应该要交给别人负责的部分。这个理解必须是他观与自观同
时符合。他观与自观冲突时产生的不一致终究会造成人际关系的崩坏。最终究会成为"又
是一个烂人，一个烂主管，一个烂专案，一个烂老板，一个烂公司"这样的简单结论。
简单来讲，也是合作性大于技术力的平衡。对于每次的招募来说，都是个人对公司，其实
比较缺乏个人对团队其间成员的思量。
结论：不管是求职者或是用人单位，不管是对于设计或是人事，说"不"比较难，但是多半
说"不"或是"拒绝规格进入"对长远比较有帮助。
第三重要
要能将时程缩短，在同一个案子开发中，技术（或是制程）方案我认为必须独裁。也就是
不要让团队陷入选择技术方案之争。而要达到这样的结果，最简单的方法就是主管的独裁
：不要让团队（在技术选用上）思考（当然前提是复数方案都可行，不可能选用一个方案
无法达到妥协后的目标）。专案与专案间需要比较的时候，最好在不同专案都有成果时，
才能够有超出技术人客观的比较）
id software的讨论串(link)中提到团队中一定会有喜欢产品的人以及喜欢技术的人。而
当团队中缺乏喜欢产品的成员的时候"your product never ship（专案就不会结束，因为
技术重构优化的工作的优先度永远都高过于把专案做完）"。因此控制招募进团队的成员
使得产品人的数量高过于技术人的数量可以在此发挥一点作用。
谈软件架构（框架）
从先前服务的几个案子中我其实学到蛮多有趣的体悟，要谈软件架构就必须先谈这些案子
的独特之处。
先说结论：软件架构的好处是将多个专案相同的地方拆出减少重复制作轮子重复解相同问
题的现象。
但这个前提（多个专案）在非续作自研案上其实不存在。在这种案子上谈架构接连地会导
致一些技术选择上的矛盾。也就是说技术派的开发者，会自动地选用可以扩充的技术或架
构，当然，一定对"未来"比较好。
而可以扩充（专案会完成，导致会有二代）这前提，若把它当作规格。此规格不一定存在
。
2018~2020 我在 Ubisoft 维护 Growtopia，先前有翻译过一篇 Growtopia 作者的自述开
发心路历程(link)，其中作者提到，之所以 Growtopia 可以在三个月完成第一个原型并
上线验证，其中很重要的原因就是，他透过先前的几个案子，已经不需要再额外开发什么
模组（也可以说这个案子他决定不再额外研究系统）。当然两人开发减少了沟通问题，独
立开发也减少了投资人发行商的意见问题也对此有贡献。而当本人在这个专案的服务过程
（当然是这个案子已经被卖给 Ubisoft 后），从制作人到主程式都很正式的跟技术团队
说明，这个案子虽然从内部看很阳春，但强烈建议团队"不要"进行重构，甚至讲明白了不
要使用 JSON 格式。所谓的阳春是什么意思？这个专案的写作方式就是把全部功能及设定
写死在程式码内。直到我离开这个专案时仍是如此。
举个例子，这个案子的设定表是像这样一个类别 ItemSettingTable 的初始化时会去跑一
个建构子（简单理解就是 Setup() / Initalize() 这样的函式），而每个道具的参数，
就是写死在这几千行的程式码内，修改时，就是改程式码重新 build 版本，重新部署。
而非透过一个 database 来管理。我相信，如果有从业人员在商业公司中这样写作，肯定
会被臭骂不够有弹性，没有经过专业训练的写作方式。
成败论英雄，Growtopia 年营收是用百万欧元做单位来计算。这个产品现在还在营运中。
Hyper-casual 类型的团队开发及部署节奏
我在 2020~2021 年连续服务于两间 hyper-casual 的开发公司。基本上开发及部署的周
期都是少于一周，也就是在一周之初企划会开出本周要做的事情，这些工作项目也必然大
多是一周内可以完成的调整，团队在一周内完成这些项目，然后在周期结束时发布到商城
。企划会接着回收数据，作为下周的方向调整依据。在这样的节奏下，很重要的是团队每
日建置测试的惯性。更重要的是企划的能力：能否在每个周期开始前就把美术项目发包完
成“回收”，让开发团队可以在新的周期开始时取得能实作的素材，在每个周期开始前，
就知道要埋什么样的数据点（同时规划 A/B Test 的方法），在每个周期完成后，能够回
收数据及 A/B Test 结论，将结论纳入下一个周期的设计。再次开始新的周期（此时已经
完成回收第二周期的美术发包）
在这样的案子训练出来的企划有一个特质，就是能够适应每次的设计都是从现况逐步改变
，而非规划长期工作。当然我不认为这么短的时间贡献的知识能有多高竿，但确实这种企
划能够提高团队的输出效率。
在我这次参与的案子中，我使用了这些概念，包含不过分使用框架（直接使用Unity再搭
配团队自己提出开发时需要的插件），在问题出现前不过分标准化写作方式（我们没有规
范coding style，唯一定义的是网络协定的命名方式），每日建置并追踪问题（我把这部
分叫做快速迭代：每个人在功能线上开发每天进行整合，每天建置，每天有新版，每天追
踪是不是有什么东西坏掉，即时或尽快修复那些整合失败的部分）
id software的讨论串(link)中也提到架构/系统这件事，就我的理解，每产生一个架构与
系统都会产生设定资讯（meta），而这些资讯是专案中独有的，不管文件怎么详细，最后
这些资讯都存在于开发者的脑袋里。架构就是想办法把开发者的脑子内的这些资讯，抽出
为非开发者也能理解。
譬如说，某些框架会去规范每个美术资料夹的贴图的分辨率大小，当档案变动时自动跑一
个脚本把贴图分辨率自动优化。当这样的设定资讯被抽出为架构，也就是美术人员或管理
层也都必须知道美术档案要放在这里，分辨率会被自动调整。（才不会游戏出来之后发现
图为什么糊掉了或分辨率跑掉了，再跑去怪美术人员或是开发人员）
如前述，这个案子中有成员在程式设计领域有困难，所以为了不要在前期花费太多时间“
教学”。更支持了我不特地选用框架或建立规范（减少知识的传递导致的时间浪费）。
当然缺点很明显，程式码每个人习惯不同，花式命名对每个开发者来说维护起来确实造成
一些困扰。但是经过适当的切割，每个人都能安全地在所属的功能中开发，我们每天有十
几次的 feature merge。其实鲜少有 merge conflict。发生了冲突也都会在一天内解决
。我想，光每个开发者，能够放胆把当天的开发功能在一天之内合进主线，就不是每个团
队每个开发者都做得到。包含我在内没有人能够写出完美不用验证的程式码，这样的开发
模式能够运作的最后一片拼图是每天与我们配合的测试人员。
开发方法与制程 快速迭代的软件开发方式
在我早期的针对品质管理演讲(link)中提到，每个修改（包含美术资源的更新）都有可能
引发副作用。修正副作用也可能触发额外的副作用。副作用的产生就只能透过测试修正逐
步解决。测试的方式我想在此不多做说明。不管哪一种，投注的时间越多，效果都看得见
这个案子我要求成员放胆完成功能就通知我整合进主线。因此如此篇文章所说，每天大概
会有十多次的整合(merge)。一定会发生有什么人改了什么导致主线无法成功运行。（
ex. compiler error/null reference）。如果成员持续地在主线上开发，那么一定会有
人发现通知团队并尽快修正。（若无法及时修正，可以直接revert回前一版）每天建置版
本的好处，revert最早也不会超过一天的量（幸运地我们从未 revert 这么多的量）。测
试员作为每日建置版本的第一道防线，如果建置的版本不能跑，或跑起来有严重错误，就
立即派人检查并修复再出一个新版。其他非致命的功能错误，就由测试员持续地回报。这
样的做法的好处就是把整合期会发生错误的修复时间，有别与传统开发方式（有指定测试
时间），从测试期拿到开发时间来。修复这些整合性问题也当作是完成功能的重要指标（
发生在功能线上正常但整合后失败的情况也代表功能的未完成。）
这样的成果在issue系统上可以显示出来，我们的臭虫数目维持一个动态稳定的数字。每
天都有增加新的臭虫，但每天都有一定数量的解决。直到里程碑进入测试期我们大多要处
理的问题就是品质与期待落差造成的修改。
资讯传递/开会仍是一个困难的议题
本案在资讯传递上也遇到了跟任何一个专案的相同问题。开会的次数及长度应如何拿捏？
开会多了，就是大家的工时就浪费在会议中。开会少了，点对点的沟通会让团体运作像瞎
子摸象，每个人都摸到象的一个部分。资讯传递在少数人中，其他人就不知道这些重要资
讯。这个问题到了专案后期我也还没有找到解决方法。只能在里程碑的断点，强迫团队成
员分享，整理文件。
早期软件管理的困难
如前述，这个案子中有成员在程式设计领域有困难。在第一个季度，我的难处是在于如何
正确评估每个成员的能力，指派适当难度的任务。不管多与少，尽量让每个人产生产值。
在自动演出的部分，很幸运地我参考了我在 <Taiwan War> 及 <Growtopia> 的经验。前
者当时的案子刚好就是自动战斗，我将每个服务器运算的战斗行为转为一个行为阵列，客
户端则依照这个阵列来演出。后者的经验告诉我演出系统是静态系统，也就是设计希望这
样演，设计结束之时可视为变动就固定，所以在客户端我依照当下的需求设计了一个时序
演出+角色分割写作的方式，将所有的角色的演出除了服务器战斗参数外全部都写死在客
户端。（这也是 <Growtopia> 每个月产出新装备新特效的做法）程式人员透过简单的函
式来呼叫美术人员的素材，透过单一写死的时序流程（"Coroutine"）逐步实作需求。幸
运地设计端也能够体谅这样的开发方式，没有过分提出跳跃式的需求。最大的弱点就是自
动演出无法中间插入变化（幸好我们没有战斗中人为触发技能施放这个功能）
意外学到的经验
瞎子摸象造成的设计问题
前述有提到瞎子摸象（团队常见透过点对点沟通但讯息不同步）的情形，本案中也会发生
。也用此来告诫设计人员，遇到问题不要只看自己的专业，而必须各方问题整合起来思考
找到共识。在本案的战斗前流程，有一个布阵阶段（双方角色摆放位置进行战略优势调整
），专案推进时因为有问题而不断做调整改版。最初是因为战斗时角色演出要有空间，所
以拉大了敌我双方的阵型距离（楚河汉界的位置有跑动演出的空间）。同时因为要方便玩
家观察布阵结果所以改用了俯视视角。两个设计需求综合后在视觉上立即出现问题，因为
俯视，所以布阵时放下3D角色就变成头顶方向，失去了角色的鉴别度，可惜了3D角色的创
作优势。因为双方阵营距离拉大，所以俯视战场的摄影机距离就要拉远，才能同时看到两
边的布阵，又更加剧前述俯视的问题（角色因距离拉远而变小）。因此这个流程陷入了多
方设计人员互相折冲的难题。后期接口进行大改版，采用了大版面的2D角色接口，也更加
剧了这个现象（因为接口占据了更多视觉空间，要在有限的空间放入双方阵营，只好再把
摄影机距离拉远）
没有想到要错误处理导致未初始化的接口引发玩家不满
在一次的封闭测试中，玩家的网络品质导致某流程初始化的流程网络要求 time out ，没
有收到重要资料。而后续的接口仰赖这些重要资料也没有检查做例外处理。导致初始化发
生 null reference。接口则赤裸裸地以原始状态显示给玩家。好死不死，设计人员不只
没有提供例外处理的计画，也没有提供初始接口的设定。所以开发者凭借自己的感觉来设
定一个99999的最大位数视觉检查方式。更糟糕的是，这个错误的情况被社群贴到网络上
。最糟糕的是，这次的封闭测试有办玩家间的比赛。这些错误的接口被玩家认为是官方在
偏袒某些玩家作弊（给某些帐号偷塞钱）。当然，在开发环境中很难意识到这些重要的网
路沟通流程会失败，而需要多防范。但完全推给玩家网络不佳，也是过度卸责的表现。只
能团队吞下来事后检讨修改。
最后检讨
在客户端，本案我觉得我将我以往的开发经验极大化但未全部地发挥出来，在工程上，成
绩算是超过我预期。在服务器端，有鉴于服务器人员都不是从游戏产业来的开发者，所以
在与企划沟通上我算是少做了太多控场的工作。导致服务器有很多不必要的重构时间成本
。如果再给我一次机会，我会用另一种方式来运行服务器人员怎么开发，简单来讲我必须
花更多时间自己写一套服务器（逻辑及协定部分）。在其他部门合作部分，程式组采取了
快速迭代的工作方法，可是并没有将这套工作流程传播到其他部门（毕竟我只管技术），
导致其他部门对于制程部分都处于管线末端必须有意地适应及被迫调整学习。这点希望部
门管理者能引以为鉴。合作性大于技术力在部门间也必须有意识地思考。
线上营运事件与后续优化混在一起让制程更加的复杂
本段落是在发售后补充。幸运地，我们顺利发售了，感谢参与的各位。我当时心态上已准
备好面对线上的问题（服务器端与客户端都有）。但令我感到寸步难行的是，当除错与行
销需求，素材更新一起发生时，同时品管人力没有补充的情况下，前进的速度像陷入沼泽
一般缓慢，尤其相较于我们开发时期使用快速迭代的节奏，反差极大。（啊～对！很戏剧
性地，在我写最后一段的同时，开发团队的大多数人员也结束了服务。）