管理心得，三天三夜。。。

軟體、軔體開發的管理真的很難估算時程，而工程師也很難估算KPI（Key Performance Indicators, 關鍵績效指標），這些問題一直以來都存在，也都很難解決的了，接下來我就試著解決這個問題看看。

在計算KPI的時候需要一個基準的計量單位，而軟體、軔體個工程師應該用什麼東西當成計量的單位下去比較呢？

我給的方法是TASK，也就是任務，而這個任務不是單純把東西丟給工程師就沒事了，當控管的人需要切割TASK，讓工作份量範圍大概是三天左右(可以低，儘量不要高)，估算這件事情就是「猜」，事實上，這種事情沒人說的準，而且當時程壓個一天也是在做，對工程師而言，一天搞不好也是可以完工，只是。。。沒測完全而已。

所以三天這個份量，說低也不低，說高也不高，以一周五個工作天來看，三天也去了大半，當事情超出預料，還可以多挪個兩天可以反應，要提早完成，就需嚴格檢查驗證是否仔細，當TASK的份量固定了之後，KPI才有依據，而對主管者來說能夠準確的切到三天份量的TASK，是個考驗，通常是先試試看，然後再來把結果回朔，用來調整預測值。

事情要是沒辦法切的好，是管理者的問題，如果管理者自身都沒能力理解這問題，自然就切不開，而可以理解之後，下刀的準度就是案子能不能順暢走完的關鍵。

當然訓練新人也需要一點組合技來加COMBO數(COMBO勒)，一般來說沒意外的話，兩、三天之後應該就要有個產出，而過程中儘量的幫忙新人過關，不然的話很容易信心崩潰，這也很麻煩，所以在放TASK的時候也要注意TASK的難度，可以使用絕招「後向連鎖反應」的技巧(靠，這招用在需要特殊增強的特殊生都可能有用，一般人，哈哈哈)，支持寫軟體的動力，最大部份還是來自「成就感」，一種對自我肯定的鴉片情感，所以要引誘新人吃這種鴉片，這招是最狠毒的絕招，當然啦，總是要先試用一下一般招式看能不能用，有些人一般招式就會中了，實在是沒必要出絕招，但是對於那種沒什麼信心、容易緊張卻實力還可以的新人，不得已，絕招還是得出，反正人都請進門了(誰叫你看錯人)，不用也是浪費，況且本質上OK的人，只是個性上可能不屬於Ace王牌人才，也可能沒辦法穩定的零秒出手，當信心與習慣建立起來時，強度也是不容小覷的。

在每個回合當中，老手需要去糾正新手的習慣，事實上寫CODE在基礎訓練之後大部份都會(小部份不要問我怎麼辦，要轉、要丟隨便你)，寫完之後好不好維護就另外一回事情了，所以糾正新人的習慣很重要，要不然全域變數把你搞一堆，一個原始碼的檔案破萬行，副程式都在比大、比肥的，關係搞得比三粒的電視劇還扯、還亂，還寫個鳥巢狀的超級迴圈考考你，這種CODE，考驗的不是你的技術或能力，是在考驗你的品性跟耐心，簡直就是在考驗你三字經什麼時候飆出來，所以切割一小段讓新人試試看，老鳥的糾正與驗收真的很重要。

一個習慣差的團隊在寫CODE，麻煩不是在能不能做出來，而是在往後到底能不能好好的維護，而有些人工作數十年，整個CODE的風格如一日，實在是浪費生命阿。

而當老闆的如果不是這行出身的，只想要出錢管人，或是放個外行的來管理，嘿嘿，兩相折磨之下，必有一傷，工程師會搞出很難維護的CODE，此後愈改愈慢，而且愈改愈難改，容易改東漏西的，問題愈來越發散，然後上下開始交怨，管的人不知道問題的複雜度，只知道老闆要的功能不多，改的人痛苦不堪，這個CODE牽一髮動全身，糾結難搞，還有點籌碼的能手，看到CODE就想閃人，新手接管之後是在浪費年輕生命來與盤根錯節的CODE搏鬥，這就是不尊重專業的下場。

所以尊重專業可以讓團隊順暢，節省時間，不尊重專業，問題會慢慢的沈澱，直到你港口阻塞，所有船都準備擱淺，重點還是在人身上。

而能夠俱備這等實力且能夠看穿真相的不是柯南，而是從工程師升級的架構師、設計師，從一般學校剛畢業就被學校教來搞SA、SD、SE的學生，絕大多數不俱備這種能力，除了邏輯上練習的程度差異之外，面對新手會遇到的問題與狀況，不是老手無法體會，而能夠在關鍵時刻給予新手點破的實力，也只有老手有機會做得到，當然這當中也要老手人品上沒問題，要是藏東藏西的，那就很難架構好的團隊出來。

所以建立一個優質的軟、軔體的團隊，事實上並不簡單。