2014年1月14日 星期二

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

軟體、軔體開發的管理真的很難估算時程,而工程師也很難估算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的學生,絕大多數不俱備這種能力,除了邏輯上練習的程度差異之外,面對新手會遇到的問題與狀況,不是老手無法體會,而能夠在關鍵時刻給予新手點破的實力,也只有老手有機會做得到,當然這當中也要老手人品上沒問題,要是藏東藏西的,那就很難架構好的團隊出來。

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

沒有留言:

張貼留言