事項1：
背景：倉庫需要增加循環盤點功能，但這個項目又包含了商家端部分需求。KA和服務同學希望能夠把盤虧原因和轉殘原因透出給商家，以便商家能夠知曉庫存產生此類異常的原因，並能夠基於此來覈算哪些是需要倉庫賠付的。同時，也需要輸出給商家一份月度庫存報告，該報告中包含了月末最後一天的結餘庫存和當月轉殘/盤虧/賠付等彙總數據。
說明：晚上約了中臺同學聊需求和排期。因爲項目是7月30日上線，中臺同學反饋這個需求無法排期，預估需要1130以後。同時，他們提到菜鳥如果再面向商家透出一份庫存數據，當這份數據和商家看到的供應鏈庫存數據不一致時，該如何處理的問題。
反思：
1、涉及中臺改造的需求沒有在項目初期就involve他們一起進來，也沒有第一時間對焦需求；
2、溝通過程太久，且一直沒有明確結論，都是單點溝通，效率非常低，浪費了太多時間
3、面向商家只能展示一份庫存數據，否則當兩份數據存在差異時，商家諮詢量非常大，且商家更容易發現兩份庫存的差異，更能感知到內部管理的問題，也就暴露了更多的問題，且庫存不一致是不可避免的問題。因此，要儘可能避免同時透出兩份理論上應該相等但實際上可能不相等的數據源。
事項2：
背景：貨主二期預計上線時間從7月2日延遲到7月7日，再延期到7月14日，再延期到7月16日。且每次都是上線前1-2天發現問題。第一次延期是因爲頁面設計不合理，產品驗收時才發現問題，屬於需求變更；第二次延期屬於沒有考慮上線前的培訓，也沒有預留時間寫操作手冊，而服務同學堅持要先培訓才能上線。第三次是因爲商家灰度問題，原本是按照對商家操作不影響的方式設計方案，但沒有考慮到未參加培訓的商家看到新增加的字段時會帶來較大的諮詢量。
反思：
1、產品驗收需要儘早完成，儘量提前發現問題，不要等到UAT前1-2天才提出來
2、項目開發過程中就需要同服務運營和業務方溝通清楚培訓計劃和灰度要求，並把方案前置做到開發環節，不要一步步像打補丁的方式來實現。
3、做項目，要明確每項工作最晚在哪個節點完成，否則就可能出現準備做某個事情時，發現還沒有明確的方案，就只能先湊合着做，或者就只能緊急找開發同學來支持，這種情況多了，就會給其他人造成你很不靠譜的感覺，也就很不願意再和你二次合作。
4、做面向衆多商家的產品方案時，不要想當然地，不要過於自以爲是，不要認爲我能理解，或者我覺得沒問題就怎麼樣，要藉助公司內部不同人對商家的認識和理解，讓他們給出更加專業的意見。當你沒有足夠的判斷力的時候，請放低自己的姿態，請虛心接受別人的意見。