跳票工厂

经历过若干个手游项目，有单机，有网游，所在的公司规模都不大，团队规模也从几人到十几人不等。期间遇到了不少团队协作方面的问题，相信也能代表国内大部分团队的情况，特此做简单点评。

1.开发计划制定不合理。领导、策划过多干预计划，完全不顾开发时间是否充裕，导致代码质量底下，缺陷率较高，整体开发周期反而上升。

我的观点：

1）作为核心人员，产品经理有必要对美术、程序和策划等每一项技术进行一定程度的了解。主程、主美、主策分别制定工作计划，由经理进行审核、整合。

2）逐级管理，不得互相干预。

2.程序先行的恶习。总以“先用别的图代替”为由，功能在资源缺失甚至文档不足的情况下就草率开发，后期却不断地修改，造成资源混乱，项目反复修改，反复测试。

我的观点：任何项目都很难做到大家同时开工，大家都有事在做，即便员工的薪水是你的血汗积蓄，你也要接受总有人不是100%开动，况且工作本来就应该是松弛有度，劳逸结合的。我们能做的，就是尽量合理地

穿插工作，比如：当项目处于一个迭代的测试修改阶段时，策划可以制定下一阶段的详细文档；在美术资源还在准备时，技术人员可以进行项目难点预研、代码重构等。

3.计划缺乏执行力。制定好的迭代计划不能良好地执行，经常被特殊情况打断（比如计划外打包、额外的资源调整、会议、功能增改、强制修复BUG等），导致时间浪费或者额外的工作量。

我的观点：

1）少教条主义，大家工作停下来简短地聊几句就了解的事情没必要准备一堆PPT，开个冗长的会。

2）对于额外的修改，项目经理必须顶住上面的压力，严格按照当然的计划执行，如果实在要修改，与相关人员商议调整并延长当前计划。

4.资源混乱。多次修改，经常会发现包中存在多批资源，有大有小，有拼音，有英文，有的带边框，有的不带边框等等。

我的观点：项目经理需要预先与相关人员沟通，制定好资源的格式、命名。

5.测试与BUG管理混乱。

        1）很多手游团队没有良好的测试机制，不做BUG trace，甚至没有专门的测试岗位。

        2）测试人员没有严格的测试计划与责任机制，随时测试随时提交BUG，导致开发计划与修复BUG冲突，由于是并行处理，也无法安排严谨的BUG复审，甚至会出现BUG大量积累的情况。

        3）团队缺乏对测试工作的抽查验收机制，导致测试过的功能一旦爆出新问题，反而成了开发人员的责任。

我的观点：理解测试驱动开发，制定测试计划，编写必要的测试用例。应用一些常用的BUG TRACE工具，比如mantis、bug free等。每个开发周期完成后，安排专门的测试、BUG修改和BUG复审时间。

6.士气低落。团队不受公司重视，无偿、不合理的加班，缺乏Team Building，缺乏鼓励等原因都会导致团队士气低落。

我的观点：

1）加班是影响士气、影响工作效率的罪魁祸首。很多公司就是拎不清，你真的以为晚上留下来加班的都是兢兢业业工作的？你真心觉得前一天9点走，今天一早过来的员工会干劲十足？如果真是迫于压力要给上面领导看加班，那么就多team building，多发福利。相反加班又多活动又少，光画饼有用吗？

2）多鼓励。这是成本最低的提升士气的手段了，但是很多人就是不会运用。比如你的手下完成的一个阶段的工作，哪怕问题再多，也请你先笑着肯定他的工作，如果你能多说一句“哇，连这个你都做好了耶”，我相信之后你提再多的修改建议，他都不会感到懊恼。