关于沟通

总结经验贴，欢迎提意见

文档中不许有套话

所有文档中,对于 试用于两个以上项目的文字,  不允许出现,必须全是"干货"

 

项目任务时间中包含评审时间

比如:概要设计的三天中包含"设计评审"时间,自己的任务有的提前或者稍延后是可以的,但不能影响其它人

过程中不沟通,最后评审才发现问题的需反省

 

研发不自测不得提交给测试工程师

此类现象属于不尊重测试工程师,没啥好说的

 

测试经理有权拒绝测试

不符合测试流程,提交版本混乱,质量差 等可以拒绝测试,产品质量问题 测试经理需直接向小pac汇报

意见的沟通:

平级间尽量进行有建设性的提意见,即提意见时附带解决方案

无解决方案时反应给部门负责人,由负责人想办法,防止认为是"抱怨"的误解出现

 

经验分享:

为呱呱维基做贡献 我们不同部门间在犯同样的错误,请 分享你的经验,这样你才能学的更多

技术经验,协调经验,项目经验,沟通经验均可,你牛就请证明这一点

 

开发-开发间协作:

提供的接口和模块需完成自测(测试工具or白盒测试or测试工程师测试),不得靠连调测试,那是在耽误大家时间

 

开发-测试间协作:

开发提交的安装包/程序 需完成测试经理提供的冒烟用例,无用例时完成基本自测,基本功能都不能用就给人家测试不是拖人后腿么

 

邮件使用:

通知类使用邮件,需要互相了解的面谈或者电话,禁止把邮件当论坛使

 

复盘:

         项目总结,月报,部门例会是用来共同复盘和分享经验的,这个非常有用,请重视

 

质量不单是测试的事情:

测试不可能测到所有出现概率再1/10000以下的bug的,需要开发人员靠自己的设计和编码实力,逻辑思维水平来保证

 

任务分配:

任务分配坚持S.M.A.R.T. 原则,并提前告知

 项目不等人

项目中有人请假等需安排人代为行使相应的角色,让大家等某个人是不合适的,请假人的主管要保证这一点

 

会议是统一认识的,不是现场解决问题的

会议主要是用来 任命,通知,整体沟通的,禁止出现会前不沟通,会上两个人激烈争论, 其余人员集体打酱油的情况

尤其是目前的需求会等,必须事前讨论过

重要不紧急的事情需要优先做,否则天天是即重要又紧急的事情

 

项目必须有 核心需求&上线时间

公司的战略需要各个版本去落地,每个版本必须配套相应的"使命"与"核心需求",而且要有"时间线",否则一个版本无休止则后续版本无机会!

 

出现争议由上级间解决

项目中各方出现争议或者问题不得搁置或者"冷处理",必须分别反馈给上级领导,由上级领导间协调解决,已经出现过因"搁置"而严重影响项目的情况