Give me an example of a calculated risk that you have taken where speed was critical. What was the situation and how did you handle it?

類似問題:

主要從故事中觀察如何在時間匆忙時做出適當的判斷與評估


I remembered when I was at Bird (a share scooter company that put scooters on the street for people to ride), we received a notification from the Chicago city govt that Bird is not allowed to operate in the city, and need to move out within a week. But Bird did have a sub-company that owns the license, so we have to make a brand new app and switch the scooter brand name. With Android and iOS submission approval time, we probably had about 72 hours. I was the deputy QA manager since my manager is out on vacation. 72 hours to build/test the app on iOS/Android is not enough time.

I had to make some choices and trade-offs. The worse case is Bird got kicked out of Chicago, and was not able to operate after 72 hours. Any extra days the company is losing money. As long as the majority of functions of the app are working, which are payment, riding, and stopping riding the scooter via the app, then other regression issues can be addressed later on. I worked with team members, and we made sure that the app is working the way it is with Smoke Test, and check no Bird name showing up in the app because the development team is not really going to re-build the entire app, it’s pretty much white label the app, and release the app. In the end,

we successfully released the app on both platforms, and we had a couple of regression issues, but the cost for that is much much lower than not being able to operate in Chicago


套用:比較難套用的一個故事 但思路可以圍繞在損失大與損失小之間做選擇 可以設立一個緊急的場景 例如 deadline要到了 主要人員突然家裡有緊急事情 等等之類的

ST: Bird在芝加哥的經營職照被掉銷 所以不能繼續在芝加哥營運了 但是Bird的子公司在芝加哥還是有經營職照的 Bird大概只有72小時的時間來上架新包裝子公司的app

A: 我必須做一些選擇 確保產品主要的功能可以運做沒有問題 以確保公司營運收入不會停止 其他小問題可以之後在解決

R: 最後成功在期限內把app上架 雖然碰到一些小問題 但是損失遠比無法在芝加哥內營運還要來的小