IT工程師數位筆記本

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

四個原則：

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產品？直接從代碼資產里拿些出來，組合組合即可。分解的要點就是盡量的解耦，盡量的不依賴于實現。