2007/05/27

碎碎念.

其實我真的不知道我這篇會寫多長, 會寫多少, 甚至寫些什麼.
應該是工作相關的事居多. 有多少寫多少, 這才是我的style.

這兩天許久不見的胃痛又發作了, 上次發作的時間已經久的讓我記不得了.
昨天晚上仔細的推想起來, 應該是壓力引起的問題, 吃點制酸劑撐著.

上週的行程不難, 就三天的會議加一天的工作, 會議開寫什麼, 知之為知之.
總之我是IT, 開的會一定是IT相關. 參與的人士大概就公司的一些mgrs.
身為一個IT, 我有著可笑的道德操守, 會議的內容就留給會議, 不想多說.
開會的壓力, 來自於愚蠢的循環, 說明問題, 想出辦法, 執行,
新辦法造成新問題, 下一個循環.......因此, 我繼續保有工作.

我一直認為, 到了一定規模的企業, 減少支援單位所耗的成本,
跟業務單位賺取的利潤一樣重要.
業務賺一塊錢要分給整個公司, 支援單位省一塊錢也是攤給整個公司.
所以, 當支援單位效率不佳, 公司會有多少成長也僅是空談而已.

就我短短五年的經驗來看好了,
失敗的支援單位大抵有兩種, 穩定不求進步或是理想而不夠實際.
最糟糕的是, 上級理想不實際, 下級穩定不進步,
結果就是弄出豬狗不如的東西.

拿幾個簡單的例子來看一下,
如有雷同, 絕對是巧合. 就跟瞎貓碰到死耗子一樣的巧.
績效考核是必需的業務, 理想狀況之下,
身之使臂, 臂之使指, 考核結果會對應公司績效.

企業開門就是要賺錢, 賺錢有兩種, 賺一塊錢, 或是省一塊錢.
怎麼賺就是領導單位要去想, 想了之後給下面的人去做. 這是常見的流程.

理想而不實際的考核單位會怎麼做?
員工是公司的一份子, 也可以對公司目標有所貢獻.
所以呢, 要給員工一個機會, 設定員工的目標, 合起來就變成公司的目標了.
嗯, 那積效考核就讓員工自己訂目標來寫吧!

還有, 貼心地想到不要讓大家在年底想破頭, 那我們一季寫一次,
就有高效率又實際的評核喔! 太好了! 我們萬眾一心, 冒著敵人的炮火前進吶!

我想說的是, 如果企業的目標由員工來決定, 那要領導階層何用?
或說, 企業的目標由員工來參與, 但是由領導階層來決定,
不用太多, 只要三層的組織中間出了一頭豬, 員工參不參與其實沒有意義.
再者, 企業的成敗若是來自領導階層的決策成功與否,
那麼做出失敗決策的人還要評核員工的績效, 不就是個球員兼裁判的鬧劇?

我是贊成需要績效評估機制的, 但是需要的是雙向的評核.
領導階層有權決定員工做的好不好,員工不應該只有離職或閉嘴這兩個反應.
至於多久做一次? 要看公司目標和考核單位好大喜功的程度而定.
以業務單位來說, 月目標或季目標可能都是不錯的選擇.
但是以某些需要以年甚至兩年計量的單位如IT或研發,
一季或一個月寫一次不過是在成就其它人的業績罷了.

回頭來講穩定不求進步這檔事. 這種單位比起上面那種毫不遜色.
舉凡行政單位, IT部門, 維護團隊都會有這種特色.
"沒有壞/可以用/還能撐, 就不要動它"
如果事盡如人意, 這的確是個不錯的主意, 跟人一樣, 少動就多個游泳圈.
這些單位不動, 公司就省錢. 裁掉不動的單位, 更省!!

故事的結局就跟粉紅皮的言情小說一樣好猜, 出了包, 一發不可收拾.
要判斷穩定不求進步的單位比理想而不實際的單位來的簡單.
後者要想一下整個流程的脈絡, 需要一點腦汁和邏輯,
前者只要看到他們做事疊床架屋就知道了.

嫌桌子歪就墊個報紙, 因為桌子還能用, 所以不要去想桌子是不是做歪了.
程式有bug就補patch, 反正這麼多年了, 邏輯問題就算了, patch的到就好.
表格要多簽兩個名就簽, 沒有那個流程的格子就簽旁邊, 表格還在就不要重畫.

發展到最後, 桌子要墊兩個月份的蘋果日報才會平.
程式patch的次數比主體發行的版次還要多.
至於表格? 那東西燒掉泡水喝應該可以滋陰補陽, 強腎固精, 養顏美容.

於是, 桌子終於倒了, 這時才要花比蘋果日報還少的錢做一個好桌子.
程式爆了, 重寫一個新程式花的時間比寫出所有patch的時間還短.
仔細看了那張符, 原來早就簽滿全公司的名字, 只為了買一枝鉛筆.

這還不是最慘的, 最慘的是集兩家之大成的單位了.
領導階層理想而不實際, 執行單位穩定而不進步. 太慘了, 簡單描述一下就好.
上面的想做出一台會飛的車子, 下面的怕車子掉下來, 所以底盤焊了一根柱子.
車子是會飛了沒有錯, 不過是在柱子上飛...

這就是我五年來觀察到的一些小小心得, 至於有沒有體驗到就不在討論範圍了.

沒有留言 :

張貼留言