這是前一陣給團隊培訓，提高團隊工作績效時寫的。
四個原則：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產品？直接從**資產裡拿些出來，組合組合即可。分解的要點就是盡量的解耦，盡量的不依賴於實現。
事物的四個特性和四個隔離級別
事物是一條或者多條sql語句組成的執行序列，這個序列中的所有語句都屬於同乙個工作單元，要麼同時完成，其中如果有乙個失敗，則其他操作都要回滾。事物是乙個不可分割的資料庫邏輯工作單位，要麼全部完成，要不失敗回滾。事務執行的結果必須使資料庫從乙個一致性狀態變到另乙個一致性狀態。乙個事物的執行不能被別的併發...
hive中的四個by
全域性排序，只有乙個reduce 對每乙個reducer內部的資料進行排序，全域性結果集來說不是排序的，即只能保證每乙個reduce輸出的檔案中的資料是按照規定的字段進行排序的 insert overwrite local directory select from table name sort ...
Hive DML中的四個by
使用 order by字句排序 asc是公升序也是預設的，desc是降序實操案例 查詢員工按照工資降序排列select from emp order by sal desc 按照部門和工資公升序排序select from emp order by deptno,sal select from emp...