身為 PM 如何應對「緊急但不重要」的事情？(下) | 專家論點【朱騏】

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

為了解決這個問題，我在工作中嘗試了 :

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

上篇文章已講完方法一，這篇文章將後面的方法說完。

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

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

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

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

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

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

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

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

元經驗筆記適用在任何領域的流程紀錄，如果在工作職場中，我建議一個月就要進行一次整理。

當自己能夠一步步將筆記整理出來時，一定會對業務流程加倍的了解。更大的好處是，我們可以將元經驗筆記分享給同事、後輩使用，當大家都擁有同樣一份的知識時，整個部門、小組處理日常業務的效率都可以一起提升。

與其給人魚吃，不如教人家怎麼釣魚

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

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

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

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

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

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

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

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

小結「與其給人魚吃，不如教人家怎麼釣魚」，這件事情在初期時一定不容易辦到，甚至需要花額外的時間跟其他人解釋，但整體計算下來，其實是大幅降低解決問題的時間。

實務上，有許多其他部門的人會抗拒自行解決問題，但是當我們已經將 SOP 文件建立出來時，可以用堅定的態度請求對方配合，否則就是告知對方他的需求會往後排序處理。

總結

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

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

瀏覽 6,312 次