工作隨筆：任務-接受-安排-核實

今天遇到一個問題：

   上週五測試經理讓我推動開發修改一個問題，結果是問題修改完，功能點自驗ok，以為開發會提交程式碼合入新包，萬萬想不到開發沒提交程式碼合入（開發不打算合版本，合版本之前的全量驗證耗時長，準備把待修改的幾個問題修改好再統一全量跑指令碼自驗）。

   這個版本需要交付給兩個使用者，其中一個使用者要求交付快一些，這週一必須轉測。這個未合入的問題不影響該使用者使用，但嚴重影響另一使用者使用。測試經理擔心同一版本只出1個包，所以期望這個問題解決之後儘快合入。（為什麼測試經理會以為一個版本只出一個包？）

   開發經理找測試經理確定解決方案，決定這個問題先不合，儘快轉測交付給一個使用者使用，然後再出一個包，合入該問題交付另一個使用者使用。後續交付確定哪些問題必須合，什麼時間之前必須合，應該測試經理、開發經理、產品經理一起確定，不要找普通開發確定。

   看著領導侃，突然發現自己窺見了事件的全貌。明白為什麼有些問題自己回答不了，只能領導上。

   事件發生之後，才發現自己理解得太膚淺。領導交代了做什麼和為什麼做，自己明確地知道下午打包之前，開發必須解決問題，合版本轉測。但是為什麼開發沒有了解到這一點？他又是跟誰確定的不合版本？

   做這件事之前跟測試經理溝通如下。

   問：為什麼必須解決？

   答：馬上要出版本轉測，測完交付使用者使用。

   所以跟開發溝通的時候也是強調了必須在打包之前解決問題。

   開發知道下午打包之前必須解決，但是就是沒有合程式碼。

   經過這件事，發現自己有些問題又想當然了。比如：在此之前，不知道要找開發確認是否提交程式碼合入版本，只知道確認問題真的“解決”了，實際漏了關鍵最後一步。其次，不知道這個版本要交付給2個使用者，不知道這個問題只是影響其中一個使用者的交付，後面發現決定問題是否合入是由使用者對交付版本的需求決定的。再次，開發經理問我，如果這個問題不解決，對使用者影響有多大，我無法回答。當時有點心虛，不光是不瞭解對使用者影響有多大，還因為想到使用者是以後才用到這個功能，目前基本沒有影響，沒有想到如果後面再出版本，使用者需要重新升級，也是個大工程。我關心的只是這個軟體的功能是否OK，從未考慮過功能對使用者的影響有多大。

   在做事的時候，我沒有把事情問明白，也沒有交接好。原因是做事的時候太想當然，要改。以後做事，但凡有疑慮的地方，一定要問；交代事情，一定要核實結果是否跟預期一致。