技術轉管理是多數工程師對自己的職業規劃路線，相信我們最可愛的嵌友也不例外，但是邁入管理層以後，是不是真如自己想象得那麼一帆風順呢？其實談何容易。。。
看看下面我和小張的對話，希望能幫助到準備或者已經轉管理的你！
半年前，我認識了小張。小張剛剛升了技術總監，手底下管着五十幾號人。我這邊正恭喜小張高升呢，小張卻長嘆一聲：
“大師，還是寫代碼輕鬆啊，技術管理太難了。如今這些開發不比我們當年，活佈置下去就沒動靜，到了交付日問他幹完了嗎，他就找一大堆理由，沒一次按點交付的。平時混一天是一天，彼此還不服，總覺得老子天下第一，在座的都是垃圾。”
“那你可以考慮試試工時管理。”
“嗯？工時管理是什麼？”
工時管理是什麼？
工時管理源自於人力資源的時間管理，是一種歷史悠久的傳統管理手段，後來被研發管理借鑑出來，應用到各種開發實踐中。
工時是員工記錄自己花費在每個任務上的時間，在不同的管理系統裏有着不同的稱呼。例如JIRA中叫“Time Spent”，TAPD中稱爲“花費”，微軟叫“問題解決時長”。無論叫什麼，本質上都是人力資源成本的一個度量單位，是一個“具體的人和一段時間”的關聯。
工時管理是圍繞着工時建立起一整套管理方案，幫助團隊從被動接受到主動承諾、主動管理、持續改進的這樣一種方法。
歐美很多企業都要求研發團隊記錄工時，記錄工時這個功能也在研發管理工具中成爲必備功能。微軟、Google、Facebook等都要求研發人員記錄自己解決問題的時長，甚至對於很多創業公司、高度敏捷團隊，大家可能連需求文檔都不寫，但卻會認真記錄解決問題時長。
“這麼神奇？這是什麼原理？”
原理是什麼？
因爲一個人一天的工作時間是有限的，這些有限的時間做出來的產出也是有限的。
工時管理的原理，就是要求員工記錄每個問題自己投入的時間長度，然後通過人和事兩個維度分析，來發現問題。
對人，可以評估員工表現，找到優秀員工，聚焦管理資源；對事，可以實現有效預估，和過程中的自主管理。
“聽着挺有意思，那我要怎麼做呢？”
“你呀，要先從讓大家寫日報開始……”
寫日報咯！
小張聽得兩眼放光，回去就讓團隊每天提交日報。
小張手下有三個研發經理，老王資格最老，很是憂慮，“咱們團隊都是敏捷型團隊，寫日報是不是太嚴格了？”。
這種態度小張早有預料，讓老王現場說說，自己團隊每個成員都在幹啥。老王開始還能大概說說，問細了就完全不知。
“老王啊，你們天天跟團隊在一起，都不知道他們每個人天天在幹啥，你說，這團隊還能好麼？”
老王很感慨，其他兩個研發經理也點頭，於是第二天，研發團隊正式開始提交日報。
小張要求每個開發人員在日報裏要寫清楚，自己每天干了啥，每件事情用了多少時間。
實施兩週以後，小張又來找我。
“日報推下去了，大家最開始還挺新鮮，現在又回到老樣子。而且團隊內部逐漸有了抱怨，任務管理系統裏要更新任務狀態，還要天天寫日報，同樣的事兒兩個地方做兩次，太浪費時間“。
“如此這般、這般如此……”
日報變工時
小張與開發經理們碰頭，這個日報怎麼樣？老王撓撓頭，“你說有用是有用，每天看看每個人的總結挺好的，也能發現點兒問題，就是大家覺得太麻煩，兩頭記錄。”
“怎麼改合適？”
“反正開發人員每天都要關任務，乾脆關任務的時候把工時記上得了，我看系統裏的工時日報就可以了。”
“好呀！”小張順水推舟，“但是，一個任務當天幹不完，他的日報裏不就少了這個事兒嗎？”
“那就要求甭管幹完沒幹完，每天至少記一下，這樣天天都全了。”
“就這麼幹！”
第二天，團隊宣佈，不用寫日報了，只要每天記錄工時就行了，團隊很高興，當場鼓掌。
研發管理源數據主要可分爲兩類：資源數據和資源活動數據。數據分類清晰，可以促進全面地收集數據和合理地存儲數據。便於後期數據的分析彙總。
一是資源數據，例如人、組織結構、知識信息等。此類數據變更頻率比較小。資源數據最好能全面記錄。但受限於法律規定或信息獲取手段等，數據的完整性不一定能保證，這裏就需要把握一個度，通過長期的堅持和積累，實現數據的不斷豐富。
二是資源活動數據，比如開發過程數據、測試過程數據、投產過程數據，生產問題解決數據等，此類數據的記錄往往是比較缺乏的。爲了更好地保留研發管理活動所帶來的資源活動數據，需要建立嚴格的管理流程和制度, 並配以相應的技術手段，實現活動過程的即時記錄。
——摘自《研發精益數字化管理》
延期？逾期？
小張最討厭的事兒就是項目延期。
有幾次大的延期導致客戶非常不滿，小張覆盤發現，主要問題都在產品和開發這裏，前面一拖，後面就只能跟着拖，越拖越遠。小張嘗試過要求開發經理保證交付不延期，效果很差。
兩週後，小張又來找我。
“大師，您不是說工時管理能有效防止延期嗎？快教教我，下面該咋幹？”
“首先啊，你口中的延期，其實是逾期……”
延期，是指將約定的交付日期向後修改。
逾期，是指在約定的交付日期無法交付。
二者之間的關鍵區別是：延期是雙方溝通後的共識，進度風險已經得到識別和控制，雙方都已接受；而逾期則是單方面行爲，並沒有提前通知客戶進度風險。
“可是這有什麼關係呢？不都是沒辦法按期交付嗎？”
“要治療延期，要先治逾期，都不逾期了，延期就好控制了。”
“那怎麼治逾期呢？”
“考覈什麼，得到什麼，先學美國大使館，發佈一組逾期數據再說。”
逾期排名
小張回去就翻歷史數據，把過去一個月各個團隊的需求逾期情況統計了出來，找研發經理一起過。
大家一看，老王團隊的逾期率最低，小趙團隊的最高。
第二天，小張發佈了各團隊逾期排名，強調減少逾期是現在工作的重中之重，務必要在這個季度，把逾期率降低到10%以下！
小張點名表揚老王團隊逾期率低，希望老王團隊再接再厲，其他團隊要向老王團隊學習。
這下七嘴八舌說啥的都有，有不服的，有得意的，有懵的。
過了一週，老王主動找到小張。
“張總，我有個建議，可以減少逾期率，就是推廣起來有點難度。”
“別有顧慮，有建議直接提”
“你看工時記錄的這地方啊，還有個預估剩餘時間，我琢磨着可以用起來……”
餘量估算
小張給我打電話，瞭解了一下估算該怎麼搞。
實現估算也很簡單，每個開發人員在填寫工時的時候，要對這個任務剩餘的工作時長進行評估，填寫到“預估剩餘時間”裏去。
如果剩餘時間超過了到期日，就說明這個任務幹不完，這時必須上報研發經理。
一週後。
“效果怎麼樣，小趙，你那邊好像又延期了，什麼情況，爲啥沒提前發現？”
小趙哭喪着臉：“估算是估算了，可大家都是按系統設定的剩餘時間填了，壓根沒主動思考剩多少時間，等到幹不完了的時候才上報。”
老王想了想：“我們是不是可以做個案例教育團隊，強調認真估算的重要性。”
小張搖搖頭：“要做，但只教育是不夠的，現在是你們三個身上揹着逾期率，但是開發人員自己沒有背，壓力沒有傳遞下去。”
老王眼睛亮了：“給開發人員做個逾期排行？”
“對，但是隻限於團隊內部使用，不對外公開比較。”
“我們試試！”
內部排行
各個團隊統計了每個任務的逾期情況，拿着數據挨個找開發人員確認逾期原因。大家確認基礎數據沒問題以後，各團隊發佈了逾期排行。
小張把研發經理們叫一起，都拿出自己部門的排名過一過，看看誰靠譜、誰不着調。和大家的主觀印象基本一致，靠譜的就是大家常說好的，不着調的基本也是大家覺得有問題的。
咬不準的主觀印象，一個逾期排名就說明白了。
兩週後，逾期率降低到10%以下。
小張：“效果不錯。”
小趙困惑：“張哥，這不就是把逾期變成延期了嗎？他們來找我說幹不完，我也只能延期呀。”
老王皺眉：“我覺得大家預估得更謹慎了，能不能幹完也都更上心了，就是產品那邊覺得咱們估算時間有點保守。”
“是啊，逾期問題解決了，生產效率問題還在，得找大師聊聊去。”
過去，我們的大部分研發管理是依據經驗管理，現在的市場競爭環境與過去相比發生了很多變化，因此研發的管理也需要隨之變化，而僅僅依據經驗作出的判斷往往會有很高的風險。沒有數據的企業就像沒有昨天、沒有歷史一樣，曾經犯過的錯誤還會犯，曾經繳納的“學費”還要繼續去繳；沒有數據支撐，管理者就無法做到精準定位問題，無法進行精細化管理。
數字化管理可以量化管理研發團隊和研發個人的工作過程、工作成果；可以精準分析效率、質量、成本、收益等內容，發現研發行爲與工作成果之間的關係以及其中存在的問題，然後根據分析結果來制定改進管理方案，促進優化資源配置、改善工作的方法工具、改善管理流程、提高研發效能。
——摘自《研發精益數字化管理》
預估太保守？
小張call過來：
“大師，我們逾期率幾乎沒了，但是大家的預估越來越保守，這個怎麼破？”
“預估，看的是準不準。不管保守還是樂觀，總歸是不準。”
“那怎麼才能準呢？”
“分兩步走，第一步，要度量準不準；第二步，要給團隊賦能，教他們怎麼評估。”
“怎麼度量準不準呢？”
“看任務第一次預估的時間和實際交付的時間，他們的差就是準不準的‘度’。”
“明白了，那怎麼才能評估得更準呢？”
“這個嘛，就得細說說了……
精確預估
小張回去就折騰起預估差異率，數據出來幾位研發經理一看，差異率都在30%以上。
老王：“預估是老大難問題，不好估啊！”
小張：“把數據拿出來，看看能有什麼發現。”
他拿出一張圖，這個圖將所有任務的實際投入彙總，以人時爲橫軸，任務個數爲縱軸，展示了所有任務的成本分佈。
小趙一看就說：“1人天以下佔50%，1-2人天佔30%，2人天以上佔20%，這三個臺階多明顯！”
老王：“我們可以把第一個階段的任務叫‘簡單’，第二個叫‘一般’，第三個叫‘複雜’，這樣就能給任務分級了。”
“但是怎麼能識別出來一個任務是哪個級別呢？”
小張：“把大家組織起來自己看這些任務，讓團隊自己總結總結經驗。”
於是，小張組織研發團隊各自面對自己的歷史數據，對每個級別的任務特點進行總結，總結的結果收集起來，作爲每個團隊的任務分級指南。
實施兩週，效果明顯，差異率下降到20%左右。老王主動要求團隊每個月總結一次這個預估手冊，持續提升預估準確性。
過了一個月，我見到小張，小張已經不愁眉苦臉的了。
“現在幹活沒啥大問題了，但是這都年中了，得刺激刺激大家。”
測量要有明確的目標，通過目標來引導方向，圍繞目標制訂測量計劃。測量要結合數據分析，通過分析可以使研發管理的人、事、物之間建立關聯，如果沒有後續的跟蹤分析，測量得到的數據就會失去價值和意義。
1、分類分析法
分類分析法是根據數據對象的特點對其進行分類，再進一步分析，從而進一步挖掘事物的本質的方法，如圖2-20所示。
當數據分析的對象數據規模很大時，我們可以按照其特點和屬性歸類，使類內的對象差異小，具有共性；類間的對象差異大，具有個性，那麼我們就可以對數據對象的幾個類別進行分析。這樣，分析工作的難度和強度都會大大降低。這就是分類分析的價值所在，用類別代替個體，使複雜的事情簡單化。
——摘自《研發精益數字化管理》
績效評價
工時管理能夠用來對每個人進行績效評價。
關注兩個指標，一個叫投入產出比，一個是飽和度。
投入產出比 = 任務規模 / （能力 * 工時）
飽和度 = 工時 / 應出勤時間
這兩個指標互爲矛盾指標，簡單說，如果幹不出活，還想投入產出比高，就只能少記工時，但是這樣的話，飽和度就低。
具體計算時，參數可以這樣設置：
任務規模可以根據之前的“簡單、一般和複雜”分別對應1、2、5。
能力可以按照職級分別指定，與各個職級平均薪資成比例，比如T3=3，T4=5，T5=7，T6=9。
應出勤時間就是按照考勤系統的數據統計出來工作時間即可。
這兩個指標，加上之前的逾期率和預估準確率，分別配上權重，就可以得到績效評分了。
績效排行
小張回去就拿數據統計了一圈，做了團隊排名和個人排名，找大家一起參詳結果。
小趙一看：“我怎麼又排最後？我太難了！”
老王嘿嘿一笑：“這排名有意思，你看丁丁，是我們的好員工，投入產出比這麼高。你再看亮亮，幹得好像挺多，都是簡單的事兒，級別這麼高還拈輕怕重，投入產出比這麼低。”
小趙也來了精神：“我的團隊這飽和度成問題啊，怎麼這麼低？回去得好好教育教育他們，都以爲少寫點兒時間就萬事大吉了？”
老王建議：“現在還是初期，我建議把飽和度的重要性稍微調高點，鼓勵大家多記錄，等大家飽和度都上來以後，再往下降降。”
工時績效試運行了一段時間、給予團隊足夠適應期之後，下半年，小張團隊發佈了績效排名。
針對前三名員工，小張做了個流動獎章，並且每個月獎勵1000元。
第一名的團隊有流動紅旗，獎勵活動經費3000元。
部門士氣爲之一振，打了雞血一樣的搶紅旗、搶獎章。
對吊車尾深惡痛絕的小趙，硬是給弟兄們扇風鼓勁兒，把紅旗搶到了手。
結語
小張雖然也很高興，但是隱隱還是有擔憂。
“大師，大家光顧着搶紅旗，工作真做明白了嗎？”
工時管理能幫助團隊降低進度風險，提升投入產出比，這是工時管理擅長解決的問題。
但是到底組織是不是真的能夠從中受益，光靠一個工時管理是搞不定的。
意猶未盡的工程師
不妨認真閱讀一下《研發精益數字化管理》
此書同樣適用於嵌入式項目
後期我們會邀請作者來分享一下個人從事項目管理的經驗，敬請期待！
繼續看，有福利！
小編申請了數量有限的書送給大家
助力嵌友在管理崗位
一帆風順！
規則如下：留言講述一下自己在項目中遇到的管理方面的問題（可以是自己的，也可以是別人給你造成的），小編會從中挑選幸運的朋友，將書快遞給您！（截止日期：2020年6月12日中午12:00）
到時候請留意手機互動留言哦~
