上週可以說是工作的地獄周，因為突然所有手邊本來就在趕進度的工作突然被一個臨時插進來更緊急的歐洲合規政策簡稱MICA用戶專案給硬生生輾壓過去，終於在如火如荼地加班一周後把這件事搞定，雖然中間也穿插一些Hot Fix 小工作，但也是算安全達陣。
只是上周一開始這件MICA專案被插進來時，有兩件事我只做對了一件，那就是約團隊一起重新排工作進度，確保在MICA專案能順利優先完成的情況下，那些手上緊急的任務可以先暫緩，哪些又可以先停掉，原本以為只要把優先級較低的Task直接停掉即可應付，但一場會議下來發現有4個跟車 6.26要上線的需求中有些是APP需要的後端需求必須在6.20完成驗證上線，這部分就很硬了，因為當時覺得6.26跟車是一種跟外部團隊的支票，不太可能延期，那就是無論如何都得在 6.20前先把後端的需求驗完上線，而 MICA 的驗證結束上線時間也是6.20，那真的是神仙打架，凡人莫測。
不過，還好老闆及時出現了，她點出了一個重要的點：因為MICA的完全優先級，整個部門6.26發車的需求早就都先暫停了，為何Copy-Trading這邊還有這些跟車需求要做呢？
That’s a good point！對阿！為啥整個部門都已經發布6.26 MICA專案優先了，理當是所有衝突的需求都會被暫時，那為何我們還在這邊討論跟車需求如何併行完成？
也因為這樣我一開始就被產品壓著說這些跟車需求怎麼排進來測試，老闆點醒之後才知道原來產品這邊是可以回頭檢視6.26這些跟車需求是不是可以先停下來的，因為其他要發車的團隊都暫停了，跟車的為何還要上車？
這件事給了我相當大的反思和震撼，那就是我並沒有完全理解到發車需求、跟車需求和我們原本的自己開車需求的差異化，導致在排需求優先級時，我無法用較新的思維去思索這種完全的需求衝突狀況下如何調整專案測試優先級！
跟車需求既然是跟著發車的人，而發車的人又因為MICA被迫先不發車，那麼我們跟車的人為何要堅持上車？對我們來說當然是既然車子都不發了，我們自然也不用趕車，直接跳過這跟車需求去衝刺MICA就是！
這就是說專案執行任務的協調上，是應該跟隨專案工作模式改變而有彈性工作思維的，這次是第一次從自己開發自己的需求轉成跟著別人的需求一起上車，也因此我們應該要Aware到我們排定需求工作優先級時，也應當是參考其他發車需求的狀況而作調整的，並非是他們說幾點開車我們就只能幾點上車，因為有可能他們發車時間也會改變，這時候我們就可以決定我們要何時上車！
所以要做到這點，就得掌握全工作組團隊的資訊（不只自己的專案團隊），我沒有掌握到這資訊就來開排定需求優先的會議，自然是給不了產品一個我們跟車需求可以先暫停的方案，才會被產品壓著劃時間，後來了解到發車的人也都不能如期發車了，反過來我們才能要求產品暫停跟車的需求，一切以MICA優先！而這也需要我即時的思維跟隨專案工作模式改變。
另外就是老闆會後找我了解為何感覺產品不知道發車需求可以暫停，才意識到在跟車需求這件事我這邊也沒有即時和車子上相關的QA對上時間，如APP團隊根本也還沒開始測試發車需求，我們這邊怎麼可能6.20就跟他們對接？
這就是另一個要改變的工作思維的地方了，跟車之後與其他團隊在時間合作上會產生更緊密的連動關係，所以確認彼此的測試時程和聯調時間點才能保證開車和跟車的人在同一條時間線上，只是之前產品和開發直接就跟APP Team的人說好了時程，繞過了QA這一層直接給出發車時間，才導致計畫生變時QA排定工作任務的混亂，在這邊我也必須知道之後再與其他團隊的QA對接上應該更緊密地同步測試節點訊息，才不至於不知道他們車開到哪了我卻還在刷牙洗臉。
總結就是專案工作模式改變時，我們的專案工作思維模式也應該作相對應的調整和改變！即便是跟車的需求，必要時也是可以先跟著還沒發車的人停車，這當中需要的則是和發車的人隨時保持訊息同步，這樣就不會被丟包路上了。
2024年6月17日星期一
留言列表
