部门间合作

工作三年来，我发现在部门间配合的问题上，一直没有完美配合的案例。在金山接受新员工培训时,我还记得PL的培训MM的告诫:完美的配合是不存在的;等待完美的配合，不如现在就开始做.
在KingSoft时，KIM事业部和游戏事业部有个合作计划，即使用KIM的IM技术，替换游戏里的内部聊天系统，但这个计划从一开始就流产；原因是游戏是个公司挣钱的产品，接入一个新的IM系统，可能会带来未知的问题。
在RoxBeam时，开发部和质量控制部(QA)从一开始就在争吵，有些很小的事情，可能互相一两句话沟通就能解决的问题，最后却能成为两个部门间群发邮件的争论。
在现在的公司，两大核心开发组之间的隔阂，让我十分焦虑。P2P产品虽然现在没有成为公司的一个拳头产品，但抬起头看以后，如果有直播点播的技术，加上公司强劲的市场运作能力，将来可以成为业内翘楚。Joost的高调发布和风险投资的追捧，让我们已经看到了互联网视频广告和数字发行的风雨欲来。
纵观这三次经历，有以下几个共同特点：
1. 风险控制问题。KS的游戏部门肯定不愿意接入一个还没有经过大规模运营的IM系统，来替换目前的内部聊天系统。即使接入一个新的聊天系统，也不能给游戏带来真正的增值。
2. 责任归属问题。RB公司的Dev和QA的争论，更像是学术的争论，一个具体的研发流程，应该谁来负责，谁又权力决策的问题。 另外也有开发究竟是Dev强势还是应该QA强势的问题。

解决部门合作问题，我想可以如下几个步骤：
1. 共同认同公司的目标
KS游戏部门应当意识到，更换一个聊天系统虽然对游戏作用不大，但是却扶持了公司的一个巨大有潜力的产品：即时通讯。
对公司目标的认同，可以解决不愿意接入可能有风险的项目的问题。共同控制、承担公司未来发展需要的技术和产品暂时的风险。

2. 互相理解
RB公司的Dev和QA的争论，我想还是属于一个技术争论的范畴，一个具体的流程应当谁负责，一个具体的Bug究竟需要不需要Fix。如果这时Dev站到QA角度，QA反站到Dev角度，这个问题的答案就已经非常清晰了。
互相的理解，可以分解责任的归属，能做到自责，这样可以互相帮助着解决对方的问题。也可以彼此互相感谢。

不得不承认，这个想法非常的理想化，写这篇blog时，我也对自己的想法做了很多保留。但是对我来说，部门间配合的问题，我必须在我的工作里解决。