項目微管理35 - 系統

根據前面學習到的知識，紅細胞的目標管理體系如何打造，四代已經有了基本的思路了，三個部分：

 

第一部分：目標設定

經典OKRs的作法，咱們前面已經討論了，很是的科學，但卻不能拿到紅細胞來直接使用，由於目前不適用。

不過OKR有一點四代是很是承認的，那就是有一部分目標來自於我的。

對於紅細胞來講，軟件的不少功能都已經積壓在功能列表中不少年了，需求已經不少，因此目標主要來自這個部分，但不是所有，四代仍是要保留來自我的的目標。之因此在這種的狀況下還這麼作，是由於四代想讓團隊先適應這種模式，並養成參與到決策中來的習慣。對於「互聯網+」時代的團隊，我的的創造力是毋庸置疑的，任何壓抑我的創造力的作法都是極其愚蠢的。

 

對於目標組成的佔比，四代綜合考慮後，肯定的比例是：三七開，三成目標來自我的，七成來自公司和團隊，是否是合理四代不知道，不過這個事總得有個開始，這樣才能去試探更加合適的值，並且在四代的計劃中，這個值也必然會隨着團隊和項目的進化不斷調整。

 

第二部分：360反饋，考覈內容

對於360反饋考覈，四代以前的公司都是祕密的，他都不知道公司的標準是什麼，因此就算考覈下來，四代也只是獲得了一個單薄的分數，雖然他內心對本身也有一個數，可是他不知道該怎麼作。確實，程序猿的考覈不能像工廠那樣定量的給出一些數字，可是仍是能夠定性描述的。有了定性的描述，團隊就會知道應該怎麼去努力。

 

綜合各類設計績效考覈的思路，四代以爲用「3W2H」來解決它最爲貼切。

第一個W - Why

這個W要回答爲何要績效考覈，這個不用說了吧，主要是爲團隊的努力指明方向，輔助的做用是覈定必定階段內的努力成果。

 

第二個W - What

這個W要回答績效考覈要考覈的內容，這個內容就是團隊的努力方向的細節。不是有一句話是這麼說的嗎：「若是方向錯了，那麼跑的越快，就垮的越快」，因此這個「W」很重要。

 

你們知道，對於員工來講，公司考覈什麼，他們就會表現什麼。正由於知道這一點，不少聰明的朋友對考覈的細節祕而不宣，或者是模棱兩可。這麼作，一方面，以爲能夠激發員工無限的創造力，由於沒有標準，因此就沒有限制；另外一方面，只須要按照本身主觀的判斷操做一下就能夠了，很是省事，反正別人又不知道考覈的究竟是什麼，這個時候隨便找個高大上的理由，性格上的缺點解釋一下就能夠了，怎麼都不會錯。

實際狀況是，一旦如此實施，不少人就漫無目標，流於混日子了，或者是他本身想努力，殊不知道該怎麼作。

四代認爲，通常組織，就像如今四代的公司，須要的作法多是知足：有限的約束，無限的可能。有限的約束來保證最低的輸出，無限的可能來培養創造的可能性。有時候最優的方案就是避免出現極小值的方案。

考覈中還有一件很是常見事就是，管理者會從上帝的角度出發，但願把每一個人都當作聖人來培養，對於這種作法，四代一直不怎麼認同。

在四代看來，考覈不是要打造「三好學生」，「全能戰士」。在「互聯網+」時代，團隊須要的是「互補」和「特長」。

好比有的人技術很強，可是溝通和展現能力不是那麼好，有的人特別擅長規劃與安排，可是技術能力又稍微偏弱，有的人技術能力與管理能力都不錯，可是沒有特別亮眼的技能。全部這些人都有可能出如今同一個團隊中，如何兼容閉包，最大的發揮每一類人的長處，儘量的避開每個人的短板，也是一個績效考覈系統設計要考慮的重要方面。

 

因此考覈的內容一方面要求覆蓋全部的可能，可是又不是要求全部人都必需要作到。

綜合上面的兩點，四代根據按照以下步驟選擇了考覈的內容：
首先，四代從團隊目前的表現中收集全部的備選項，而後再加上四代參考的那些公司對於「優秀」所定義的行爲，這樣通過整理，四代獲得了一個的可供討論的提案。
其次，四代組織你們一塊兒頭腦風暴，補充更多你們認爲好的行爲。
再次，合併整理分類，獲得一份你們贊成的版本。獲得你們的認同，推動就不會有太大問題。
最後，回顧所有考覈內容，宣佈開始實施，制定每一年修訂的計劃。

最終的考覈的內容分四大類，每大類有數個權重不等的加分項：
1. 項目研發
這一類包括Release發佈是否成功，功能質量、代碼質量、違反代碼規範次數、重要重構次數、違反研發流程次數，引入提升效率的新技術和工具幾個主要的加分項。
2. 團隊合做
這一類包括幫助別人解決問題次數、接受別人幫助次數、主動性、積極性、跨團隊服務態度幾個主要的加分項。
3. 學習分享
這一類包括分享的工具、資料和知識的數量，參與部門分享的次數，學習的內容，須要掌握的模塊的熟練程度增長狀況幾個主要的加分項。
4. 額外的狀況
這一類指的是不屬於上述三類、可是有益於公司或團隊的其餘事例。

在後面公司引入價值觀考覈以後，第二類和第三類所有合併到價值觀考覈中去了。

 

第三個W - When

這個W要回答何時績效考覈。

這個大多數公司都是一年一次，或者是一年兩次，四代以爲針對紅細胞的現狀，這樣是不夠的，由於反饋週期太長。

績效考覈主要的做用就指明方向和核定努力成果，若是時間拖的太長，那麼容易被忽略，或者遺忘。
可是四代也清楚，考覈是有成本的，在下面咱們會看到執行考覈的成本，那也是不少公司一年只作一次的緣由，實在是勞民傷財哈。

綜合考慮了這些因素和成本，四代把考覈分紅了兩類：

一類詳細一點，是Release考覈，每一個Release結束後的第一週開始考覈，考覈內容就是上面的那些內容。

另外一類簡單一點，是年中或年終考覈，這個取決於公司執行的時間，這個主要是彙總時間段內的各次Release考覈的成績便可，很是簡單。

 

第一個H - How to do

這個H要回答考覈的形式是怎麼樣的。

因爲年終考評是以Release考評爲依據的，因此如何進行Release考評就成了關鍵的一步。

在這個方面，四代全盤接受了360反饋的作法，那句廣告詞是怎麼說來的，「咱們只看事實，不講道理」。

Release考評分兩步走：自評和他評，內容是舉事實，也就是列舉在當前考評的Release階段發生的任何的事件，正面或反面的。

自評是被考評員工列舉本身的事例，他評則是被考評員工直屬經理（也就是四代）、被考評員工自願指定的團隊內2個夥伴和團隊外的2個夥伴，共5我的爲被考評員工列舉事例。

當四代收到全部事例後，再根據事例所屬的考評內容加分項來給被考評員工加分，最終根據總分給員工劃定一個等級，這就是Release考評的全過程。

 

第二個H - How to improve

這個H要回答對於反饋的處理，以及整個流程演化的過程。

通過上面三步，考覈的內容和方式就肯定了，那麼是否是每次這麼執行一下就能夠了呢？很顯然不是這麼簡單。

就像前面說的那樣，前面肯定的那些內容和形式只不過是一個並不知道是否正確的種子，也僅僅是個起點而已，可否讓績效考覈這個小不點隨着團隊的發展成長爲一棵參天大樹，還須要不斷的演化和調整。

在每一個Release結束，四代不只會組織績效考覈，還有一件事也是四代不管如何都不會掉以輕心的，這就是團隊對於考覈流程自己的反饋和建議，包括考覈內容和形式在內一切考覈相關的事情。

四代會提早發出這些內容，而後組織一次會議專門討論這個議題。四代對全部反饋的內容無比重視，由於四代知道，任何流程要發展壯大都離不開每一個人的參與與反饋。任何東西一旦中止演化和調整，就代表它已經死了。四代收集到反饋之後，會在下個Release研發的過程當中整理並調整考評流程，而後你們一塊兒討論並在Release結束時當即開始執行。

所謂的敏捷開發流程，也就是快速的開發，快速的測試，快速的發佈，快速的反饋，以及快速的調整吧，環環相扣，缺一不可。

而在這個快速迭代的過程當中，完成一切的粘合劑，就是溝通。溝通是一個團隊最重要的事，在考評流程也很是正確。

 

第三部分：溝通管理

對於溝通在團隊中的做用，無比重要，生死攸關，不管怎麼強調都不爲過，這個前面已經討論過了。

 

在團隊中，四代採用了「實時溝通」與「一對一溝通」，它們一正一輔相結合，能夠解決目標管理和績效考覈中大部分的問題。

「實時溝通」通常發生在事件發生後的第一時間，無論是安撫、解決問題，仍是鼓勵、獎勵，第一時間最有效，最高效。

「一對一溝通」每一個人每個月一次，稍微正式一點，用於解決那種不是很緊急，或者平時不太好開口的問題。

無時不在的溝通、鼓勵、培訓和陪練，使得敏捷開發的流程順利的向前運做，這也使得目標管理和績效考覈這個系統隨着團隊的不斷磨合而不斷茁壯成長。