DMA01
如何應對「緊急但不重要」的事情?

如何應對「緊急但不重要」的事情?

朱騏

這篇文章其實是將《和「電腦玩物」站長1對1諮詢,常見時間管理的問題與解答》的一部分內容抽取出並且補充說明,我不會針對「四象限法則」多做說明,網路上已經有許多相關的時間管理的文章可以閱讀,我想要分享的是:「不重要但緊急」的任務,其實是日常任務流程出現問題的警訊!

前言

知名的美國前總統艾森豪(Dwight David Eisenhower)曾提出著名的「四象限法則(又稱艾森豪法則)」理論,也就是將任務依據兩個維度-緊急程度、重要程度分成四個象限:

這個法則告訴我們處理任務的順序應該是:

  • 1.重要且緊急
  • 2.重要但不緊急
  • 3.不重要但緊急
  • 4.不重要且不緊急

「重要且緊急」的事情是我們都知道一定要先處理的任務 ; 然而許多人會在「重要但不緊急」與「不重要但緊急」的事情徘徊,而且最後都會身體老實的先處理「不重要但緊急」的事情,即使我們知道長遠來看這不是好現象。

這篇文章其實是將《和「電腦玩物」站長1對1諮詢,常見時間管理的問題與解答》的一部分內容抽取出並且補充說明,我不會針對「四象限法則」多做說明,網路上已經有許多相關的時間管理的文章可以閱讀,我想要分享的是:

「不重要但緊急」的任務,其實是日常任務流程出現問題的警訊!

讓我們一起想看看你是否曾經遭遇過以下的事情:

我們每天都有做不完的事情,在閱讀完時間管理相關的文章之後,都知道任務應該從重要開始處理,但因為任務需求來的實在太快,最後還是變成先處理「緊急但不重要」的事情!

每個人遭遇的「緊急但不重要」的事情都不相同,以我的工作來說,可能是:

* 來自業務端的臨時性需求,例如使用者在系統上遇到的bug

* 合作廠商突然遭遇不可預期、無法理解的程式問題

* 團隊內成員的假需求,也就是看起來很重要,但冷靜花30秒思考就會發現根本不重要的問題

Note:這邊所舉的例子在實務上有可能是「重要且緊急」的任務,判斷屬於哪一分類還是根據個人的工作經驗、過去遭遇問題次數來做判斷,大家可以用自己日常的工作帶入來理解

事實上,「不重要但緊急」任務曾經困擾我相當長的一段時間,請不要小看這些不重要的小任務,當它的數量是以 {小任務*N} 不斷進入我們的工作排程時,你會發現處理完這些小任務後,美好的一天就過去了。

為了解決這個問題,我在工作中嘗試了許多不同的方法,這篇文章要分享的是我認為目前較為有效的處理方法,分別是:

  • 「筆記本/便利貼」隨手記問題,有時間在排序
  • 將瑣事流程整理成「元經驗筆記」
  • 與其給人魚吃,不如教人家怎麼釣魚

 

一、「筆記本/便利貼」隨手記問題,有時間在排序

第一個方法是目前我在日常生活中最常使用的,也就是使用「筆記本」或是「便利貼」先隨手紀錄其他人送進來的小任務,等到目前手上的任務處理到一個段落後,再對小任務進行處理排序。

「排序」這件事情在任務管理中非常重要,因為人的思維是有惰性的,也就是:

先進來的事情就先做,後進來的事情放在之後處理!

這個思維最大的弊病就是,就算是小任務也會有「緊急性」、「重要性」的排序,除非這個小任務是「當下(right now)」一定要處理的問題,否則都同樣適用「四象限法則」。

根據我自己的經驗,基本上小任務如果是人家口中的「當下(right now)」必須處理問題,通常有87%都是假問題,因為如果真的有這麼急,那應該已經歸屬於「緊急且重要」的重大任務。

小結

當我們收到其他人緊急的需求時,先將問題記下來,等到有時間再進行處理排序。

有些人問過我說,究竟筆記本或便利貼哪個比較好用?我應該選擇哪一個來當作我紀錄的「實體媒介」?

要回答這個問題的答案,我認為最終是依「你是如何管理任務、筆記」而定,我自己最終選擇的是「便條紙」。以我自己來說,我在每天快下班時都會花大約5–10分鐘的時間,將這一天收到的小任務(便條紙的任務)、破碎資訊歸類到Evernote的筆記中。

電腦玩物站長在《為什麼要管理的工具那麼多?用這張心智圖建立工作匯流系統》分享了如何整理來自四面八方任務的方法,可以用一張心智圖清楚的整理自己日常的任務,下方是我的整理供大家參考:

原圖:http://bit.ly/evernote_system_flow

 

二、將瑣事流程整理成「元經驗筆記」

當我們遭遇多次同一件「不重要但緊急」的任務後,我們都可以隱約感受到:這件事情有一個固定的流程,雖然每次的任務情景都會有些許不同,但是問題本質上都是相同的,此時就是「元經驗筆記」上場的時間了!

在《電腦玩物站長的筆記思考術心得》中,我曾經分享「元經驗筆記」的概念:

當我們同個領域的筆記寫多、整理多的時候,忽然覺得這些筆記背後的知識體系都互有關連,有些筆記的結論甚至互為因果關係。

如果再稍加歸納,甚至可以發現筆記背後有一套底層邏輯在運行,而這些知識只是在這套邏輯上的不同表現而已。

這種可以重複利用的經驗架構叫做「元經驗」,是由一個固定的行動流程所組成,如果我們可以將元經驗抽取、紀錄下來,未來當我們再碰到相同或類似的任務時,只要按照元經驗中的行動流程走就可以順利解決問題。

同時也介紹了兩個抽取「元經驗筆記」的方法 -「畫流程圖」與「使用演算法思維」,這兩個方法對於日常瑣事來說絕對是最佳工具,讓我們一起回想看看,日常瑣事不就是由「重複發生的流程」所構成的嗎!

以我的日常工作來說,雖然查詢「常發性程式Bug」屬於我的工作項目之一,但在公司的RD導入了Log tracing服務軟體(查詢程式紀錄的軟體)-Kibana之後,有許多看似困難的系統問題,都可以透過這個工具、用同樣的方式來進行問題查詢,這個「問題查詢」的流程,就屬於上方所說的元經驗筆記。

小結

元經驗筆記適用在任何領域的流程紀錄,如果在工作職場中,我建議一個月就要進行一次整理,當自己能夠一步步將筆記整理出來時,一定會對業務流程加倍的了解。更大的好處是,我們可以將元經驗筆記分享給同事、後輩使用,當大家都擁有同樣一份的知識時,整個部門、小組處理日常業務的效率都可以一起提升。

Kibana畫面

 

三、與其給人魚吃,不如教人家怎麼釣魚

上面所說的「元經驗筆記」,主要是自己歸納出一套解決問題的流程,方便自己未來再遇到相同的問題時,可以用最短的時間來解決。

然而只做到「元經驗筆記」是不夠的,因為就算自己的工作效率變的超高,如果問題的源頭還是持續的發出問題,那自己也只是重複所謂的「低水平勤奮」,也就是我們看似很努力的再解決別人提出的問題,但這些問題產生的價值卻很低!

有一句相當中肯的話是這樣說的:

當問題發生時,與其解決問題,不如解決提出問題的人來的簡單!

如果我們可以減少「提出問題的人」的問題,那這樣豈不是比增加自己的工作效率來得更加直接、有效嗎!為了要達成這個目標,我找出來最有效的方式就是「寫SOP文件」

但SOP文件並不是單純紀錄一個問題的解決流程,我們可以想像,如果只紀錄一個問題的解決流程,那下次發生類似、但不完全相同的問題時,我們一樣還是要自己跳進來處理,到最後還是沒有節省我們的時間。

因此,我們應該以「元經驗筆記」當作SOP文件的基底,輔以「使用演算法思維」(相關內容可參考《思考的演算》閱讀筆記)來紀錄問題的解決流程,我們要寫下的應該是適用決大部分場景的流程。

下方為我寫給同組PM、以及常遇到類似問題的BD(業務),若遇到User(這裡指使用本公司平台的主人)提出類似問題時,都可以用這樣的SOP來進行初步問題排解,有些人也稱這樣的文件為公司內部的FAQ(Frequently Asked Question)。

日常瑣碎問題舉例
小結

「與其給人魚吃,不如教人家怎麼釣魚」,這件事情在初期時一定不容易辦到,甚至需要花額外的時間跟其他人解釋,但整體計算下來,其實是大幅降低解決問題的時間。實務上,有許多其他部門的人會抗拒自行解決問題,但是當我們已經將SOP文件建立出來時,可以用堅定的態度請求對方配合,否則就是告知對方他的需求會往後排序處理。

 

四、總結

我們都希望做能夠產生價值的任務,但現實生活就是有許多「不重要但緊急」任務(有時我們心中OS的狗屁倒灶的鳥事),如果沒辦法避免,就只能想辦法去面對它、解決它,同時思考它為什麼會重複的發生。

希望這三個小技巧能夠幫助大家處理這些「不重要但緊急」任務,讓自己可以保持好心情、同時增加時間去處理真正有價值的「重要但不緊急」任務。

 

 

原文出處:如何應對「緊急但不重要」的事情?

朱騏
朱騏

一個組織能力超強的軟體產品經理,喜歡研究軟體產品、生產力工具、時間管理方法

可提供軟體產品管理、時間管理、生產力工具的相關諮詢

歡迎講座邀約或跟我喝杯咖啡聊聊天,我的信箱是 [email protected]

【產品規劃系列(一)】軟體 PM 撰寫規格書的三大工具之一,User Story
「User Story」的目的是以簡單的敘述,用不同角色來傳達一個產品的價值,讓其他人快速了解產品/功能存在的目的。簡單而直觀的性質,非常適合作為產品功能分析的第一步。
Project delivery
Step 1:Go to market plan, Step 2:User onboarding flow, Step 3:Deployment plan
如何應對「緊急但不重要」的事情?
這篇文章其實是將《和「電腦玩物」站長1對1諮詢,常見時間管理的問題與解答》的一部分內容抽取出並且補充說明,我不會針對「四象限法則」多做說明,網路上已經有許多相關的時間管理的文章可以閱讀,我想要分享的是:「不重要但緊急」的任務,其實是日常任務流程出現問題的警訊!