路宁(luning)的博客

有一个新入职的Dev，每次开发完一个功能后就叫上QA到自己的机器上来测试，并不像大多数Dev一样发起正式的提测流程。

他这么做一方面是因为担心自己开发的质量差，正式提测后的Bug被记录下来，影响他的KPI表现。另一方面是正式提测如果有问题还要打回来，来回走流程费劲。

QA起初积极配合，但后来发现这么做对自己很不利，无法在领导那里体现自己的工作。因为QA是根据Dev的提测计划制定自己的测试计划，QA经理主要根据测试计划及执行情况来了解手下人的工作。不仅如此，这样做还会影响自己的一项KPI：漏测率。漏测率是指上线后发现的Bug数除以总Bug数，如果记录的Bug基数少了，漏测率极易上升。

QA反应过来这个问题后就不再配合了。Dev嫌QA变默唧了，QA 反过来嫌Dev懒，让他正式提测。两边合作不愉快，就开始找“流程”帮忙，沟通少了，一切走邮件，走流程。

Dev 感觉QA 让他名下的Bug多了，搞得自己在Dev经理面前很没面子，和QA说话时自然没什么好语气。QA 心里也不顺，本来没多大的事，搞得默默唧唧的。

最终的解决办法是，走流程，你在系统里提测，我才测试，有问题记录Bug，依赖Bug跟踪系统......

哈哈，有意思吧。你能说这个Dev或QA不够好吗？不是。

不管出于什么动机，他们确实发现了一个更高效的合作方式，但却被“流行的组织结构”，“僵化的KPI”，和“万能的流程”无情地打击了......

我最近Lead一个QuickStart，第三周编写Story，这一周就像是整个项目的缩影，它让我看到了项目的未来：屈服于压力，不尊重实际的速度，迷信业务的承诺，轻信自己的判断，后期加班，项目延期。

我和一个BA想用一周时间（本周有7个工作日）把Story都做出来，并制定交付计划。之所以是一周，是因为第二周要做汇报。开始比较乐观，认为Story可以很快产出。

周一：
只做了30个Story，比预期的少了近一半，但一想只花了半天做Story，以后应可以补回来。

周二：
做了28个，远少于预期，因为今天又有别的事，不能全力做Story，也许明天会好些。

周三：
做了34个，今天多了些，但感觉Story的总量会比预期多不少。我们反思了一下，业务（客户）的支持不足是最大问题。心想，如果业务一直在身边，写起Story肯定神速。于是争取了一下，业务承诺每天10点至少支持我们2小时。

周四：
业务如约来支持我们，但主要是Review做好的Story，没写新的。下午业务开会，还是我们自己写Story，今天完成40个。

周五：
业务没有来，因为他每天都工作到凌晨3点，虽然承诺10点到公司，但11点还在自家床上呢。看来只能加班适应他的时间了。今天做了33个。

周六：
我们11点多才到公司，就是准备晚上陪业务加班。加上加班的2个多小时，共写了42个，并没有预期的50～60个那么多，原因是“软柿子”都被我们捏过了，剩下的都是复杂的需求了。

周日：
一早我和老大分析了一下，决定推迟汇报的日期。业务那哥们今天大部分时间都在支持我们，但由于剩下的都是复杂的逻辑，今天只做了40多个。

一周回顾：
一开始根据汇报的时间点做了乐观的估计。3天后有了实际的“速度”，但迫于压力没有据此调整预期，因为还梦想着业务会支持我们并大大提高生产率。后来发现业务近两天不可能提供全面支持，于是决定加班。之后又发现即使业务支持了，速度也未必明显提高。最后决定延期交付。

哈哈，整个过程俨然就是将来项目的缩影，该犯的错误是一定要犯地！