大家好,我是烏陵土明。


過氣的遊戲製作人烏陵土明。(為什麼過氣?因為曾經輝煌過。)
專案災難專家烏陵土明。(為什麼是專案災難專家?因為我說好的不一定準,說壞的一定準)
三吸達人烏陵土明。(哪三吸?吸空氣、吸菸、吸鼻涕)
敗家達人烏陵土明。不是我很會BUY,而是我經常慘「敗」。
很雖的抽籤合宜宅沒抽到,卻很幸運的候補買到浮洲合宜住宅,又變成很雖的成受災戶的烏陵土明。
DIY維修工具人烏陵土明。

什麼是烏陵土明呢?為什麼你筆名叫做烏陵土明呢?請看這篇  「什麼是烏陵土明


你聽過安麗嗎  

(先不管這個,你聽過安麗嗎?  ==>  這句話,是鄉民流傳的經典語句,堪稱終止話題的經典[話術工具]。)


 

 

有些工具是整套的[工具組],較複雜,較難說明。下面的[問題分析與處理]工具組就是其中一個例子。

 

 

五、[問題分析與處理]相關工具

        相信各位可能有這樣的經驗:公司遇到了某個問題,因此某高層主管下了決策去處理。可是,最後還是沒處理好,還延伸出其他的狀況。為什麼這樣下決策?有甚麼根據?有考慮到其他環節嗎?沒人知道。

        為了讓決策流程更加合理,有方法,有根據,因此才有了[問題分析與決策]這樣的企管課程。由於課程內提到的方法、流程相當複雜,也不容易一下子就上手,因此烏陵又把課程重新整理簡化。如下:

1.問題發掘。

 

  • 工具:nWnH(有的是5W,有的5W1H,還看過5W2H,7W3H,反正大概就是不離Who,What,When,Where,Why,Whom,How,How much,How Many)

清楚描述發生問題的狀況、影響的狀況:(下面案例是虛構舉例,勿對號入座) 

 

 發生狀況

人:程式師

事:技術規格無法確定

時間:造成專案延遲兩周 

地點:無。

物:無。

 

影響狀況

人:主管和人員產生壓力

事:影響到整個專案進度

時間:延遲時間往上遞增

地點:無。

物:無。

 


2.問題分析。

 2-1.分析出問題背後的真正原因是出在哪邊?

工具:人、機、料、法、環分析法

人員組織:能力經驗不足

機器設備:無

原料材料:無

方法制度:公司無知識或經驗可傳承

軟硬體環境:公司無解決方法僅是不斷給予壓力

   

2-2.深入原因找出原因後面的原因,直到根源。

工具:尋找要因

 

這個表格要解釋一下了。

第一層的原因背後的原因是因為[第二層]的原因(二次因)。

二次因又可能是三次因或是其他的一次因或二次因造成的。多個箭頭指向的原因,稱為[要因],是造成很多問題原因的核心原因。

因此我們針對最關鍵最核心的問題來處理,就可以打開問題的死結了。



2-3.分析問題的重要性和急迫性。

工具:重要急迫分析表


關於優先順序的欄位,烏陵故意留下空白先不填寫。我們用part 1的windows工具來分析事情的輕重緩急。看官們,如果是您,您如何決定處理的優先順序呢?(如下表) 


  
如果排序的話,大家可能會這樣排定優先順序:

         1.重要且急迫

         2.重要但不急迫

         3.不重要但急迫

         4.不重要且不急迫


但是,管理專家和許多實戰經驗豐富的經理人都會強調順序應該是這樣的:

          1.重要但不急迫

          2.重要且急迫

          3.不重要但急迫

          4.不重要且不急迫

因為,[重要但是不急迫]的事情如果不先處理,最後就會堆積出許多[重要又急迫],最後就會整個失控!

所以,上面那個表格內優先順序怎麼填寫,看官們應該都瞭了吧?



3.提出改善對策。需要進行改善對策的評估。

 3-1.方法提出:列出各種可能可以改善的方法或策略。

 3-2.方法評估:

        *將列出的策略整合到表格中。

        *上方橫向欄位列出評估要點。例如時間、資源

        *進行評分,最高分可設為5分,最低1分。某些重要評估點可加權計分。

工具:改善對策評估表


3-3.方法選定:針對評分最高分的方法擬定執行細節。


         
4.執行改善:按照計畫執行。

5.檢核執行狀況:比對計畫和實際之間的差異。

6.擬定預防措施:

工具:防呆手冊。裡面撰寫著問題或錯誤是怎樣發生的。未來要怎樣才能避免這樣的豬頭鳥事。(這邊沒有範例可讓大家參考。自己想著辦吧)

 

 7.總歸納整理:

 

工具:PDCA


 Plan計畫=> Do執行=> Check檢核=>  Action改善 


這是我們展開工作的基本流程工具(應該說是一種工作的觀念吧?)附帶說明的是,PDCA是管理大師-戴明提出的工具,強烈推薦身為研發人員的看官們K一下戴明大師的書籍。

比對目標管理/績效管理,戴明管理應該更是適合研發團隊的管理方式。


以上工具提供遇到問題的時候,一種有系統有方法的處理方式。各位可以參考斟酌使用。

 


最後,舉個活用[問題分析與處理]工具組的例子來做為本篇的結尾。有兩位研發人員因為要使用哪個開發方式而爭執不休。

烏陵將[改善對策評估表]拿來用,讓每個人客觀分析對方方法的優點,和自己的方法的缺點,並且進行客觀的評分,於是雙方很快地就達成共識...

他們提出的方法都不對,需要用其他方法來處理。

完了。


相關文章

遊戲開發專案管理的管理小工具介紹 Part 2

遊戲開發專案管理的管理小工具介紹 Part 1


 更多烏陵土明的世界觀,討論到關於「遊戲開發」的文章

arrow
arrow

    烏陵土明 發表在 痞客邦 留言(0) 人氣()