※ 引述《StupidGaGa (笨嘎嘎)》之铭言：
最近在跟日本人做案子
看到这篇，真是心有戚戚焉啊...
台湾的程式跟企划虽然常常拌嘴吵架
但是真的杀到不留情面的很少
吵完后，多半都会各退一步帮对方想想
日本人就不是了
除了比较会在背后来阴的跟推责任之外
一切照规矩辨事
依你下面的例子
我来说说我遇到的日本人会怎么处理
: 01. 好的企划又怎样，程式一句不行、不能、不想、以前就是这样了直接打枪。
他们会直接EMail告知案子的实际负责人(不是制作人，因为制作人的位阶很高)
程式、美术的大头以及PM，顺便cc给那个程式。
如果负责人(通常是总监)觉得这功能有必要性，而且辨得到
你就会看到程式被人钉上天...
: 个人常遇到的就是，需求有了，写出来了，一切如同机械表一样的完美运作，
: 然后就会有新的需求进来，当然，上头会希望你在“原本的架构上面新增功能”，
: 这时就陷入了地狱的无限循环，
: 新需求>改程式>新需求>改程式>…，程式不稳定，BUG一堆。
: 实务上“需求一直在变化”，
需求是需要被管理的
日本人管理需求的方式就是“仕样书”，也就是企划书
他们写的企划书非常完整，不但完成度极高还非常容易阅读
就像是在看一本游戏攻略书，里面附上各种设定及计算式
最重要的是，每项功能及需求都有写上他的目的以及要达成的成效
当游戏上市后，该功能是否如预期达成它的功效(玩家的评价)
都是这位企划考绩的评比
一份企划书在交给程式、美术之前
除了要通过其它企划人员全部赞同之外
还需要总监的认可
听说文字写的太多或内容过多、图片说明太少
不够清楚有条理、无法让人感到有趣、规划的功能不符合目的…等等
都会被退回重写
一但仕样书交给程式、美术、音乐后
除非制作人要求修改，否则是不能变更的
企划想要变更，必须向总监提出报告跟说明
再由总监向制作人及PM说明要变更的部份
经过同意之后，才能向程式、美术要求更改
PM会向财务、老板说明仕样变更后影响的时程及预算
万一影响太大，制作人跟总监就科科了
也因为企划书如此的重要
一年的案子，大概会有半年的时间让企划去生企划书
前半年只有少数的程式及美术陪企划去做一些Demo或是prototype
后半年才开始投入大量的人力去制作
一些已知的美术部份，在前期也会先外包出去
: 身为一个程式，我知道需求会变，
: 我不会说“计画赶不上变化”，而是要“变化也是在计画之内”，
在台湾，程式要保留弹性去符合变化
在日本，企划必须要把变化在纳入企划书之中
: 02. 制作人一句要、不要、不然你想怎样完全没有要沟通的意思。
是
在日本，制作人就是神!!(无误)
一切他说了算，因为他要为游戏负上全责
万一游戏卖的很糟
好一点是被冷冻，惨的是直接开除
落魄的制作人有多惨，就不多说了
: 常常上头有了突发奇想说要加某些功能，
: 评估后可行，但是所需时间太长，然后上头就说不要…
: 或者改完后，客户觉得难用，又改回之前的…
因为在台湾，你很少看到上层因为这样而受到什么处罚
最多被老板叫进房间狗干一顿就没事了
在日本，出大包一次就被降职并不希奇
而且很难爬回去，就像半泽直树里面的近藤
所以他们推责任的功力真的超强，愈高层愈强...
也因此，他们工作压力很大，对于工作也很认真
相较之下，台湾真的是自由轻松多了，但是工时超长= =