「效率是以正確的方式做事，而效能是做正確的事。效率和效能不應偏廢，但這並不意味著效率和效能具有同樣的重要性。我們當然希望同時提高效率和效能，但在效率與效能無法兼得事，我們首先應著眼於效能，然後再設法提高效率」——————《有效的主管》
對於乙個企業或者乙個產品研發而言，不可缺少的是效能，而非效率。但是我們太多的時候關注的是效率，《麥肯錫卓越工作方法》一書提到：正確地做事強調的效率，結果是讓我們更快的朝著目標邁進，做正確的事強調的則是效能，結果是確保我們的工作是堅實地朝著自己的目標邁進。效率重視方法，但是效能重視時間的最佳利用。對應到做事上就是首先要做正確的事，然後才存在正確地做事。
有乙個例子就是，在網遊產品的版本更新問題上，員工按照要求作版本，質量，操作都符合標準，沒有事故，沒有任何問題，那麼只能是說他在做一件正確的事，但是如果我們的版本更新後，玩家不買賬，沒有對應的付費使用者群，ib銷售障礙，人氣提公升疲軟，這就不是在作正確的事。也就是說無論你怎麼努力，無論你怎麼表現，方法有多麼正確，結果都是徒勞無益的。
做正確的事不僅僅使方法，還要有一種思想的支撐。任何事要執行很容易，問題在於從戰略意義上怎麼做正確的事，即使我們做的完美無瑕但是最後發現，你的做法最後不產生效益，不產生企業想需要的，那就是失敗的。
最近很多人在問我這個問題怎麼分析，怎麼實現，其實大家過於關注細節，或或許有的人很清楚我要用什麼方法來做和執行，比如使用dm演算法，或者營銷模型分析，而且最後也可以得出結論，然而大家依舊有疑問，這就是因為，你還沒找到正確的事。
我們看到乙個大問題，比如流失率，我們要做的工作就是解決這其中乙個又乙個問題，把這些解決串聯了，就是整個這個問題的解決過程，很多時候這樣乙個問題擺在面前時，問題本身很清楚，解決的辦法也很清楚，但是無論怎麼下手解決，從**開始入手解決，正確的工作方法只能是：「在此之前，請你確保自己正在解決的是正確的問題---很有可能，它並不是先前交給你的那個問題」。
比如對於流失率的研究，巨集觀來講，我們要把握玩家生命週期中的各個階段的流失率（abcde五個階段），也可能專門研究新手玩家的流失率分析（使用者體驗設計指導），也可能是付費玩家的轉化流失率分析（遊戲的收入必然是以流失玩家為代價的），也有可能是沉默付費玩家的流失率分析。
在crisp-dm模型裡面有個最重要的階段，叫做商業理解，還有評估階段，這其實就是在說，做事要確定你做的是什麼，從那裡做，要明確是你要解決的問題是真正要解決的問題，否則比如讓你研究新手流失率，你卻研究付費玩家的流失（活躍那部分），這樣即使你的方法正確，最後的東西不是人家想要的。
放到企業的角度審視，一款產品，我們要明確先在努力解決的問題是真正要解決的，否則即使你做的很多任務作，並且是在對的，但是最終來看從最終的效果上，就會發現，他媽的我做了這麼多的努力，付出這麼多，怎麼就沒有效果呢？
java的效率與效能
今天聽了qpit的關於這次提公升效能的報告，總結了幾點，很好。1 字串相聯接,一定要使用stringbuffer類,而不要使用 2 在對集合進行遍歷時,一般情況下,不要對它進行非null判斷.即在宣告集合時,一定要對它進行初始化.此條不能提高效能,但絕對是乙個良好的程式設計風格,對 結構有良好的作用...
twaver flex效率與效能測試
連線 不建立連線物件 連線 建立一定數量的連線物件 與節點數量比為1 5 測試三 連線 建立一定數量的連線物件 與節點數量比為1 5 測試源 flex paddingleft 0 paddingright 0 paddingtop 0 paddingbottom 0 creationcomplete...
效能測試（效率）
定義 performance testing 測試該軟體在整合系統中的執行效能。大多使用工具測試 目標 度量系統相對與預定義目標的差距。實施 1.效能指標定義明確。2.構造效能測試研究資料。3.構造不同的效能測試場景。4.執行效能測試 一般 90 就通過 5.效能分析。6.效能故障定位。7.效能優化...