周例會
當你看到「會」這個詞時，你可能覺得非常的「不屑」，你也許會想：「又要開會？沒搞錯吧！這就是你的最佳建議？」對此，我們有兩點考慮：
1．雖然我們建議你開周例會，但這只是乙個建議而非強制。每個組織對會議的看法各不相同，這可能適配你的文化，也可能不適配，要具體問題具體分析。
2．增加乙個會議看上去增加了你的工作負擔和組織複雜度，但實際上這類會議，通過強調對目標達成有重大影響的那些關鍵事項，事實上可以簡化和降低你的組織複雜度。一旦你開好了這些會議，你會發現其他會議與之比起來價值甚微，甚至可以從你的日程表中直接劃掉。難道不想嘗試一下嗎？
周例會的目的有三個：
❑ 評估進度；
❑ 在問題爆發前識別潛在風險；
❑ 在使用okr之初，就嚴謹地把okr和基於績效的管理方法整合到公司文化中，以確保團隊持續聚焦。
不要把這個會議當成是對結果的正式檢查。相反，重點應該放在如何分享資訊和促成更有價值的討論上。
以下是周例會的一些建議，時間上應該不會超過乙個小時：
❑ 會前充分準備：尤其是召開會議的團隊成員的級別比較高時，可以首先從確認哪些人參會這一點著手開始這項工作。雖然在過去10年，虛擬會議無論是質量還是數量都提公升了不少，不過有時候還是希望大家能面對面地討論一些重要決定，對一些有爭議的問題進行現場辯論，分享一些關鍵資訊等等，因此事先弄清楚大家的時間安排就很有必要。
❑ 確定工作優先順序：這週的工作重點是什麼？要做哪些事才能讓okr的達成更進一步？正如上面所提到的那樣，人們很容易陷入救火的泥潭而忘了初心，忘記了那些對結果達成最重要的事情，所以明確工作優先順序會幫助大家更好地達成okr。
❑ 狀態確認：我們曾分享過okr專家克里斯蒂娜·沃德克的一條建議，也即當你們制定okr時，將成功與失敗的預期設定為一半一半，這樣在周例會上，你可以再評估一下大家的自信程度：成功概率是提公升了還是下降了？結果是哪個並不重要，重要的是要弄清楚為什麼會這樣。如果你們在穩步推進，你應總結固化經驗以確保這種狀態能持續下去；如果團隊動力不足，就應該討論下如何投入更多資源以確保事情重回正軌。
請記住，團隊的評估是乙個主觀評估即可，這是乙個非正式的評估，不應該讓團隊花費大量時間去收集資料來做這件事。在這裡你只須要認識到，對你而言特別重要的是，要讓你的團隊成員都樂於分享他們在達成okr的過程中遇到了哪些困難，信心是否有增強。如果下屬分享的不利資訊受到上司的指責，那麼久而久之就再也沒人願意說出他們遇到的困難和風險，當這些最終被發現時可能已經來不及補救了。這會給公司帶來**煩！在大家開誠布公地分享訊息哪怕是不利訊息時，你應確保團隊成員敢於把它們說出來。這種做法應該被鼓勵，而不是被指責。
❑ 激發員工敬業度：okr應該要能充分激發大家進行創造性思考，以達成前所未有的高度。然而，挑戰性目標也可能會有***。如果目標達成遭遇挫敗，負面情緒會在團隊中快速蔓延，造成大家開始倦怠。通過周例會可以及時了解團隊的情緒狀態，他們是否仍在積極地去實現目標，還是只是打打嘴上功夫沒有任何實際行動？
❑ 從大局出發：公司應該頻繁地跟蹤健康度量項，因為它代表的是對戰略的成功執行。精心設計的okr最終要能促進健康度量項的達成。為此，可以通過周例會去討論健康度量項的任何進展或存在的問題，以及它們對你當前或隨後幾個季度okr的影響。
如果進展順利的話，當會議結束時，每個團隊成員都應該充分理解了其他同事在下週的關注重點，並提供一切必要的幫助，以確保團隊目標被穩步推進。
如何進行Monkey Test
一 簡介 monkey是android中的乙個命令列工具，可以執行在模擬器裡或實際裝置中。它向系統傳送偽隨機的使用者事件流 如按鍵輸入 觸控螢幕輸入 手勢輸入等 實現對正在開發的應用程式進行壓力測試。monkey包括許多選項，它們大致分為四大類 基本配置選項，如設定嘗試的事件數量 執行約束選項，如設...
如何進行Code Review
code review應該怎麼做 如何高效迅速的進行codereview 下面推薦一些 code review 工具 crucible atlassian 內部 審查工具 gerrit google 開源的 git 審查工具 github 程式設計師應該很熟悉了，上面的 pull request 在...
如何進行CodeReview
規範主要分為風格規範與設計規範兩大類 主要是文字上的規定，看似表面文章，實際上非常重要。具體有如下幾個方面 1 縮排 2 行寬 3 斷行 空白行 4 括號 5 命名 字母 下劃線 大小寫 6 注釋 a 單行注釋 b 多行注釋 c 變數 方法 類 包注釋 牽涉到程式設計 模組之間的關係 設計模式等方方...