讀管理雜誌 : 王嘉陵, 前IBM資深副總裁談領導

很多人把領導和頭銜, 權力劃上等號, 但領導人所負的是責任.
前英國首相邱吉爾 : 偉大的代價就是責任. 一個領到者要願意付出更大的代價, 承擔更大的責任.
王嘉陵, 前IBM資深副總裁談領導.
1.要以身作則, 樹立榜樣,堅持作對的事.
先釐清自己的價值觀,信念,想法. 價值觀是領導人的指南, 唯有確定自己的理念,才不會隨他人起舞.
同時必須和團隊成員溝通你的價值觀, 信念,做事原則.
接下來,必須保握機會樹立榜樣, 以身作則, 用實際的行動證明自己對信念的執著與全力以赴.

2.挑戰自己,挑戰陳規,才能不斷進步.
勇於嘗試以前沒有做過的事, 讓團隊持續進步. 如果領導人不挑戰自己,團隊成員將只是安於現狀.

3.不要跟你的團隊競爭, 要幫助他們成功.
有時, 領導者為使團隊成員做事, 最好的辦法就是讓路, 並賦予權力.

4.帶兵要帶心,激勵員工沒有公式, 要因人而異.
團隊成員不是被迫跟隨你, 而是選擇跟隨你. 領導人要鼓舞部屬的心, 被感動的部屬, 表現才會超出預期.
激勵的放是因人而異, 有些人因為錢, 生活品質, 成就感, 挑戰.

5.方向對了,才能聚焦.
帶領團隊往正確的方向,也就是未來想達成的理想和願景.
要關注如何拉近現狀和目標.

一個團隊負責多個系統, 開發工作已排好未來的半年計畫, 還有一推搶著安插.

賴 san( くん ) 說他有一個五人團隊, 工作內容則是開發維護零零總總的五套軟體系統, 原本的規劃應有十個人, 但因為景氣不好公司裁員外加人員外流, 目前人事也凍結, 但開發工作已排好未來的半年計畫, 而且還有一堆已知的需求尚未排入, 更恐怖的還有已等待超過一年的需求等著排. 外加三不五時必須應付上頭安插的非預期工作或是一定要先安插的工作.

聽賴 くん 講到這只有哇的一聲, 心想 : 嗯, 工作確實吃重.

賴 くん 繼續說著, 這些系統都不是小系統, 還有部份的系統是與產線有關或控制的系統, 平時電話就不少. 又有資料分析系統, 使用者對資料有疑問, 必須發不少與上游系統溝通及追蹤.

聽賴 くん 講到這忍不住說 : 你那不是五人團隊, 是無敵鐵金鋼團隊.

賴 くん 問到, 其實我是要問像我這種狀況要怎樣處理?

我回答 : 是不是找新工作會比較好一點, 而且簡單.

賴 san( くん ) 這個問題真的很棘手, 光想想像就很恐怖了, 真的遇到了, 日子應該蠻慘的. 但想想現在的景氣, 應該也有人有相同的情況與問題, 替賴 san( くん ) 分析一下也不錯. 賴 san( くん ) 目前所遇到的問題應該有 :

1. 工作量多, 人員不足. 時程安排策略.

2. 系統眾多, 人員配置策略.

3. 系統眾多, 互相支援策略.

4. 既是產線系統, 值班及備援策略.

5. 編制十人的團隊管理策略.

6. 上游系統溝通及追蹤策略.

看看賴 san( くん ) 的型態, 有一些大方向是一定要抓住的.

1. 十人團隊, 團隊的運作要有一定的流程,準則或方向.

2. 所有系統一定要有負責人, 掌管所有大小事.

3. 既然是產線系統, 系統人力備援一定要有, 值班相關準則規範.

上述三大方向的實行細則, 及注意事項 :

1. 十人團隊, 團隊的運作要有一定的流程,準則或方向.

要管理一個十人團隊, 況且系統這麼多, 真的不容易, 所以 :

1.1 團隊的運作流程一定要流暢, 做事方向大家都要清楚, 例如 : 一個新的需求下來, 一定要先瞭解需求, 確認需求無誤之後才可以開工, 至於需求怎要叫做無誤呢? 當需求範圍大時, 就必須要制定需求文件, 請需求者確認畫押, 當需求範圍小時, 有一定的進度就要和需求者再做一次的確認. 如果以時間來看, 最好一個星期一定要和需求者開一次會, 有實際的進度看成果(例如操作畫面), 沒有實際的進度就看文件, 這樣的作法不僅可以和需求者建立緊密的關係, 對於內部也可以有推升的效果.

1.2 該注意的方向一定要明確, 不要變來變去. 一個產線的系統, 品質一定很重要, 所以開發過程中, 要怎樣作法品質的把關, 就必須明確定義, 例如一定要有人最後的品質認證, 或是軟體的單元測試(Unit Test).

所以有時候也可以把流程與項目合併, 例如開發的流程中有一個步驟是品質管控, 而管控的方式就用單元測試實作.

1.3 仔細且頻繁的確認一切事項. 軟體開發看是簡單, 卻時常錯誤百出. 最好每天都要確認一切的事項都是在軌道上正常的運作.

2. 所有系統一定要有負責人, 掌管所有大小事.

2.1 挑選系統負責人. 開發行為和維護行為有著不一樣的注意構面, 也有不一樣的深度, 開發行為從無到有, 所費時間較長, 可以從長計議, 事情單一專注; 維護行為必須, 反應迅速, 舉一反三, 事情多且雜. 但無論怎樣, 一個系統一定要有人負責.

2.2 負責人全權負責. 系統除了要有負責人外, 這個人也要有能立全權處理所有事物.

3. 既然是產線系統, 系統人力備援一定要有, 值班相關準則規範.

3.1第二系統負責人. 系統既然多, 又是產線的系統. 一個系統不能只有一個人會, 一個人不可能只會(或管)一套系統.

3.2 值班規則. 既是產線系統, 問題發生了, 必須要再第一時間恢復. 但問題出在系統這麼多, 並不是所有的系統都是自己開發的, 所以疑難排解標準手冊就變的很重要.

會議中老是做自己的事或人到心不到

怎樣的會議(課程)會使得一個人心不在焉.

會議中我總會不在意的注意與會的人參與情況, 大概就這幾種了.

1. 認真參予, 有問有答. 這總人對於會議內容清楚透徹.

2. 偶爾參予, 但又有問到重點. 這種人我真的不知道他是否對於整個會議的內容都清楚透徹. 一個典型的例子就是 : 他會在會議中使用 NB 處理一些事情, 可是有時又可以和與會者對答. 我想姑且把這種人當作是一個強者, 他就是有能力可以同時做兩件事好了, 因為聽聽這種與會者詢問的問題, 與對答的內容又很清楚.

3. 卯起來做自己的事, 只是偶爾抬起頭來應付會議主持人.

4. 找周公去了.

想想學生時代的課堂上, 也大概是這樣一點都沒有變.

會議主持人, 或是主管, 總是希望與會者能夠清楚透徹整個會議討論議題. 如果是老師, 總也希望所有的學生都可以吸收到課堂上所授與的知識. 但總是會有正反兩群參予者, 只是程度的不同. 為什麼有人就是屬於反面的那一群呢?

讓檢討會議評論與學習在歡熱中完成

檢討會議評論是管理中不討好的議題, 被檢討的人心情不好, 檢討別人的心不在焉, 深怕太認真, 下一次換成自己是被檢討的對象時無法下台.

這個議題雖然很嚴肅, 但是要輕鬆對應, 才會有好的效果. 所以改變氣氛是很重要的(老師都這樣說). 但不管怎樣改變, 效果都不如以下我所使用的方法.

本人所使用的方法是在不知不覺中進行. 

畢竟這是一項工作, 怎有可能不知不覺中進行呢, 當然是不可能, 只是進行方式改變一下而已. 原則如下 : 

1. 在不知覺中開始會議 : 不要會議室, 不要講台, 一切的現況都沒有改變, 只有主導者知道, 會議已經開始了.

2. 會議目的是主持人的底牌, 最後才亮出 : 會議已經熱烈的討論中, 但沒有人知道目的, 卻被引領直奔結論.

3. 慎選第一個發表者 : 既然是檢討會議, 怎可不發言呢, 不要第一個發言者就弄僵了整個氣芬 . 要掌握好氣氛.

4. 讓每個人都發言, 且引領出改善方案.

5. 被檢討者最後發言 

如何看緊你的員工

朋友問, 最近覺得員工的工作狀態不是很好, 大家的進度很慢, 到底要怎樣讓大家認真工作?

我回答 : 哇哈..., 你門公司也會有狀況阿, 你們這些高科技公司, 也有這樣的困擾, 那一般的素質比較低的產業, 不就更嚴重嗎. 好吧, 我們的經驗是這樣的.

就是要看緊點, 所謂的看緊, 就看你怎樣做了喔.

以前我們一個案子有聘請委外的人力(Outsourcing), 這些人力是非常貴的, 一個人力月支出約是我們員工的兩三倍, 你想, 有這種資源的單位, 怎樣使用這些資源, 做了什麼事, 沒有被好好 Review 是不可能的. 所以當你手中有這種資源時, 管理這件事必須格外的做好.

而我們就是每天 Review, 看看昨天做了哪些事情, 完成了哪些, 有沒有怎樣的問題是導致工作沒有辦法進行的, 還有今天計畫要進行怎樣的工作...等. 因為我們有點類似研發的工作, 如果沒有把問題發掘出來, 導正錯誤的方向, 讓這些錯誤繼續進行下去都是在讓費資源, 而多久 Review 一次就是停損點. 故每天 Review , 最多的損失就是一天.

這樣的頻繁 Reivew 對於員工來多, 其實是一個很大的壓力, 所以也需可以改良 Reivew 的方式, 或是說關切, 未達相同目的有不同的作法.