為什么工程師的效率有那么明顯的波峰波谷?負面情緒與工作效率有什么關系? 團隊 Leader 應該怎樣保證整體的效率輸出與大家的成長?為什么醉心于技術的同學做項目總是虎頭蛇尾?

對工程師來說經常會有明顯的效率差異，有時一天能搞定好幾個模塊，順帶加了好幾個新的技能點，而有時一個簡單的功能投入了兩三天還和之前沒什么區別。雖然任務并不復雜，但忍不住會刷會微博，聊會 QQ，即使硬著頭皮去做，往往效率也不如意，甚至引入一些新的低級 Bug。這個差異與技能水平和工作態度無關，在絕大多數工程師身上都會看到。

一、焦慮，執行力崩潰，GTD

當任務單一時大家的效率往往很高，例如『今天下班前只提供一個用戶獲取接口就行，傳入城市編碼，分頁返回用戶』，這個對絕大多數同學沒什么心理負擔。但現實情景不會這么簡單，尤其是在創業型公司，每天會有各種任務，可能運營一會會要一份數據，產品一會報一個 Bug，或者老大又提了幾個新的優化點，這些任務單個來看工作量不大，但是持續而無序的任務到達一個工程師身上時，完全可以摧毀他一天的效率和心情。尤其是研發需要注意力集中，頻繁的任務切換會浪費大量的時間和精力。

在 GTD(Get Things Done)中對此有闡述『壓力不是來自于任務本身，而是任務在大腦中的堵塞，帶來的焦慮和心理的抵觸』。當一件任務還沒有完成時，持續到來的新任務會帶來很大的心理壓力，意志不夠強大時，很容易導致執行力崩潰，進入一種任務怎么做都做不完的絕望狀態。

知道原因了，自然也有解決方案，GTD 提供了一套很可行的執行方案。簡化后如下：

1.把任務放在 『待歸類』『今日待辦』『日程』『等待』幾個盒子中

2.收集：每次收到新任務先做一個判斷，如果這個任務5min 可以搞定的話直接干掉，否則都放在『待歸類』盒子里。

3.整理：每天開始的時候從『待歸類』盒子中開始過濾任務，挑出來今天需要做的3件事，放進『今日待辦』。如果今天不需要做再根據有沒有明確的執行時間，放入日程或者等待盒子里。

4.執行：只盯著『今日待辦』即可，再有新任務執行 收集步驟。

5.回顧：定期整理自己的『日程』『等待』盒子。

這套解決方案能將雜亂地任務明確下來，一定程度上減輕心理壓力。

Tools：符合GTD 的時間管理工具很多，Doit.im 是其中的佼佼者，全平臺覆蓋，強烈推薦。 Omnifocus 則是功能最強大的，支持無限級目錄等功能，不過只支持 Mac/iPhone/iPad，且價格不菲。 也可以使用印象筆記/OneNote來自己規劃管理，這樣相對靈活。

上面說到的是在任務壓力面前個人可以做什么，那作為公司/項目經理/產品經理，也需要為避免『執行力崩潰』做一些事情，那就是保持開發的節奏。 二、節奏，情緒的體力值

第一次聽到『開發的節奏』是在微博的Scrum項目流程培訓上，這個概念解釋了以前大學時我們學生外包團隊遇到的諸多問題。 簡而言已，可以給每個人的情緒量化出一個體力值)。每個開發任務/每個會議/每次報告 都會消耗這個體力值，當體力透支時，后面可能會需要幾天不等的時候來恢復體力(我們說的恢復干勁也是這個東西)，當透支次數過多時，可能會引發更惡劣的情緒問題。

所以一個健康的團隊需要維持開發的節奏，具體操作可以是 每1-2周為一個周期，進行大的項目規劃，研發任務占用時間最好不高于80%，之后每個人能有休息/自我充電的時間，在下個周期開始時，團隊又能進入滿體力值的狀態。

具體到我現在的團隊，我們以一周為一個單位，每周一產品經理提完本周的需求，我們進行分工消化后，存進需求系統。這周的其他時間內，產品應最大量減少對開發的干擾，下周一的時候對上周的任務進行回顧和總結。 這套方案起到了一定的效果，團隊成員沒有明顯的疲憊感，每周能自由支配一些時間(任務能早早完成的話，自由適配時間更多)。

Tools：團隊的需求管理系統 我們先后試過 Onenote多人協作/ Teambition / Team.oschina /c禪道，但普遍不理想，或者功能太復雜，或者無法同時集成 Bug 系統，目前采用的是開源的 Cynthia，Cyntia也是我們團隊的Bug管理系統。 具體工具的選擇有時間單拉一篇 Blog 來講

三、情緒

影響效率的另一個問題是情緒，情緒問題危害很大，最直接的在于：

1.情緒很容易泛化：單一誘因導致的問題會影響各個方面：工作積極性，工作效率，工作質量等等

2.情緒很容易傳染：小圈子內，情緒很容易傳染(QQ 群功不可沒)

3.情緒不好消除：后面會看到，導致情緒的問題多是之前小問題的日積月累，或者就是現階段不好解決的問題。

1.研發節奏過于緊湊：在上一節中提到當開發的情緒體力持續透支時，會有惡劣的情緒問題。 這個在開發團隊中并不少見。當開發節奏太過緊湊，團隊不注意休整時，團隊很容易負面情緒彌漫，而情緒一旦形成印象，便不會那么好消散。

2.薪酬倒掛：這個也是大家詬病 HR/Leader的重要原因，當一個團隊薪酬內部增長太乏力時，內部人員會有流出，團隊需要再招聘新人，而市場上平均待遇已經和之前不同，所以新招來的人員待遇往往也會水漲船高。 這個是很致命而且不好消解的。HR 太過節約成本，往往會對團隊有致命的傷害。

3.與 Leader 理念/習慣 不合。

4.工作內容安排不當，太困難或太簡單，或者與職業發展規劃不符。

5.純粹發泄。

6.......

情緒問題暴露后，也不是不能解決，有明確的訴求時直接去解決問題本身。沒有明確訴求的可能是抱怨性格或者與公司方向不合，那也無法強求。

而真正可怕的是團隊 Leader(或者需要對這些問題負責的人) 對團隊本身情緒的不知情。當大家私密的 QQ 群/討論組 都沒有你，聚會也沒有參加，不會有什么真心話交流，只有工作上例行的接觸時，就已經是挺危險的信號， 成員離職時再去尋找原因已然太晚。

4. 糾結的Leader

Leader 這個詞并不是太貼切，這個職位的職責應該是服務團隊的開發同學，找到并解決大家開發不爽的地方，做好技術和業務的架構，保證整體研發輸出的質量和時間點。

而且 Leader 其實并不容易當. 要獲得工程師的尊重, 需要滿足下面一項或多項

1.技術過硬，能解決團隊遇到的各種技術問題。

2.情商逆天，有能力和意愿感知團隊成員的情緒,并能不斷給積極的反饋, 團隊保持很強的凝聚力。

3.資歷深厚，業內有影響力或者披荊斬棘創下了公司的基業，能為團隊爭取到資源。

而在沒有得到工程師的充分尊重前，各種措施的執行都會收到影響，技術決策的討論更得充分尊重大家的意見。

5. 技術驅動

技術驅動業務是產生顛覆式創新的動力之一，工程師更清楚技術的邊界在哪里，哪些情景已經可以被成熟(或者半成熟，但可駕馭)的技術方案來解決了，這些會把公司與競爭對手拉開一個或者半個技術時代，輸出更酷炫的產品。

這個時代對于工程師來說是最好的時代，Github等開源社區的興起，讓新技術的學習成本變得很低。數據挖掘，自然語言分析，圖數據庫，數據可視化，虛擬化，移動互聯等技術的發展更給業務帶來了無限的可能，而美國市場與中國市場還存在5-10年的時間差，也為我們提供了很多可以參照的模板。

技術驅動有更多實際可以做的事情，放到二手車行業，例如當其他產品靠用戶自己填購車需求時，你實現了通過用戶的行為軌跡挖掘用戶的需求;當其他產品還是幾張圖片來展示車況，你實現了低成本的全景照片，當其他產品還在要經銷商自己維護關系時，你通過圖數據庫計算出了他可能的朋友圈...

那么問題來了，應該如何推動產生更多的技術推動型的產品呢

1.寬松的學習氛圍：技術驅動型一般借助于相對前衛的技術，大多數同學對這些技術都沒有多少經驗，依賴于持續的學習，而學習就需要有學習的氛圍，尤其是時間的保障。

2.優秀的工程師：技術驅動對工程師的自我實現需求要求的更高，只想完成現有任務不想多事的工程師顯然不合適。

3.技術與業務的結合：最理想的是工程師本身有商業思維，能夠主動將新技術與業務結合起來，尋找最大價值的結合點;其次是工程師定期宣講技術成果，與產品同學共同討論。例如：『我們已經將20萬經銷商數據全部存入圖數據庫，支持寬度遍歷，深度遍歷這些查詢方式，他們的時間復雜度是O(n+e)』 『我們可以對這幾十萬條評論內容進行分析，分辨出褒義還是貶義，還可以匹配上我們數據庫中的品牌車系，準確率能有60%』

技術驅動也有一些硬傷，或者說工程師同學主導項目時都很容易出現的硬傷：優先級，時間點，任務管理。

優先級：醉心于技術的同學會被問題本身吸引，例如『MongoDB 還支持數據分片，那我搭個集群試試』『我試試這里能不能承載1w qps 的壓力』『雖然我正在看 iBeacon，但是 Ardunio 也好酷哇，我做個Demo先』等等， 在這種吸引下，工程師很難對套頁面，修數據這種任務感興趣，而這些對項目來說優先級可能會更高。(心理學中也有類似結論，當難度降低到一定程度，動機的強度也會降低。)

時間控制：同時因為要使用的很多是大家沒用過的技術，技術本身可能不成熟，大家經驗也不多，有時候一些坑要好長時間才能埋上，這樣固定的時間點很難保證產出。

任務管理：許多熱衷于解決問題的同學同時也是挖坑小能手，他們能預見一種更優雅的解決方案，但是沒有時間和精力去完成，在這個過程中還挖了更多新的坑，于是這些坑一直沒有時間埋...

也因為以上幾個原因，我們會發現很多醉心于技術的同學在做項目時會出現虎頭蛇尾，總也結束不了的樣子。 這種情況需要技術同學自己注意每月確定團隊的大方向，定期匯報，發周報或者半月報。

如何提高個人與團隊的效率。是會伴隨行業發展長久存在的問題，每個團隊都要去尋找自己的答案，大家一起努力。

PHP100為您推薦更多與程序員效率相關的優秀文章：《提高程序員工作效率的5個工具》、《關于程序員的工作效率(絕對干貨!)》、《22條日常技巧助程序員提高工作效率》，希望這幾篇文章的工具和小技巧能幫大家保持良好的工作效率，進入高效的工作狀態。

一說大數據，人們往往想到Hadoop。這固然不錯，但隨著大數據技術的深入應用，多種類型的數據應用不斷被要求提出，一些Hadoop被關注的范疇開始被人們注意，相關技術也迅速獲得專業技術范疇的應用。最近半年來的Spark之熱就是典型例子。

一說大數據，人們往往想到Hadoop。這固然不錯，但隨著大數據技術的深入應用，多種類型的數據應用不斷被要求提出，一些Hadoop被關注的范疇開始被人們注意，相關技術也迅速獲得專業技術范疇的應用。最近半年來的Spark之熱就是典型例子。

Spark是一個基于RAM計算的開源碼ComputerCluster運算系統，目的是更快速地進行數據分析。Spark早期的核心部分代碼只有3萬行。Spark提供了與HadoopMap/Reduce相似的分散式運算框架，但基于RAM和優化設計，因此在交換式數據分析和datamining的Workload中表現不錯。

進入2014年以后，Spark開源碼生態系統大幅增長，已成為大數據范疇最活躍的開源碼項目之一。Spark之所以有如此多的關注，塬因主要是因為Spark具有的高性能、高靈活性、與Hadoop生態系統完美融合等叁方面的特點。

首先，Spark對分散的數據集進行抽樣，創新地提出RDD(ResilientDistributedDataset)的概念，所有的統計分析任務被翻譯成對RDD的基本操作組成的有向無環圖(DAG)。RDD可以被駐留在RAM中，往后的任務可以直接讀取RAM中的數據；同時分析DAG中任務之間的依賴性可以把相鄰的任務合并，從而減少了大量不準確的結果輸出，極大減少了HarddiskI/O，使復雜數據分析任務更高效。從這個推算，如果任務夠復雜，Spark比Map/Reduce快一到兩倍。

其次，Spark是一個靈活的運算框架，適合做批次處理、工作流、交互式分析、流量處理等不同類型的應用，因此Spark也可以成為一個用途廣泛的運算引擎，并在未來取代Map/Reduce的地

最后，Spark可以與Hadoop生態系統的很多組件互相操作。Spark可以運行在新一代資源管理框架YARN上，它還可以讀取已有并存放在Hadoop上的數據，這是個非常大的優勢。

雖然Spark具有以上叁大優點，但從目前Spark的發展和應用現狀來看，Spark本身也存在很多缺陷，主要包括以下幾個方面：

1.穩定性方面，由于代碼質量問題，Spark長時間運行會經常出錯，在架構方面，由于大量數據被緩存在RAM中，Java回收垃圾緩慢的情況嚴重，導致Spark性能不穩定，在復雜場景中SQL的性能甚至不如現有的Map/Reduce。

2.不能處理大數據，單獨機器處理數據過大，或者由于數據出現問題導致中間結果超過RAM的大小時，常常出現RAM空間不足或無法得出結果。然而，Map/Reduce運算框架可以處理大數據，在這方面，Spark不如Map/Reduce運算框架有效。

3.不能支持復雜的SQL統計；目前Spark支持的SQL語法完整程度還不能應用在復雜數據分析中。在可管理性方面，SparkYARN的結合不完善，這就為使用過程中埋下隱憂，容易出現各種難題。

雖然Spark活躍在Cloudera、MapR、Hortonworks等眾多知名大數據公司，但是如果Spark本身的缺陷得不到及時處理，將會嚴重影響Spark的普及和發展。