Unity过于便利导致项目失控 山本一郎披露解决方法

zhuzhenghao

2013年4月15日，由unity主办的“unite japan 2013” 在东京召开。第一日在游戏开发现场，召开了以“着火”为主题的议程。

    不仅仅是游戏界，其他行业也一样，开发中长期的项目，超预算或延期这些因素通常都是难以避免的。代表 I&P（irregular＆partner）公司的山本一郎登台演讲。 I&P公司是接受那些开发进程陷入延期状态公司的委托，为防止事态进一步恶化而进行项目调整，处理，以此为业务的公司。山本先生把这种无论怎么努力都无法按时完成的项目，比喻成“着火”。（顺带一提，如果降低项目品质，加班加点还能努力完成的这种状态，被称作“向死亡进军”）

项目着火时，项目经理人的分析的理由是“复杂性上升”。“越做项目的进展就越慢”，这样就出现了这种不可思议的情况。到底该怎么办，项目最终又会发展到什么地步？没有人能把握的了。到了这种情况，通常的解决办法就是“停止项目”“追加预算，推倒重来”“清算负责人”“降低品质，把最低限度的东西先做出来吧”。顺便说下，为了在期限内完成项目而追加人员的处置方法，效果并不很好。用这种解决办法而导致的项目更复杂的例子非常的多。项目负责人一定要通观项目整体，“项目哪里不足”，“为了制作出什么而努力工作”，这些要明确的指出来。

    为了防止项目着火，事前要熟知可能引起着火的关键点。要了解项目哪里压力最大，最容易出问题。明白了这些，就有了处理和改善的方法。可是无论是谁，怎么努力的管理项目，都可能出现突发的误算或延迟的情况。

　

  那么，介绍一些稍微极端的例子来进行说明。（似乎都基于事实）

?项目管理者与公司女性恋爱了，多了很多无用的联络
?程序员突然不来公司了。
?项目经理人有了心理疾病，带着他妈妈一起来上班了。
?被逼到绝境的设计者剽窃其他公司的作品。
?制作指示书的文字被弄脏了，看不了了。
?客户放出豪言“不要debug的时间”。结果工作负担大大增加
?开发期间制作公司被收购。
    如果想要应对这种突发状况，那么项目的初期阶段就非常非常重要。也就是要在一开始的时候就要保证让游戏能够运行（将β版提前）。这和之前的家用机游戏开发手法是相反的，但像unity这种新的开发工具出来之后，就显得越发重要。而实际上，将β版提前的开发项目，目前还没有进展不顺利的例子。

    这里对项目主要负责人说明一下unity的优势。标准项目里，项目管理者的工作时间，有百分之六十是在负责团队内部的沟通。那么，unity能起到提升剩余百分之四十工作效率的效果。具体的说，举以下两点例子。
    编码规范很少的情况下，也没问题---既能保持团队内的统一性，也能降低工作量。使用unity，只有其标准情况的4成以下。
    试制游戏时很容易检验游戏性。---游戏的原理和问题能够很早就确认。
    可是，由于unity的这种便利性，而导致出现问题的例子也有。

    使用unity，并不会使项目的所有方面的作业速度都有提高。项目的进行，有些部分的时间是不能省的。如果不认识到这一点，很可能导致项目着火。最后即使完成了这款游戏，也是失败之作。为了避免这种情况，山本介绍了四个要点。
?依赖unity的部分和需要自己消化运用的部分分开
?要求条件和优先顺序要在最初时把握好
?着火的部分要及早发现，立即报告
?减少互传口信，指挥系统一体化
    只是，尽管这样做了，还是引起了项目着火，这时该采取什么对策呢。项目着火，在此基础上推倒从来的可能性几乎没有时，千万不要做出“先这么着，做出来个样子看看”这个选择。由于上司判断过迟，导致无可挽回的例子，山本先生遇见的非常多。
山本强调，对于着火的项目，基本的处理办法就是“放弃项目”和“确保追加资源”这两种。对于是否要“放弃项目”这种判断，是伴随着很大的责任问题的，实际上是很难的。而关于后者的对策问题，进行了一些介绍。
1.追加资源(时间，预算，人员等)确保
2.确认其他部分的制作进展情况
3.确认项目着火点进行处置--这里由于特定人引起问题的例子也很多，这时就需要将其调离本项目，给予别的安排
4.能减则减，给项目瘦身
5.摘出最重要的工作部分，投入资源
    总结来说就是“降低项目的复杂性”。把握住项目全体，除去项目内不可知的部分，就可能达到灭火的目的。

    最后是关于unity的部分。山本说道“全部都依赖于unity是非常愚蠢的”。Unity并不是万能的工具，项目越大时，管理与沟通的重要性就越大。只会使用unity，对于unity以外的领域都不了解的话，就已经埋下了问题的火种。他指出“随着unity的使用，磨练自己的管理技能是非常必要的”

来源 17173

啍辤★箛独

日本人 是人才啊 都是工作狂