2008/07/10

CTO的高度

我想這篇文章很久了,但一直找不到好的點切入主題,所以這篇文章一直只有題目但無法下筆。直到上周,發生了一件事,讓我覺得感觸良多才下筆。

上周,我們的CTO C先生發了一封mail,問軟體部門主管W先生為什麼在這個版本的測試過程一直沒有開Bug Review會議?W先生就直接發mail給整個軟體部門的同仁,表示:根據C先生的個人要求,所以軟體部門將回復成實施Bug Review會議的情況。

所謂的Bug Review會議


在這個版本以前,軟體部門在Release前的每個Build的測試階段,通常會定期在每周二針對此Build的新Bug、和前一Build未解的Bug,逐個進行狀況了解。

在這個會議中,所有的Bug都會依照被分配(Assigned)的member的英文名字字母開頭作排序。軟體部門主管會主持這個會議,CTO會藉由這個會議了解軟體目前的現況,而每個SW programmer也會被要求依序進入會議室說明被分配的Bug前的處理情況。

一個軟體頭幾個Build的Bug Review會議每次開會需要3~3.5小時,隨著軟體版本越來越成熟,每次的Testing Cycle越來越短,執行的頻率也跟著越來越密集,但執行所需的時間就越來越短,直到:
  • 預定Release時間;或
  • 軟體的品質符合可以接受的criteria,

就可以準備Release。

Bug Review會議的特性


目前執行時,依照上次執行Bug Review會議時的經驗,軟體部門主管和CTO會全程出席這個會議,不過因為他們二人的參與的方式不同,所以對參加Bug Review會議有不同的立場。

對C先生而言

由於C先生只涉入了部份軟體部門內的開發活動,但對於其他軟體部門的開發活動並不了解,所以他會希望藉由參加Bug Review會議的過程,了解他未參與的小組的開發活動近況、及其Bug。

對W先生而言

因為在開發的過程中,W先生就一直盯著Bug Tracking System(Bugzilla)上的Bug,只要一段時間沒有更新Bug的status,他就會主動去了解、並要求member持續更新Bugzilla上的資訊。

因為W先生已經透過Bugzilla很了解開發的近況,所以Bug Review會議對他而言浪費太多自己和組員的時間去重覆了解他已經知道的資訊,這是他之所以要在這版取消Bug Review會議的原因之一。

現在,C先生直接發mail要求W先生將Bug Review會議改回原本的模式,從我來看,這個事件隱含了幾件事。

CTO的定位?


其實我對CTO的職責與定位不太了解,(有興趣的讀者請見維基-首席技術長),但我絕對認同:決定軟體部門Bug Review會議實施方式的權責是在軟體部門主管的身上。

從C先生這項舉動我解讀成:
  • C先生希望能更掌握軟體部門的開發近況;
  • 所以,C先生直接架空了軟體部門主管W先生;
  • 並向軟體部門的同仁表明他才是這個部門的實質掌控者,軟體部門內的所有活動C先生說了才算數。

C先生在處理這件事上,破壞整個組織的行政架構及行政倫理,但其實C先生早在這件事發生前就這麼作了,但在說這件事前我先講另一個「少將班長」的例子。

以前我在部隊服役時,就聽過「少將班長」的趣聞。有些少將指揮官,嫌基層的內務差,就直接跳過了好幾個階層直接到基層去檢查內務,甚至親自示範如何整理內務。這麼作感覺起來很有效率,也直接告訴所有的人指揮官對內務非常要求。

但指揮官下有中校營長、上尉連長、中尉排長、下士班長,這項舉動等於擺明告訴所有的阿兵哥這些人都沒有我指揮官厲害?讓這些士兵懷疑主屬主官的能力,那以後大家還會聽從他們的命令嗎?

此外,一個人要直接管理400-500人,也牽涉了管理幅度的問題。

管理幅度


軍中設置這麼多的階層,就是考量每個主管能够直接有效指揮和監督的屬下數量是有限的,這個能有效地直接领導的屬下數量就被稱作「管理幅度」。

由於組織內最高主管的管理活動也同樣受限於「管理幅度」,因此他就需將担任的部分管理工作再委托给另一些人協助進行,依此類推,直至受托人能直接安排和協調組織成員的具體業務活動。因此,也形成了一個组織中從最高主管到具体工作執行人員之間的不同的組織階層。

雖然,C先生是研發部門的最高主管,但他真有獨自指揮40-50人的能力?我認為是不可能的。

研發部的指揮階層


研發部下轄除了軟體部門外,還有另外兩個部門;在軟體部門內除SQA外,還有另外6個組,每個組除了組長外就是負責執行的組員了。C先生破壞的行政架構就是直接跨過了軟體部門主管、和組長這兩個階層,去指示組員依照他的意思開發軟體,但軟體部門主管、和組長則完全管不到這個組員,這導致了人員在管理上的衝突。

因為當屬下能被更上層的主管指揮時,那直屬主管要求要執行的規律性工作,對屬下而言其重要性就會降低,但這類的事可能重要但不一定急迫,延後的結果卻可能會影響到其他的工作,這時到底該先執行誰交辦的工作呢?是直屬主管?還是更上層的主管?

跨層領導的結果就是會出現指揮上的衝突。

Bug Review會議的有效性


主題拉回舉行Bug Review會議,我自己是認同W先生的作法。

因為直接在軟體的問題出現前就先找人持續Verify可能有問題的程式,直到品質達到某一成熟度了,才將code checkin至CVS內,直接在源頭就對程式品質作把關,雖然這個方式SQA會被當成了Tester,但這個品質至少是比以往版本所召開的Bug Review會議討論再解決的方式更有效果和效率。

以軟體部門內以往每組各自運作的情況,這個版本絕對無法準時推出。

但是C先生完全沒有看到W先生在取消Bug Review會議後的配套措失,甚至認為這次的小改版是個很小的effort,還逕自相信在前版所使用的Review活動能持續有效。

但倘若這個方式有效,上個版本Release的時間就不會一延再延:從去年10月、延到12月,還是在W先生進入公司花了3個月了解所有的情況後,不但將時間訂在今年4月低並準時Release外,也將這版本訂在6月底準時Release。

從結果來看,W先生對於軟體專案的管理能力明顯勝於他的老闆C先生。

Bug Review會議的必要性


當然,其實我並不懷疑Bug Review會議的必要性,它當然要執行。

只是,Bug Review會議的實施必須建立在其他的基礎之上。至少必須實施我在「軟體開發過程的長鞭效應」一文所提及的:
  • 「開發流程」
  • 「版本控制」
  • 「需求管理」
  • 「型態管理」

這4個提昇軟體品質的手段,還得加上所有組員對這4個措施也要有一定的成熟度才有可能看到成效。

小結


從SQA觀點來看,除了這幾個是主要的問題,還有其他的因素就先不說了。我想要討論CTO是否應該管這麼細節的課題。另外,我也對CTO想單靠實施「Bug Review會議」就想要提昇軟體品質的思維不解。但我實在不知道為什麼會有這樣思維的CTO,這個問題讓我一直很訥悶。

後記1-2008年8月7日


我和同事討論過這件事。我們一致認為這是台灣企業經營上常見的問題。

因為,通常擁有很多技術的人,通常也會是個管理者,當管理者與技術分離時,就失去掌握權力的基礎,位子就會被其他的人所取代。

所以,既有的管理者往往會一直去追求、擁抱技術,以避免被邊緣化。

但在外國的企業有「管理」和「技術」兩個不同的系統,甚至在連軍中也是如此。管理職就是軍官,可以領導越來越多的人。技術職就是士官,可以專研戰鬥所需的相關技能。

現在竟然在管理職之內,又設置了一個技術性質的最高職位(CTO),然後回過頭來領導組織,我認為這是大有問題的。因為,有技術的人不見得有管理能力,但這個安排就是建立在這個不一定成立的假設之上。

後記2-2008年8月16日


在我看完1080期的商周後,我找到了為什麼我們的CTO的行為不適任的原因之一。

「絕大部分的技術工作者,都不適合當老闆,」王品集團董事長戴勝益認為,這可以從業界「會做菜的師傅,如果跳出去開業,很少有成功的。」看出。

因為會做菜,所以當別人執行成果與自己預期的有誤差時,老闆就會跳下來插手,親自做給夥計看,「一這麼做,就完了,」戴勝益說。

所以當技術越強的人創業之後,領導難度反而變得越高,這就是技術創業者最難的部分:選擇要不要放掉自己賴以成名的法寶,把自己的know-how,變成組織的know-how,靠別人來執行原來執行的工作。

但如果不把自己賴以成名的能力釋放出來,就不可能真正運用組織的力量。我想這就是我們的CTO可能需要調整的地方。

因為到最後,組織要成功,技術工作者就要習慣放手,靠領導來帶領創造組織的成功。
  1. 維基-首席技術長
  2. 百度-管理幅度

2 則留言:

  1. 嘿啊!! 最近剛當專案負責人, 結果就犯了把一堆事情攬在自己身上的大忌><".

    回覆刪除
  2. Hi 張天師,
    我自己覺得最好的「專案負責人」是一個最能了解:專案成員、專案目標、專案資源的人,而且他是一個「協調者」的角色。
    如果他能知道那些事有誰作、什麼時候完成、如何確認已經完成,能作到這些事就已經很好了。
    真的不用把一些非自己就能完成的事攬在身上,這樣容易有管理上的衝突。

    回覆刪除