反思之前对于XZ项目中被压在自己身上确认的问题或者让自己反感的问题，例如：到了发版临界时间点，自己被要求确定要延期的问题。以往自己的做法是，思考后下决定。虽然自己自信这些问题不影响，但是这样会带来后续“当初决定是产品做的，产品背锅”的风险，这仅是其一，更甚者会给小组中其他成员一种感觉，项目临界点就是可以有bug延期，需求延期发，这样让其习惯后敏捷迭代的结果就是大家越做越松散。
从明天开始自己要改善方式：可以决定优先级，对于优先级低的问题解决不完的，任务完不成者开发和测试亲自跟项目经理确认是否可以遗留，或者跟用户解释。让压力也传递到他们那里，而不是所有的压力都由产品顶着。
后续对于项目现场反馈的需求，明确自己的角色所要承担的责任：判断需求的合理性，明确用户的需求。至于需求是否要做，由项目经理确定；什么时候做要项目经理反馈优先级；怎么样做，要技术给出技术队伍解决方案。
关于产品迭代中，前期定好的计划，执行到尾期表示完不成时，前期不可以松口（包括不能缩小范围，延期）。对方提出缩小范围的点，务必问清楚砍掉的点所需工期再来决定；如果涉及到延期，也是让任务不能如期完成者亲自跟项目经理沟通解释，提出plan B是否接受。而不是由产品来出面，让开发和测试对压力有亲身感知。
网友评论