例行维护前，你的测试部门加班吗？
一款已运营的产品，几乎都有例行维护。而在例行维护时，一般又有bug的修复或内容的更新。尤其在投入运营不久的那个阶段，例行维护的更新内容是较多且频繁的。例行维护的周期常见的是一周一次。每周的例行维护，测试部门是否加班，我想很能体现一个团队的专业成熟程度，并尤其体现leader们的规划管理能力和成员们的执行能力。
调查一下业内的测试员们，无一例外的都对加班不陌生。
这一点我要由衷赞一下我的团队leader们和我的同事们。因为我们的产品已经运营中，但几乎从不加班。我们的流程是成熟的，各环节的沟通也是顺畅的；应对紧急情况的措施也是成熟的。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/qiaoanlu/archive/2010/03/31/5436205.aspx 我们运营期间更新版本不加班。
加班主要出现在开发赶工期,测试需要配合的情况下
运营期间的更新流程与PM提前沟通好，留给测试部门足够的测试时间。
有一种可能会加班。类似资料片的大量功能、数据更新版本，boss定死了更新时间。开发在赶工期，测试时间紧张，只能加班。 开发赶工期，加班到什么程度和强度？ 2种模式
1、小长期每天多加两个小时，不加周末。3-4个星期后缓一个星期。
2、必须在短期内完成某个目标，通宵后直接休息。
加班这种速效技能是有反馈伤害的
对人员的身体、意志、积极性等都有可能带来debuff
这种debuff控制不好也许会出现人员流失。工期完成的困难就更加大了。
留下的人在已有任务的基础上再加上离职人员的工作。叠加debuff状态
[ 本帖最后由 maxwell12 于 2010-3-31 13:17 编辑 ] 加班无工资，调休不兑现，好像挺普遍的 :L 公司的QA 刚成立没多久。。。加班很普遍， 没加班费也是正常现象。~
调休~？ 那是什么！？ 不加不是解决问题而是讨论问题的班，
不加加了也无法解决问题的班，
不加正常加班以外的加班，
不加突破人体生理极限的班，
除此之外，求加班。。。越多越好。
基于以上原则，不加班。 每周维护晚班或者早班，感觉挺郁闷的，程序策划qc3个部门流程不协调，技术又低，leader只强调“努力”，什么新改革新技术的态度就是“不可能的，这么乱的情况下”，结果很容易就是晚班做到晚上12点，本来效率高的话，工期管理控制得好的话是没加班的必要的……同个一个公司，一个组这周就测完下一周的内容，一个组正赶着测试这周的内容；那边一天测试2小时就有空闲时间，这边感觉整天都有东西等着测；差距不是一般的大 工作流程不好造成的必然结果 我只加过一次班
调休倒是一定可以兑现的。
调休~？ 那是什么！？
好经典
页:
[1]
