「怎麼隕石又來了!急件又來了?我該怎麼處理?」
面對這件事,我們的選擇只能是「加班」和「死命的加班」嗎?有沒有更好、更科學的處理方式,能幫助我們不加班的順暢解決呢?我整理往年的經驗,並條列如下的推薦給大家:
- 有效運用 Yesterday’s Weather:Scrum 是一個大量運用數據的科學管理方式,在重視數據管理的現代,請記得務必要估算前三個 Sprint 的 Velocity 平均值,以便了解團隊以往的概略狀況,用於預測下一個 Sprint 的大概能處理的任務 Story Point 總量。而推薦這項作法的原因在於,第一、平均值是統計學中最常見的統計方法,它能用來表達要觀察的數據值相對較集中的數據位置。第二、它是目前最簡單好理解,以及最快速的統計工具,在面對快速變化的市場和環境,我們要盡可能地簡化自己在其他方面的複雜處理,減少複雜性,就能減少暴露在風險中的機會,也才能讓事情能快速且有效的進行。
- 有效運用 Interrupt Buffer:鑑於 Scrum 的科學化管理原則,以及面臨市場和環境變化的迅速,請記得務必要估算前三個 Sprint 的插件平均值,並扣除 Yesterday’s Weather 的數值,以便快速預測出下一個 Sprint 的比較接近實際的任務 Story Point 總量。
- 落實重視 Product Owner 的專業判斷:Product Owner 是面對需求方、利害關係人(或老闆們)的重要窗口,所有需求都需要經過 Product Owner 的裁定判斷,才能落到團隊身上,以便執行。若所有的需求都是說來就來,沒有經過最理解產品狀況和 domain know-how 的Product Owner 的判斷,那麼產品勢必會走向一團混亂,技術債快速的債台高築,影響到產品發展,即使組織內業務和行銷單位再強,也無法避免掉不好用的產品評價。要記得,產品使用者才是產品能存活在市場上的最最重要核心。
- 強化與利害關係人的有效溝通:當急件來的時候,非常需要 Product Owner 與利害關係人的有效溝通(甚至 Scrum Master 也應該加入溝通協調),以便讓利害關係人知道產品是否需要這樣的需求,以及團隊目前的狀況,這樣的目的在於讓「資訊保持公開透明度」,並塑造 Scrum team 整體的聲譽,當團隊給人的印象是可靠誠信、資訊通透清楚,那在與利害關係人進行溝通時,便能有效地讓其知道是否真的有必要這麼做?若沒必要做而需要拒絕需求時,對方也能真心理解和接受。要記得,「誤解,來自於對彼此的不理解」,保持資訊公開透明度,尤其是組織各單位運作時,非常最重要的基本元素。
- Scrum Master 與 Product Owner 的良好協作:Scrum team 的成員為 Scrum Master、Product Owner 和跨職能的 Developers(指UX、UI、BA、QA、Engineer 等各種跨職能的產品開發團隊成員),當急件發生時,請 Product Owner 務必與 Scrum Master 溝通好事情的前因後果,與該如何與 Developers 溝通的適當對策,讓 Scrum Master 協助 Product Owner 與 Developers 討論為什麼會有這項急件?做了急件對公司和產品有什麼好處?這項急件要完成什麼樣的內容?確保整體 Scrum team 都能理解急件的完整內容,以便讓團隊能一起將這項重責大任儘早完成。
- Trade-off 掉與插件大小差不多 Story Point 的較不重要任務:一天只有 24 小時,MIB 電影中提到的一天有 48 小時的這種事,不存在於彼此的現實生活中,因此,任務不是盡量塞好塞滿就好,而要考量到團隊能承擔的狀況,所以務必把「和插件估算出來差不多的 Story Point 的較不重要任務」(即這任務是「相對於其他任務來講,相對較不重要的任務」)從當次 Sprint 中剔除,延後到其他 Sprint 中處理。要記得,人是組織內最重要的資產,如果不善待「人」,只把人當成「工具」,那麼終究只會獲得高流動率且不忠誠的員工,而組織就只能不斷地經歷 Bruce Tuckman 提到的團隊發展階段(Stages of Group Development)的 Forming 和 Storming,而永遠到不了能開始展現團隊績效的 Norming 階段,更不用談進入團隊發光發熱的 Performing 階段了!
急件總是說來就來,而且絕對無法避免它的出現,因此,我們需要好好地了解它、面對它、處理它,才能好好地完結它,讓對需求方和團隊都能擁有好的結果。
這篇文希望能帶來一些新的視野。若你有一些經驗想與我分享討論,歡迎聯繫我!: )
— — —