游戏软体管理经验谈 发布区域：PTT GameDesign版（telnet://ptt.cc），部落阁Black Straits Historical （http://ndark.wordpress.com/） 版权所有，禁止转录 作者：NDark，目前任游戏公司软体工程师（专案主程式） 时间：2011 秋 执行期的规格变动 由於游戏专案的特殊性，执行时期必然会发生规格变动的事件，也就是说很少有一开始决 定之後就完全不改的企划案。这算是游戏软体开发最难处理的问题之其二。规格变动的原 因有很多，一开始想错所以做一半要改，做一半发现技术做不出来所以要改，做完了发现 不好玩所以要改，老板不喜欢色调所以要改，做不完了所以要砍规格改，作太快还有很多 时间就乾脆改一下，甚至做太久了也要跟着市场潮流改。连设计模式的圣经都告诉我们 " 规格是不断变动"，要认命。 就算是充满热忱的软体人员，经过几次的改来改去之後都会开始观望，观望等到不会变了 才想开始做。反正改（做）不完，所以就慢慢做，也就是丧失了热情，反正做快一点最後 也会改。这种现象对团队文化是种伤害，更不是一个专案管理者所乐见。但是就我观察并 非每个软体人员一开始都这麽摆老，大部分都是环境改变了他们。 规格变动从结果来看有几种 . 完全不同，这几乎是打掉重练，规划人员要重新分析规划，执行人员如果已经实做一半 或是完成了，就会呐喊 "还我的青春来"。但是打掉重练多半会重新安排时程。 . 由大变小，这种变动比较友善，如果原本的有认真规划阶段，多半可以用跳过的来省略 。苦的是原本规划的人员（花时间规划结果变成白工，超干），但是对执行人员来说算 是松了一口气。 . 由少变多，原本规划两天实装一刀劈下去的动画不够，现在还要有彩带，火花，背景原 本的太阳要变月亮，动画结束又要变回太阳。这种变化最令人讨厌，因为多半是渐渐发 生，东接西凑的情形下原本有规划的系统就会变的很不稳定，执行人员改完之後一定巴 不得永远不要再看到那些程式码。超时工作後也许做的完。但是对软体人员来说执行这 样的工作却是扣分，也就是做完却没有得到成就感。 我们都能体认道规格变动的必要性，但是就我的经验，管理阶层却常常刻意忽视规格变动 会连带影响时程变更这件事（也就是我要看到专案变成我要的样子，却不要看到时程会变 长）。不管是打掉重练，由大变小，由少变多的哪一种。管理阶层都会拿着一开始的时程 表来逼着执行人员。这点就造成了团队闹翻的万年理由： "时程不合理"。我们可以理解 这种现象是由於时程改变（通常是变多）代表着预算要增加，而通常没人愿意去背那个增 加预算的黑锅。因此只好压榨底层的执行人员，或是先做看看祈祷有奇蹟会出现，真的不 行了才翻出底牌。 但是就我的经验，当路途的前方发现一个坑，而团队却忽视这个风险，掉下坑的可能性几 乎是百分之百。临时拉来几匹马想要加速冲过去的下场都会很惨。最惨的不是真的掉下坑 ，而是团队失去了对於呼救的反应能力。对那位真知灼见的先知的忽视可能才是对团队的 严重伤害。也就是真正伤害的是团队内的信任。 当时程不合理的时候，解决方式其实显而易见：增加时间，减少规格，加人。其实优劣也 正如这个顺序。但是不容我说，大部分人都不敢壮士断腕，而宁愿用煮青蛙，挖东墙补西 墙的作法。而通常这些补出来的东西即便能让团队冲过坑，也都会在不久之後碎裂崩坏。 这就跟玩扑克牌大老二很像，有好牌的时候要勇敢打出去来主导牌局，而不是等到快输了 才在想办法把顺子拆成单支。也就是不要被时程逼着逃，而应该反过来勇敢决定一个合理 的时程。 执行期的规格变动大概会有这样的循环： １。不知道什麽原因，发现规格要改。 ２。讨论规格，要怎麽改。 ３。分析规划新的时程，若不能被团队所接受，回到２。 ４。插入或置换原本的时程，确定要改了。 ５。修改规格书（企划）。 ６。执行（美术，程式，企划）。 就我的经验没有完成这整个循环的规格变动一定会导致灾难般的结局。 譬如说只有１与６：一个有力人士跑来，就叫美术把木牌换成石柱。这种例子多半明天石 柱就会换成石敢当。 譬如说缺少５：规格书没有跟着改动，有一天就会有一个天兵再把改过的东西改回旧的规 格书。或是测试後一堆错误才发现测试规格书是依照旧版企划规格制作的。甚至最惨的， 时间一久原先的规格书就变无用的档案，最新的规格都只存在大家的脑海中，团队再也看 不到同一个目标。 譬如说缺少３与４：马上改，原本的时程就被压缩。或是快到里程碑的时候才发现当初改 规格的时候忘记（有意识，无意识，或根本就刻意忽视）把时间加上去，所以当然做不完 ，当然只好加班。时程不合理，bad end。 其实这整个循环完全跑完铁定花不少时间，但这也有好处－让规格要改的决定更加审慎。 顺带一提，我认为这里面最重要的步骤是４，也就是插入新规格的时间点。当然规格变动 大多时候其实派人很快去的改一下是在简单也不过。可能不超过一个小时就能改完。但是 一定数量的 "一个小时"的修正及验证累积起来造成的时间绝对最终会变为不可忽视。如 果原本的时程就已经安排的满满，这时候插入的工作必然造成原本的时程延迟。 我个人衷心地认为比较理想的时间点是里程碑後。因为若是插入的时间在里程碑之前，虽 然改变的规格可以及早看到，但是多半都是会压缩到时程的。若是能将改变的规格压在里 程碑之後（也就是下一个版本），对目前的执行人员来说就可以不用多分心，还是持续冲 刺好好完成现在在做的工作。下一个版本再以新的规格重新出发，对执行人员来说的伤害 会比较小。 我要拿距今两千五百年前软体管理祖师爷的智慧严正地忠告各位晋升管理的朋友们： 团队信任最重要，人员去留次之，产品成果摆最後。 -- "May the Balance be with U"(愿平衡与你同在) 视窗介面游戏设计教学，讨论，分享。欢迎来信。 视窗程式设计（Windows CLR Form）游戏架构设计（Game Application Framework） 游戏工具设计（Game App. Tool Design ） 电脑图学架构及研究（Computer Graphics） --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.44.174.179 ※ 编辑: NDark 来自: 114.44.174.179 (11/02 20:23)