如何快恨準的抓住工作重點

來自專欄項目管理4 人贊了文章

背景

最近在帶一批剛剛入職的應屆畢業生，突感歲月不饒人的同時也有歲歲年年只是人不同的感覺，通過他們目前的工作方式，回頭看自己曾經走過的路，發現繞了好大的一圈。作為腦力勞動的工程師，是以結果為導向型的工作，這類工作是要看自己能創造的「功勞」有多少，這也是我所理解的高效工作。

至於為什麼會將「功勞」和高效聯繫起來，請看下面百度百科關於高效工作的定義：

請大家默默的想想什麼叫取得的成績，直白的話說就是拿的出手、說的出口的績效，這個就是工作中的「功勞」，至於「苦勞」是算不上成績的，甚至對於有的上司來說，「苦勞」還是無能和低效的一種隱喻。至此，有木有覺得找對事情做其實比雞湯告訴我們的做好事情還要重要？

在錯綜複雜的工作中需要解決的關鍵的事情不會直接呈現在面前，尤其是工作三五年之後分配的任務更多的是一個標題，因此需要獨立的思考哪些是關鍵問題。本文結合本人幾年薄薄的工作經驗，和大家一起探討一下如何找到工作中的關鍵，快恨準的抓住重點。

關鍵問題

如何像愛因斯坦老爺爺一樣用55分鐘的時間去分析問題，用5分鐘的時間一針見血的解決問題呢？（這個時間比例僅表明分析問題的重要性）很多書上都有介紹，比如《金字塔原理》《麥肯錫的問題解決》《關鍵問題》等，所以原理性的就不再追訴，這些方法融合起來都比較類似，一下的6部曲為例子結合實際工作為分析：

Step 1:澄清問題最重要的就是要先了解項目背景，對相關的工作內容有個了解

比如我目前在做模型測試，如果拿到這個任務直接輸入邊界條件進行模擬，最後給出一個模型精度值，這個表現任務只能體現出苦勞因為整個過程就是一個體力勞動。因此需要換一種思考方式，目前的項目plan是什麼，提供給客戶的軟體和硬體是否是目前模型測試的，該軟硬體是提供給客戶的最終版還是中間測試版，如果是中間測試版那麼終止版客戶需求時間是什麼時候？通過這些問題就搞清楚了項目的背景。

Step2：挖掘訴求就是要分析做這件事情的主要動機

再進一步去分析，為什麼需要做這個模型測試？據我說所知該測試的軟體已經在台架標定過了，模型測試僅僅是為了驗證模型精度？經過交流才知道驗證模型精度只是第一步，後面還要用這個精度符合要求的模型進行軟體的瞬態和高原標定。

Step3：找准問題是繼挖掘訴求之後的，針對訴求要定義出這個任務關鍵

那麼關鍵的問題就是我需要理清楚軟體釋放的流程和日期，進而定義模型測試的一個計劃表。這個是我的關鍵任務。

Step4：確定關鍵是在這個關鍵任務中哪些問題是必須要解決的

在模型測試中又會碰到很多問題，比如切換不同的硬體時，需要在腳本文件中修正一些參數，這個是可以花很少的時間快速解決，而碰到一些非能力範圍內的事情時，基於學習的態度會先嘗試著解決，但時間花出去後又沒有進展，就要思考這個問題對於這個任務是不是必須要解決

Step5：確定可行

如果不解決任務能否進行？情況1）可以不用解決，這個就好說了直接跳過情況2）必須要解決，此時就是關鍵問題了。那麼自己要先預估解決這個問題要多久？

Step6：正確思考

和最初的plan相比有沒有落後？如果有時間上的滯後，在解決問題之前，先把問題描述清楚和相關人員溝通，避免給後續工作造成不必要的麻煩。這一點也是學習PMP一個很重要的心得，溝通是一件很重要的事情，即利於自己的工作也不會給別人造成很大的麻煩。

通過這幾部的分析，基本就能確定出做這件事情重點需要做什麼，關鍵節點在哪裡，

如果能不斷的將這種思維結構化，快恨準的找到「功勞」型工作就不再是難題了。

畫外音

其實這種求源的思路在汽車行業已經應用的爐火純青，比如魚骨圖，5W1H，DMIAC,8D，這些所有的方法不過都是為了找出根本原因，徹底的根除問題所在。其實這些方法也是適用於我們的日常。比如以DMIAC結合5W1H為例分析如何找出關鍵問題為例。

在measure和improve中間必定要經過問題和結果的分析，比如我們可以用魚骨圖、用5W1H的方式進行brainstorm。

這種方法在各個行業都是通吃的，在掌握技術技能的同時如果不斷地套用這樣的思路去解決問題，工作將會變的事半功倍。