本文由 dbaplus 社羣授權轉載。
大家好，我是快狗打車的產品技術設計團隊的負責人沈劍，可能很多人通過“架構師之路”認識了我。在這些年裏我身上肩負着架構師和團隊領導者的身份，完成了不少系統的產品設計，也從一線管理者晉升到現在整個產研團隊的總負責人。
其實在這個過程中需要設定很多目標，包括團隊的目標、業務項目的目標和技術項目的目標。今天分享主要集中在讓大家瞭解，作爲一個管理者或項目經理可以通過哪些方法和工具去達成既定的目標。
如果你是一個團隊的負責人，或者未來也希望成爲團隊負責人，又或者你正在帶領業務和技術項目、正在參與項目且未來希望能夠帶領項目，那麼我希望通過今天的分享能夠幫助大家解決以下三個問題：
- 如何達成既定目標；
- 如何制定計劃；
- 實現團隊目標。
前言
在開始分享前，我在這裏先拋出兩個問題：
- 管理者的職責是什麼？
我的理念是，作爲一個管理者在面對上級、同事和下屬的時候職責都是不一樣的。
面對老闆，我們必須完成給定的業務目標或者項目目標；面對同事，我們就要爲隊友賦能；而面對下屬，我們不僅要幫助他們解決問題，還有幫助他們成長和提升，也就是幫他們搭舞臺唱戲。以上是我認爲，作爲一個管理者要盡到的核心職責。
然而究其根本，管理者的職責其實是實現自己承諾的目標。面對老闆就是要實現承諾的業務目標，對同事是實現對合作的承諾，對下屬則是對你實現承諾的方法和資源。管理者並沒有擁有很大的權力，多大程度上實現了承諾過的目標纔是崗位價值的體現。分層次說的話，CEO要實現自己對業務總體目標的承諾，CTO要實現對產研項目、產品系統交付的承諾，而總監經理要實現對交付質量、技術體系建設、組織能力建設的承諾，員工也要實現對自己在項目、在系統中負責的穩定性、迭代、效率和質量的承諾。
我們對管理者基本的要求，就是實現自己承諾的目標 。如果目標沒有達成，那這個管理者就是不合格的。
- 管理者如何實現目標？
達成目標的要素有老闆的支持、清晰的目標、下屬的能力、到位的監督等等，可能每個管理者實現自己目標的關鍵要素都不一樣。
回想一下，我們在做項目的過程，是不是先定下項目目標，然後是項目負責人，接着拆解、監督跟進、風險評估和改進、過程改進？這個流程可能大家沒有一個系統的說法，但它就是使用計劃管理去實現目標的。整個定目標、做計劃、行動、覆盤、調整行動、達成目標的過程其實就是計劃管理。特別是在效率交付這個方面，對負責的相關研發部門來說，計劃管理極其重要。
一、什麼是計劃管理
1、計劃管理
要做計劃管理，那就要先說說什麼是計劃。計劃就是目標及一步步實現目標的步驟。想看一個企業做得好不好，帶領一個團隊帶得好不好，我們要重點看其是否養成了做計劃的習慣，因爲做計劃是一個主動規劃的過程。
但是很多人會說：“很多時候我只是被動地被安排工作啊，老闆讓我做什麼我就做什麼。”
被動安排工作，很可能是你的老闆在做計劃而你只是執行他的計劃。很多的時候，業務變複雜了，團隊也擴張了，很多管理者就不會做計劃了，或者做好的計劃就亂套了，這樣對項目推進有很大的影響，所以我們必須養成做計劃的習慣。
計劃管理是我們做一切管理的基礎，是達成目標的一個工具。
2、流程管理
我們知道做產研項目的項目流程是提需求、接需求、需求設計和評審、研發設計和評審、研發鏈條測試上線部署。
那麼流程管理能解決什麼問題呢？重點解決的問題不是說哪個人在哪個環節進行審批，而是大家的分工問題。我們要知道整個流程需要哪些崗位來配合工作，藉此設置產品、研發、測試和運維的崗位。流程管理是用來確保人人有事做，事事有人做，並且在整個項目、業務流程中，每一個崗位都是明確的。
3、組織管理
組織管理的內容是確定權責，它主要解決了負責人必須有權，有權的人必須負責的這個問題。
在實際落地的管理工作過程中，如果推進流程清晰、崗位分工明確，那麼組織管理的工作就會比較少；反之如果推進流程模糊、崗位分工也含糊，那麼管理者就需要投入大量精力去解決關於流程的問題，去解決組織上需要權責清晰分明的問題。
實際工作中，花費在流程管理和組織管理的時間還是比較少的，更多的時間用在計劃管理上，需要做好設定和達成目標的工作。計劃管理、流程管理、組織管理分別解決不同的問題：
- 計劃管理， 解決設計計劃、明確目標、合理分解任務和達成目標的問題；
- 流程管理， 解決流程和崗位要清晰，人人有事做，事事有人做的問題；
- 組織管理， 解決權責問題，確保組織合理，做事的人有權、有權的人承擔責任。
這是基礎管理最重要的三項內容，如果你要做更高階的管理，往總監、VP、CTO的方向走的話，那麼在管理工作中你還需要思考高階的管理，比如說戰略管理，我們要建設怎樣的能力，又比如說文化管理，我們如何能夠持續地建設能力並且在各個方向上文化都擁有戰鬥力。
計劃管理是我們做好一切的基礎，是達成目標的方法。 做好計劃管理，基本上你就是一個80分的一線或者二線管理者。
二、計劃管理最佳適用範圍
問題：銷售的目標是一個需要達成的銷售額，銷售額按月度考覈，有的時候目標達成了而有的時候沒有，那麼我這個月需要怎樣制定怎樣銷售額度。以上算不算計劃管理？
答案：不算，這個例子更偏向於績效管理。
對於直接爲業務結果負責的部門，會特別注重績效管理。但是對於不直接揹負績效管理指標的部門，績效管理就不是這個部門的管理者最關注的的事情。像是最典型的研發部，它們爲交付服務而存在，是一個注重效率的部門，要求快速、高質、高效地交付產品和系統。
計劃管理適合關注效率而非績效的部門。 對這樣的部門來說，其核心管理方法論就是計劃管理。
還是典型的例子，對技術部門來說，他們的主要職責不是技術驅動業務的部分（少數公司例外），更多的是爲交付而負責，確保高質量、高效、安全、低成本地做系統交付，十分注重過程和效率。所以計劃管理非常適合像研發這樣的團隊去做管理。
三、計劃管理也是一個過程管理
有一些團隊拍着胸脯說：“你就不用管啦，我季度末給你結果！”
這不算過程管理，它雖然有目標有結果，但是卻沒有關注過程，所以它其實就是績效管理。像這樣“不用管，到時候保證給出結果”的情況在很多公司和團隊中都存在，這種管理方式極其容易出現管理失控。
結果團隊，例如銷售的KPI管理的review週期比較短，通常以周或者月爲維度來review銷售結果，這嚴重依賴個人能力而不是制度或者流程。過程管理運用到研發團隊身上的話，績效考覈一般來說粒度更粗，以季或者年爲維度review結果，也就不大會出現“拍胸脯”的現象，以避免管理失控。
既然計劃管理是一種方法和工具，想要做好管理就需要去多學習、多練習。那麼如何培養好好的管理習慣？大家回想一下自己的編碼習慣是怎麼培養出來的，應該就是通過不斷寫代碼而訓練出來的。所以類比一下，對於計劃管理也是一樣的，我們需要養成做計劃的習慣，刻意訓練自己運用這種管理方式的習慣。
舉個例子，比如我負責58到家的技術部，而且在2020年有一個“提效、爲效率負責、爲項目交付吞吐量負責”目標。首先我會和技術團隊解釋我們有這樣的目標是因爲它與我們的職責相關，然後明確目標的內容是“本季度或者本年的交付吞吐量要提升到20%，線上線下bug要降低多少”等等。
其實這就是要向你帶領的團隊明確我們 爲什麼做、做什麼和怎麼做 ，以及其他細節：
- 爲什麼做？ 爲了提高效率；
- 做什麼？ 建設技術體系；
- 怎麼做？ 討論現在效率的瓶頸是什麼，找出項目流程中的主要矛盾到底是需求評審階段、項目設計階段、研發階段、鏈條階段還是上線階段。哪個過程最耗時間，如果是需求評審階段很低效，產品沒想清楚，那麼我們這個季度就會主要抓這個部分來提高效率；如果是上線階段，我們沒有好的工具和平臺，都是依賴於人肉，整個過程都是主要矛盾的話就重點抓這一塊；
- 時間節點？ 季度；
- 負責人？ 我，沈劍。
四、計劃管理五要素
看完之後其實會發現，上面說的 做什麼、爲什麼、怎麼做、時間節點、責任人 這些要素，不管是帶領團隊做產品項目、業務項目還是技術項目，在計劃管理中就是最重要的五要素。爲了方便大家記憶，計劃管理五要素可以記成“他問我爲何”，也就是 Target、Why、When、Who、How（TWWWH） 。
1、 T（Target）：
- 首先設定好目標；
- 其次這個目標必須承接戰略和部門職責，比如說部門職責是提高效率、高質量、低成本、安全地交付。目標必須和職責相關。爲什麼要建設技術體系，一定是更高效、更高質量的和交付相關的。
2、W（Why）：
- 項目成立原因，比如研發團隊的職責相關，所以要提高效率、建設技術體系、改進上線流程、改進產品協作流程等等；
- 這個點是負責人和管理者在做計劃、傳達的過程中最容易忽略的一個點。很多時候我們只跟大家同步業務目標和結果、項目目標和結果，但是沒有傳達爲什麼要做這件事情，這就導致了很多員工執行不到位。是因爲他們在做這件事情的時候，本身就不認同這件事情的目標，也不知道爲什麼要做；
- 比如目標是技術體系建設，有些運維人員會覺得自動化運維工具會取代自己的崗位，他不認可這個目標。但是這個工具在平臺建設中和部門職責息息相關，是必須要完成的事情。所以，在傳達的時候要解釋清楚這個工具會幫助運維團隊提高工作效率，讓他們有時間專注在其他關於自動化的工作上，而不是不斷重複上線操作。這樣，一旦他們認可你的目標之後，執行計劃和配合工作纔會更加順暢。
3、W（When）：
時間點很重要，比如本季度或者今年要提升多少；
- 如果你說今年要完成5、6個項目，員工聽着就會覺得時間粒度非常粗且不可控，會導致他們完成的信心指數非常低。如果把這個時間節點進一步細化和拆解，今年要完成5、6個項目，其中容器化項目實現需要12個步驟，並且每個動作需要1個月來完成。這樣將時間點做了細緻的拆解，聽着相對可控，員工對於完成這個指標的信心指數就會比較高。又比如說這個項目需要2個星期上線，時間粒度粗所以項目風險也高，如果你說項目需要研發幾個接口、每個鏈條和自測需要多長時間，時間拆解越細，老闆對你完成這個計劃的信心指數就高；
- 對於時間這一塊想要強調的是，在做計劃時儘可能將時間粒度拆解得細、最大程度明確動作，這樣老闆看完你的計劃之後信心指數比較高，會覺得項目交給你之後他就不需要實時和你同步項目，他可以把精力放在別的項目上。
4、W（Who）：
在計劃和管理中，責任人要對整個項目負責；
- 項目成功，就要獎勵；項目失敗，責任人就需要對項目負責。
5、H（How）：
- 分解、實施、review、覆盤、改進行動計劃以達成目標；
- 需要完成計劃、明確目標、上傳下達、提高老闆信心指數；
- 舉一個很粗粒度的例子，2019年我負責58到家的技術中心，當時老闆向我提了一個要求，就是要提升團隊的效率。提升團隊的效率是在明確職責的前提下，相同的事情能夠讓更少的人去做，或者是人數不變的情況下承擔更多的職責。我會首先，按季度粗粒度地將計劃進行拆解：
- Q1： 在架構側、中臺側、基礎服務側和企業平臺側，可能要做效能的提升；而運維側和IT側可能需要成立虛擬的組織，讓更少的人能去做更多的事情。Q1要成立一個創新的部門，去做一些創新的事情，Q1可能只完成了一部分，等我把這一塊拆解之後，就把這個目標給相關的總監，由他做更細化的拆解；
- Q2： 可能有兩個部門的人效比較低，有人員的汰換或者質量部、效能部的重組架構調整，那我Q2主要抓這一塊的矛盾；
- Q3： 有些部門反饋到數據部，覺得效率比較低，那麼就要對大數據進行調整。同時創新的方面，又孵化出了一個保險業務；
- Q4： 我做了一級的拆解之後遞歸給下面的總監和經理做二級的拆解，可能最終年效提升了10%，節省40%的人完成過去相同的工作，又或者在人數不變的情況下，我還孵化了兩個創新的產品。
- 我必須確保在我的管理範圍內，所有人都知道我們的年度總目標是什麼、爲什麼要做、計劃是什麼、每一塊的負責人是誰、初步的規劃怎麼做。
大家可以想想，你們的團隊是否明確了今年整個技術部的目標，或者你們部門是否明確了目標，又或者你們最近一個項目的目標是什麼。你的團隊人員究竟是清清楚楚，還是簡單地被分配和執行工作。
如果他們對目標不清楚或者不認可這個目標，在執行的過程中就很有可能出現很大的阻力，也會有很多的問題。
還有就是，你們到底有沒有和他們討論怎麼做。很多人會這樣說，“人效要提升40%”，那你沒有具體拆解過的行動計劃，如果沒有那最後就是靠天看這個目標能不能達成。
有沒有負責人和明確的時間點，在怎樣的時間節點要達成怎樣的目標。
所以TWWWH（他問我爲何），目標、爲什麼、時間節點、負責人、怎麼做這五項因素在做計劃管理中非常重要。
五、計劃管理核心討論什麼
1、怎麼做很重要
計劃管理最核心應該討論：怎麼做。
舉個具體的例子，比如我所負責的快狗的技術中心的部門，Q2的項目吞吐量中一個效率指標要提升30%。我們初步定的目標是30%，挑戰點的目標是50%，其實我們並沒有花多大的精力去討論目標是30%還是50%。但是很多同學在做計劃的時候會很精細地計算到，“我要提升15%，我算過了，做A可以提升5%，做B可以提升5%，做C和做D可以提升5%，所以總體可以提升15%。”
我不知道大家在定OKR的時候是不是這樣細算出來的。我們知道，制定OKR的時候要制定有挑戰的目標，而且最好50%概率能夠完成，也就是跳一跳能夠得到的目標。
所以你要把效能提升30%還是35%還是50%，其實沒那麼重要。甚至很多業務，你問他的業務增長目標是怎麼做出來的，這很有可能就是老大拍板的。
怎麼做非常重要，在做計劃管理的過程中我們應該把時間放在討論怎麼做上面，重點應該討論行動計劃的制定。
我們重點需要花時間去想，執行中可能會有的潛在困難、這些困難的解決方案，再配合定期的執行、校驗和行動計劃的更新。
2、如何覆盤
定期的執行和檢查，我也不知道大家會不會定期覆盤項目，你們的項目覆盤會怎麼開，重點說什麼，但你們想一想是不是下面這個樣子：
首先擺數據，我們訂單增長了多少、效能提升了多少、體系化項目進度是多少；然後找原因，解釋這個地方爲什麼沒有達成預期，去做各種各樣的解釋。這是一種非常錯誤的覆盤會。當然找原因是必須的，但是你會發現你找到原因解釋，對後續的改進沒有任何意義，所以覆盤會上要重點討論什麼呢？
要重點討論後續的行動計劃、潛在風險、解決方案和行動的變更。 制定計劃的時候要討論行動計劃和怎麼做，覆盤的時候也要重點討論行動計劃。之前做對了的我們要繼續做，什麼行動要保持，之前做錯了什麼或者什麼沒有做對，我們也要糾偏回來。
但是我參加過很多覆盤會，這些會可能都和追責有關。很多覆盤會做這樣的工作，通篇都在解釋爲什麼這個項目沒有達成預期，不是我的原因而是別人的原因。
我又舉個例子，我對Q2產品效能的提升定了一個50%的目標，最終目標完成了80%。Q2過去之後，我們要怎樣覆盤？
我們做對了什麼？可能是組織架構調整了，目標更清晰了。原來一開會大家都在扯皮，說測試是瓶頸所以要加測試，說前端是瓶頸所以要加前端。我將組織架構調整成相對閉環的部門，業務裏有一個研發小組，包含了測試、研發、前端和後端，那麼原來溝通的成本就降低了，大家都看齊同一個業務目標，背一個業務指標，扯皮就減少了，溝通就更高效了，這樣對項目提升可能有幫助。
最簡單的方法，比如說五、六月份是戰略重心，有幾個戰略項目都要上線。有些老大會說，“這兩個技術團隊的同學辛苦辛苦，週六來衝個刺。”這樣可能團隊多工作一天就提升了20%的效能，但我特別反對長期通過這種方式來提升迭代速度。我們還是要通過優化流程和工具去優化、提升速度。
又像剛剛說到的流程這一塊，在項目流程過程中，原來在需求階段可能存在問題但我沒有改進，所以最終只提升了5個點。
或者說，原來上線都是通過人工，而現在用自動化的上線工具；原來搭建測試環境需要很長時間，現在通過自動化的方式去搭建測試環境，這樣對效能的提升是肯定有幫助的。這方面就需要管理者瞭解當前的主要矛盾，並去解決這些主要矛盾。
如果你覺得人員技能不到位，那你就能要去做培訓；你覺得不靠譜，那你就要做汰換。反正到了季度末我們覆盤的時候，做對了的事情在下個季度就繼續做，做錯了的事情就要停止做，能夠繼續迭代的空間，我們就要去優化。
在計劃管理的過程中，大家要多花時間去討論行動計劃，在覆盤中討論做對了什麼、行動計劃要改變什麼，而不是單純的質量和數字，以及解釋、推脫或者甩鍋，這樣對後續達成目標沒有什麼幫助。所以我想表達的是，花時間的重頭戲應該是制定行動計劃。
六、計劃管理的兩大特點
1、目標不合理性
前面提到了怎樣的OKR是好的OKR，如果你達成的概率是50%，50%概率不能達成，這個目標跳一跳就可以夠得到，那這樣的目標是好目標。
再舉一個例子，Q2有一個項目是IDC或者叫集羣，快狗側可能有幾百個集羣原來做了過度的設計，微服務化拆分出了太多細粒度的服務，導致維護起來成本很高。那我們說Q2可能要做一些集羣的合併和架構的優化。
當時項目有一個負責人，我讓他提一個目標，他糾結了很長的時間，說我不知道集羣要減少10%，還是15%，還是8%。但其實你會發現，不管這個值是多少，後面重點要花時間去討論的是行動計劃、怎麼樣合併集羣、架構怎樣更合理、以什麼樣的節奏去執行。其實目標是10%還是30%，和後面討論的行動計劃是沒有關係的。所以後來我就說，那我定下20%這個值，然後Q2就按照這個目標去走，看Q2能不能達成20%的OKR。
OKR和KPI不一樣。KPI達成與否跟你的漲薪或者跟你的績效有關，但是OKR指定的是有挑戰的OKR，所以你的leader一定要綜合實現難度係數去打分。雖然說我拍了一個目標，但是因爲我是一個技術專家，所以我在拍的過程中是有所謂的專業手感的，我並不是瞎拍的。
我實際是想了一下，20%的目標去做工作有一定的挑戰，但就是能夠實現的。在這個拍目標的過程中，能夠體現我的專業手感。在一個專業領域裏浸淫久了，拍目標的時候其實能夠體現專業手感，IDC減少多少、效能提升多少、訂單增長多少更合理，這些都能夠體現你的專業手感。
總之，計劃管理有一項特點是目標不合理，因爲目標本身是一個預測，目標要符合戰略的要求，而且目標更重要的是體現你對某一部分的決心。很多時候項目目標定下來了，團隊管理反而簡單了。有些團隊之所以不出成果，是因爲花了大量時間放在目標討論上，而且在制定目標的過程中往往也提出了很多困難，去強調達成目標非常有挑戰，並持續降低自己的目標，直到目標降低到自己有把握的程度。這個不是OKR，也不是計劃管理。OKR不是在制定目標的時候有大概率能完成的感覺，而是一個有挑戰的目標。
未來也希望大家在做計劃管理的過程中，能夠制定一個有50%概率能夠完成的目標，這就是一個好的OKR目標。目標在制定的過程中也能夠體現你的專業手感，所以如果你讓一線的同學來這個事情會更不靠譜，因爲一線的同學更多思考自己怎麼才能不出錯，所以你讓他去定目標，一定是自己能夠實現的。他們關注的更多是自己，可能不是業務或者公司的壓力。
我們作爲leader，有一項非常重要的要求，你要同時具備內外部視角。外部怎麼看問題，你的老闆希望你能達成什麼目標。而很多一線的員工可能缺乏外部視角，他們可能更多思考的是做什麼能夠不出錯，所以我要制定一個我能夠完成的目標，這樣我就能拿到獎金。這就是典型的KPI或者自我的思維。
計劃管理的第一個特點，也是不必花太多時間精準地制定目標。很多時候大家精準地討論目標，就會強調這個事情有多難、多有挑戰，會持續地降低目標，直到降到一個自己有把握的目標。你想想，這樣對團隊的發展和對業務的發展，都是非常不利的。
2、行動計劃的合理性
行動計劃必須合理，你要花最多的時間在討論行動計劃上。
資源匹配要合理，如果你沒有給我那麼多的預算，我拿不到那麼多的市場費用和流量，你也沒有足夠的研發團隊，那你讓我在一個月之內幹出那麼多系統，我做不到。所以行動計劃的拆解必須是合理的。
下面舉一個例子，快狗打車在做Q2的容器化項目來提升的自動化程度時有一個負責人，負責人是我們這邊運維的總監，目標是Q2整個測試環境容器化全覆蓋。
他就解釋給團隊聽：
- 爲什麼要做這件事情，你要提高效率，跟我們的職責相關；
- 時間節點是一個季度，我們要達成測試環境的覆蓋，他就進行拆解，總共有200個集羣，第一個月要覆蓋80個，第一個星期要覆蓋哪10個集羣完成容器化；
- 每一塊工作繼續拆細，研發和運維團隊要負責哪部分；
- 在季度初，他就做了一個計劃管理，然後在每個月執行的過程中，以月爲單位進行review。上個月我計劃完成三分之一，那我有沒有80個集羣測試環境的三分之一Docker容器化覆蓋？如果項目delay了，我要發現爲什麼項目delay了；如果有一塊技術方案我們想得簡單了，那有什麼解決方案？如果我們後續的行動計劃可能要改變，我們就得加進人手，讓大家更重視或者晚上加一個小時班，這樣去不斷地調整自己的行動計劃，不斷覆盤之前哪一塊工作做得好，做對的要繼續做，做錯的要停止做，迭代優化要繼續改進。
總結
1、 對管理者最基本的要求，是對目標的承諾
你能夠承諾多大的目標，你的崗位就有多大的價值。
大家想一想，你能跟你的老闆舉手說我願意背什麼樣的指標。你這句話承諾的指標，項目、系統、團隊或者業務的一個指標，你都會發現跟你的崗位有關。你的職位越高你承諾的指標和負責的範圍會越大。
2、 計劃管理是一切管理的基礎，計劃管理也是目標達成的一個工具
基礎管理非常重要的幾項：
- 計劃管理解決的是目標及目標達成工具的問題；
- 流程管理要確定核心的業務流程。產研側的話就是項目流程，確定實現過程中的崗位、解決事事有人做，人人有事做的問題。大家可以去看看，你們的團隊是不是缺某些崗位，觀察有沒有PMO崗等等；
- 組織管理確定權責的關係，解決負責的人必須有權，有權的人必須爲結果負責的問題。
流程管理，一旦流程確定崗位確定之後，我們在日常管理的過程中，再改流程的概率就會變小，你花在這個上面的比重也會小。組織管理也是一樣的，一旦權責明確，組織架構明確。其實你調整的頻率也是很小的，
所以基本上作爲一個管理者，不管你是做項目管理還是團隊管理，無論你是做業務項目還是技術項目，絕大部分的工作都應該花在計劃管理上。
設定目標、設定行動計劃、追蹤行動計劃，做好了計劃管理就能做一個80分的管理者。
3、 計劃管理，非常適合關注過程和效能的“非績效部門”
研發團隊是典型的爲交付、產品負責的“非績效部門”。部門的職責是高效、高質、低成本、安全性地進行交付，這樣的部門非常適合計劃管理。所以理論上，這種部門的管理者絕大部分做計劃管理都是定目標、做行動計劃、review和達成。
4、 計劃管理是一個過程管理
過程管理對銷售部門來說更多的是KPI導向，要完成多少的銷售業績，每個大區有每個大區的玩法，每個城市經理有每個城市經理的玩法，每個團隊的執行過程都是不一樣的。如果通過拍胸脯的方式，這樣的團隊review的頻率或者是績效考覈頻率可能會比較高，會以周或者月爲單位。
5、 計劃管理五要素：他問我爲何（TWWWH）
- 目標（T）；
- 爲什麼（W）： 這是Leader在管理的過程中很容易忽略的和下屬和團隊成員進行溝通的問題。Leader的職責是上傳下達，很多時候你只是告訴他們業務目標是這個，項目交付時間是這個，但你沒有告訴他，他爲什麼要做這個業務和項目，這樣可能會引發團隊成員的歸屬感或者疑慮。當他不認同這件事情的時候，他可能就會成爲達成目標的一個反推力，所以這個部分非常重要；
- 時間節點（W）： SMART法則，要有時間概念；
- 責任人（W）： 責任人很重要。負責的人要有權，有權的人要負責，你有沒有授予他協調資源和完成目標的權力也很重要；
- 怎麼做（H）： 爲什麼很多團隊的目標無法達成，可能是在制定目標的時候只提到這個季度要提升50%，但是沒有提及怎麼提升50%。如果就這樣做了再說吧，那到了季度末的時候整個管理是會是失控的，整個項目和業務達成也是失控的。整個過程的初期中最核心要討論的就是怎麼達成，而不是你的目標到底是10%還是15%。
6、 計劃管理中，核心要討論怎麼做
7、 計劃管理兩大特點：
- 目標的不合理性： 不要花太多時間在討論目標上，定一個50%概率能達成的、跳一跳就能夠達成的目標是最合適的；
- 行動計劃的合理性： 行動計劃和資源匹配必須是合理的，不能是不切實際的。
團隊管得好不好，可以看大家有沒有養成“計劃管理”的習慣！ 如果你做的不好，大概率是季度初制定了目標，但不做行動計劃、不做review覆盤，季度末達成還是不達成，就全靠天。所以我也要求我的團隊在各塊工作都需要做計劃管理，初期討論行動計劃，review整個過程，而不是找藉口和做推脫，並且季度末也會根據他工作的難度係數給予他應得的東西。
作者介紹：
沈劍，快狗打車CTO
- 到家集團技術委員會主席，互聯網架構技術專家；
- 曾任百度高級工程師，58同城技術委員會主席、高級架構師、技術學院優秀講師。
原文鏈接：