工作随笔：任务-接受-安排-核实

今天遇到一个问题：

   上周五测试经理让我推动开发修改一个问题，结果是问题修改完，功能点自验ok，以为开发会提交代码合入新包，万万想不到开发没提交代码合入（开发不打算合版本，合版本之前的全量验证耗时长，准备把待修改的几个问题修改好再统一全量跑脚本自验）。

   这个版本需要交付给两个用户，其中一个用户要求交付快一些，这周一必须转测。这个未合入的问题不影响该用户使用，但严重影响另一用户使用。测试经理担心同一版本只出1个包，所以期望这个问题解决之后尽快合入。（为什么测试经理会以为一个版本只出一个包？）

   开发经理找测试经理确定解决方案，决定这个问题先不合，尽快转测交付给一个用户使用，然后再出一个包，合入该问题交付另一个用户使用。后续交付确定哪些问题必须合，什么时间之前必须合，应该测试经理、开发经理、产品经理一起确定，不要找普通开发确定。

   看着领导侃，突然发现自己窥见了事件的全貌。明白为什么有些问题自己回答不了，只能领导上。

   事件发生之后，才发现自己理解得太肤浅。领导交代了做什么和为什么做，自己明确地知道下午打包之前，开发必须解决问题，合版本转测。但是为什么开发没有了解到这一点？他又是跟谁确定的不合版本？

   做这件事之前跟测试经理沟通如下。

   问：为什么必须解决？

   答：马上要出版本转测，测完交付用户使用。

   所以跟开发沟通的时候也是强调了必须在打包之前解决问题。

   开发知道下午打包之前必须解决，但是就是没有合代码。

   经过这件事，发现自己有些问题又想当然了。比如：在此之前，不知道要找开发确认是否提交代码合入版本，只知道确认问题真的“解决”了，实际漏了关键最后一步。其次，不知道这个版本要交付给2个用户，不知道这个问题只是影响其中一个用户的交付，后面发现决定问题是否合入是由用户对交付版本的需求决定的。再次，开发经理问我，如果这个问题不解决，对用户影响有多大，我无法回答。当时有点心虚，不光是不了解对用户影响有多大，还因为想到用户是以后才用到这个功能，目前基本没有影响，没有想到如果后面再出版本，用户需要重新升级，也是个大工程。我关心的只是这个软件的功能是否OK，从未考虑过功能对用户的影响有多大。

   在做事的时候，我没有把事情问明白，也没有交接好。原因是做事的时候太想当然，要改。以后做事，但凡有疑虑的地方，一定要问；交代事情，一定要核实结果是否跟预期一致。