工做中任務管理的四個原則和四個技能

這是前一陣給團隊培訓，提升團隊工做績效時寫的。

 

四個原則：

l 瓶頸性任務最優先解決原則

l 高不肯定性的任務優先解決原則

l 前置性原則

l 複雜多變任務的處理原則

瓶頸性任務最優先解決原則

好比說，上面這個任務分解，B、C、F這條線是瓶頸線。是最優先解決的線。

高不肯定性的任務優先解決原則

知足下列兩條之一的任務是高不肯定性任務：

· 困難的、沒有實現方案的；

· 沒法預估完成期限的；

仍是以上面那張圖爲例子，假設A任務是高不肯定性的任務，它可能沒法解決，可能解決須要很長時間。它極可能比咱們計劃的時間要長，從而影響進度。好比說，任務圖會變成這樣子：

因此，這類任務要優先解決。解決步驟以下：

第一步，尋找最小實現方案，若是技術不可行，尋找替代方案；若是技術上可行，作出最小的實現，消除風險和不肯定性，估計徹底解決須要多長時間，將高不肯定性任務轉變爲普通的任務；

第二步，按照普通任務的處理方式來進行優先級排程。

前置性原則

好比說，上面的圖，B是C的前置任務，B應該在C以前解決。

這裏有兩個例外：

（1）若是後置性任務屬於高不肯定性任務，那麼須要想辦法解除後置任務對前置任務的依賴，把它優先處理；

也就是說，若是C任務是高風險、不肯定性的任務，那麼就要想辦法解除C對B的依賴，優先解決C，作出C的最小可行性方案，將它變成普通任務；而後，再按照B優先於C的原則來處理；

（2）若是有多餘的資源或人手，應該想辦法解除後置任務對前置任務的依賴，將這個任務儘可能的和前置任務並行處理；

複雜多變任務的處理原則

對於複雜的任務，需求可能發生變化的任務的處理是項目管理的難點。這種處理的原則是：

產品層面多溝通！！多溝通！！多溝通！！這種狀況下，聊天比寫代碼重要！！

技術層面多分解！！多分解！！多分解！！分解成不一樣的模塊，經過模塊組合來實現需求，當需求發生變化時，換一種組合方式就好了，或者換一個模塊就好了。切忌整個代碼都是鐵板一塊！！這樣，需求一變，會改不少不少東西！！

 

四個技能

l 溝通

l 解除依賴關係

l 最小實現方案

l 分解

溝通

溝通很重要，尤爲是對複雜性任務，越複雜的任務越須要溝通。

這是解決複雜性任務的必備技能！

溝通也不簡單，有可能三我的討論一件事情時，最開始20分鐘，三我的感受討論的都是一個事情，隨着討論的深刻，20分鐘以後，忽然發現，三我的談的表面上是一個事情，實際上心中所想的互相之間有很大區別。

多聊天，多畫原型。

解除依賴關係

解除依賴關係，將不能並行的任務變成能夠並行的任務，這是縮短項目時間的必備技能！

若是有多餘的人手，想辦法解除任務之間的依賴關係。

假設甲作A任務須要2天，乙作B任務須要3天，A任務是B任務的前置條件。若是不解除依賴關係，那麼項目得5天作完。解除依賴關係後，就只須要3天。

最小實現方案

用最快的時間，實現最小實現方案，來評估高風險任務的可行性、所需人手和時間。

這是解決高風險任務的必備技能！

分解

把一個功能分解成更細的功能，這是進一步提升工做績效的必備技能！

就像電腦同樣，需求變了，換個零件、換個外殼就解決了。若是全是鐵板一塊，那就麻煩大了。另外一點，軟件代碼的重用成本幾乎爲零，分解以後，這些就變成了代碼資產了，須要A功能？須要B模塊？須要C產品？直接從代碼資產裏拿些出來，組合組合便可。分解的要點就是儘可能的解耦，儘可能的不依賴於實現。