先看下面我经历的一个直实的场景 ,小问题的反思
新产品发布到用户那，用户在页面上找一个checkbox 一直没找到，然后问客户，这个checkbox 为什么找不到
客户问产品经理，产品经理一看确实没有客户说的checkbox，但在需求的原型界面中有，然后问研发人员，
研发人员说，我看这checkbox 没什么用，我做的时候就把她去掉了
然后产品经理去问测试人员，测试的时候怎么没测试出来，测试人员说开发人员告诉我，按他现在做的测试，然后我测试了现在的实现，没问题。
你要是作为部门的负责人，问题虽然是小问题，但足以引起得视。如何看这问题呢？测试人员问题！开发人员的问题！我看他们都有部分责任，但更主要的是管理流程的问题。
首先开发人员，在自以想当然的更改了客户的需求，且没和产品经理商量；本来测试那边也可以纠正这错的，他们没严格按需求来测试，导致最后一道防线也没守住。
如何避免再出现这样的问题呢？首先变更要和产品经理商量，没他批准不能更改，一旦批准了更改，要通知项目干系人，测试人员，测试时严格按需求来测试，如
测试物和需求不一致，要向产品经理说明，然后产品经理，该如何和用户沟通，那就是产品经理该做的事了，或是在进度能保证的情况优下让研发那边按原有需求来
实现。
导读目录
一：BUG龄期的意义
二：BUG龄期的定义及分类
三：BUG龄期分析的实现
一：BUG龄期的意义
在一个项目完成后，BUG龄期这个指标，在分析团队的解决BUG的效率方面是很有意义的，特别是在团队进行对比时，也可作为一个参考项.
二：BUG龄期的定义及分类
从定义上来讲，就是BUG从某种状态演化为另种状态的过程所花费的时间。
从关注点上我们可以分来下面几类
（1）己关闭BUG龄期：BUG从发现到解决的龄期，她又从时间段上按天和按周来分为两类，不同的项目阶段对时间段的关注也相当强烈
(2)待处理BUG龄期，除时间段上又分为按天的按周外，待处理龄期，又分为绝对龄期和待处理龄期。从待处理龄期上可以发现中间环节是否顺畅，比如测试人员发现的BUG，开发人员迟迟没修改，不一定是开发人员的问题，因为在分配环节停停留得太久，开发人员迟迟没有被分派到BUG；绝对龄期反应的是整个团队的效率。
注： 待处理BUG指所有未解决的BUG；待处理龄期为停留在某个处理流程上的龄期;绝对龄期指从提交到现在的龄期
三：BUG龄期分析的实现
我们从下面的图表来看
己关闭BUG按天龄期
己关闭BUG按周龄期
注： 待处理BUG指所有未解决的BUG；待处理龄期为停留在某个处理流程上的龄期;绝对龄期指从提交到现在的龄期
待处理BUG按天待处理龄期
待处理BUG按天绝对龄期
待处理BUG按周待处理龄期
待处理BUG按周绝对龄期
