開會有效率的方式
1. 漫無目的的會議是最令人討厭的。
2. 開會的真正意圖應該是統一認識，查漏補缺，形成結論。討論只是其中乙個不太重要的環節。
不要在會議上去思考問題和發現問題，開會之前這些問題都應該提前發現，並找出解決方案。
3. 開會一定有乙個強有力的有控制力的主持人，這樣能保證不跑題，開會有效率。
這樣開會不會變成聊天的工具。
4. 如果大家意見不統一，或者對某些問題，爭論不定。
看似問題很多，其實問題不多，因為人與人的差距並不很大，只需要讓每個人把自己能想到問題list出來，然後去重，你會發現其實問題並不多，然後一條一條的找出解決方案即可。
更有效率的是，某次會議只解決重合度比較大的幾個問題，其餘問題已經不是問題了。
總結
1. 開會之前要做充分準備。
2. 會議邀請提前預約時間，請用outlook的meeting request，起到提醒與會人的目的。
3. 發出會議邀請時，請附帶agenda和要討論的檔案。
4. 主持人掌控會議進度，杜絕跑題。
5. 整理問題，統一認識，確定核心問題的解決方案。
6. 一定形成結論。
如果形成不了結論，就不要浪費時間，找更有話語權的人來拍腦門實行，實行一段時間後再調整即可。
正確有效率的開發方式
不要急著寫 要先把問題弄清楚。真正的理解需求，與產品一起了解需求是什麼。一般這些產品通常不給足夠的時間來整理需求 他們通常無法提供前後一致或完整的需求意見，文件 要弄清楚其它程式設計師或其它團隊中程式設計師需要那些互動 如介面，伺服器，不同網域名稱呼叫 如何互動 使用白板交流 畫流程圖 uml或vi...
讓決策更有效率
你是否經常有這樣的經歷，在一次會議或者在一次小組討論時，當你提出乙個觀點而被別人否定時，你非常急迫地去反駁別人，從而捍衛自己的尊嚴，而不是第一時間考慮別人提出這個否定觀點的原因。又或者在會議輪流發言過程中，你喜歡自己滔滔不絕得發言，沉浸在自己的觀點中而對別人提出的看法不以為意？或是經常說這樣的話 我...
寫有效率的SQL查詢（I）
1.1where條件的列上都得有統計資訊。沒統計資訊sqlserver就無法估算不同查詢計畫開銷優劣，而只能採用最穩妥的scan 不管是table scan還是clustered index scan 一般情況下我們不會犯這種錯誤 where條件裡不使用非索引列是個常識。索引上的統計資訊是無法刪除的...