設計翻譯
15分鐘原則：工作被問題卡住時，我該立刻發問嗎？
前言
不管你是設計師還是工程師，解決問題時難免會遇到卡住的地方。雖然在國外工作時，大家通常比在台灣時更習慣遇到問題就丟出來解決，但頻繁的求助於同事，經常會打斷他們的工作狀態，會造成整體的效率下降。只靠自己想辦法解決的話，有時候找了一整天也仍然毫無頭緒，有經驗的同事也許只要 10 秒就啪啪的解決你的問題了。
我自己的方式通常是這樣：
1.這個問題如果不會影響到其他的工作，我會摸索一下下還無法解決就先跳過它，先解決其他的 bug 或待辦事項。
2.為了避免打斷同事的工作，一定會先自己找一下答案，準備好要問的問題再發問。
但「先自己找一下答案」的時間是多久呢？什麼時候才是自己找答案的停損點？關於這個問題，Intercom 的文章《從 15 分鐘原則，了解什麼時候該尋求協助 》提供了一個很有幫助的想法，以下是我整理的翻譯跟大家分享：
不管在哪一個部門工作，在新創公司的生活你絕對會有遇到困難卡住的時候。
決定花多少時間在解決一個問題上，也是一個挑戰。我應該自己嘗試去解決一個問題，直到解決為止？還是遇到問題時就該立刻尋求協助呢？
問問你自己：
我真的是解決這個問題最好的人嗎？
透過 15 分鐘原則，團隊裡的每個人都應該知道學習自給自足的重要，但是真的需要幫助的時候，15 分鐘原則會強迫他們去找到他們的救生圈。
這個簡單的規則是 Jeff ( Intercom 的客戶支援總監）在我還是新手客戶支援工程師時教我的。如果我被困在一個特定的客戶問題上，他跟我說在尋求協助前，我首先應該花 15 分鐘去試試看自己找答案。但是 15 分鐘過後我仍然沒有答案時，就必須向他求助。
【 15 分鐘原則 】
花 15 分鐘盡可能的去想辦法解決問題。然而，如果你沒辦法在 15 分鐘回答的話，就必須向某人詢問。
你必須為了自己做嘗試
不是 Jeff 不想幫我 — 他做到了。但如果我不斷的把錯誤升級，甚至沒有把答案想出來，我永遠沒辦法學會如何解決自己的問題。
花 15 分鐘教自己的，不僅是要找什麼而已，而是如何尋找解答的技能。
在任何客戶支援或工程團隊中，最重要的技能之一，就是會搜尋內部的程式資料庫（codebases）、文件跟了解答案就在裡面，只要你願意花時間去找。
跟上述同樣重要的是，這代表著當你要求幫助時，您至少已經掌握整個問題的完整背景。你可能已經嘗試查看資料庫、搜索舊對話、搜索Slack，並透過內部文件進行搜索關鍵字了，仍然沒有頭緒。但是 90％ 的機會，你的搜尋結果會為幫助你的同事，提供一些有價值的資訊，所以你也可以更快地解決問題。
但你還是必須尋求幫助
但有些時候，你實在無法在 15 分鐘內解除封鎖，或是你已經找了整天了。在這些情況下，15 分鐘原則會強迫你去尋求協助。
讓解決問題的深淵消失的方式太簡單了，你需要退後一步，問自己：
“我真的是最好的人來解決這個問題嗎？
事實是 — 你的時間很寶貴。用困難的方式學會新東西的感覺很好，你會建立很寶貴的技能。但是花 3 小時去解決一個，別人只要 10 分鐘就可以解決的問題是不會讓你拿到獎學金的。
如何用 15 分鐘原則幫助整個團隊
對要建立客戶支援團隊（或工程團隊）的人來說，15分鐘原則有一些很實際的優點：
- 可以教育新人學會依靠自己
- 但是當他們卡住時，有重要的安全網可以守住
- 新人可以有資深員工當導師，看他們如何有邏輯的解決問題
- 資深員工也可以非正式的順便進行審核，然後即時把問題回饋給團隊
- 支持員工提升自己，又不需要讓客戶等太久
即便我已經不是工程師了（或是即便我知道大部分的文件都放在哪裡）， 我仍然很常使用15分鐘原則。它教會我如何尊重同事的時間，但是當我真正需要幫助時，又不會害怕尋求協助。試試看吧！
結論
You Must Try, and then You Must Ask.
我自己實際嘗試了之後，覺得有進展的話稍微拉長一點也沒關係，只要先為自己設下停損的就行了。重要的是不經整理的問問題，就像是把功課丟給同事做一樣，大家都會一起掉進惡性循環裡。我們都應該更珍惜彼此的時間，在尋找 bug 解法過程，如果能稍微記錄一下，告訴同事你找到哪些方法、已經嘗試哪些作法，也會加速整個流程。先靠自己先去尋找答案，大家都能節省很多時間。
如果你也在為不知道如何發問而苦惱，希望這篇文章有幫助到你。
在工作上有問題就大膽地發問吧！
