張國洋 Joe Chang - 作者系列文章

張國洋 Joe Chang
Joe G+ ICON Joe LInkin ICON

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

如何做年度專案的選擇?

這篇是轉貼的文章,談的昰組織該如何篩選專案。 尤其現在是年底了,很多組織都在做明年的專案規劃。 但怎麼樣的Project Portfolio最合適呢? 一部分人會有個迷思,以為最好公司能開的案是「越多越好」。 但以我經驗而言,這未必是對的。 因為啟動超過組織能力負荷的案子數量,有可能最後全部做不出來、或都嚴重Delay、或無法照顧好每個客戶(或產品線)、或壓力太大讓人員陣亡。 最後結果往往不會比「適量」來的好。 但如何評判適量? 又如何選案? 這篇文章有些做法上的建議。 (下週有空時,我也可以分享我個人在此議題上的看法) 這篇文章的原始標題叫做

Scrum的三大主要角色

之前寫了一篇關於Scrum精神的說明。 發現還確實有些朋友對此方法有興趣,所以接下來繼續分幾個篇幅來多介紹一下這方法的一些細節吧。 但我也要再次提醒,世界上沒有「聖杯」。 並非你學了這方法,專案就能避免一切問題。 所有方法都有「適用性」的問題。 適用性「並非跟產業相關」,更跟專案規模、類型、組織、人員能力、還有文化相關。 如果在不合適的環境中嘗試不合適的方法,最後就會得到不對的結果。 所以請別誤以為你是做軟體開發或是遊戲開發,這方法就一定適合你。 但在繼續討論Scrum的方法細節前,我想先解釋一下Scrum中幾個「管理角色」的界定。 因為這方法很

利害關係人管理 之 只是在一起還不夠…

前幾天大家聊到有些專案的甲方常常會在案子進行中天馬行空的提出變更,不受合約控制、不了解管理步驟、態度惡劣、甚至也不理PM的專業。 就有網友問到,這種甲方到底有甚麼方法能「馴服他們」? 我當下提出的回應是說「做專案跟談戀愛是一模一樣的。這種問題完全應該用談戀愛的方式去處理。」 若夫妻沒有對婚姻的Commitment時,任何一方很難單方面維繫感情。 這是Day1就得開始努力的事情。 不然等簽約後PM才想著要怎麼馴服客戶其實已然太遲了。

如何最低成本的取得PDU與考PMP

最近不約而同有幾個朋友在問我「如何成本最低的取得PDU」。 好吧,我先承認。 雖然我自己對這樣「貪便宜」的想法有點不以為然,覺得這樣做似乎不是一個專業人士該有的行為。 但我畢竟也不是甚麼衛道之士,而且只要不太誇張,想找個低成本的作法也是人之常情。 那環顧四周,最便宜的絕對是某些補習班搞出來的噱頭。 據說你可以上那些補習班的Facebook去按讚,這樣就能得到一定數量的PDU!? 除了Facebook以外,好像他們還有一些實體的活動(比方說甚麼課程說明會),你拉人去,他也給你PDU。 搞得像直銷與老鼠會一樣…. 老實

專案熵與經驗曲線

熱力學中有個字眼叫做「熵」(Entropy),是用來衡量系統的失序程度。 所謂失序程度,則也可以簡單的理解成「狀態的混亂度」。 根據熱力學的第二定律而言,在一個封閉的系統中,熵值其實是會不斷增加的。 舉例而言,如果我們在房間裏噴一點香水,香味是會隨著時間慢慢發散。 這是因為氣體分子朝四周逃散,並讓香味的亂度擴散。 雖然大家(包含我)對於熱力學應該沒甚麼研究,但我們可以暫時解讀,在任何系統中混亂度都會隨著時間而自然增長。 這是因為在世界上,任何事務有規律的狀態僅只有幾種構型,但失序狀態確有無限種。 比方說就存在於我房間地板的灰塵而言,它們會隨機且平

Scrum是甚麼?

最近很多人開始在炒作Agile相關的管理方式。 提到很多好處,甚至講得好似能取代一切其餘的專案管理手法。 在這氛圍下,不免就有些朋友會開始詢問我這議題,尤其常有人提到他們公司內部有人提出想導入的聲音。 因為很多人誤以為「跑Agile表示不用做計劃,或是能更自由的隨機應變」。 但這恐怕是對Agile這方法的誤解。 所以就興起了想寫一些相關的文章。 那這篇想來談談Agile的一個分支,也就是被稱為Scrum的方法。 這篇將解釋一下這手法的目的以及期待解決的問題是甚麼。 當然,若大家對這議題有興趣,往後我將繼續談談這手法的一些詳細細節。  

(轉貼) Is Your PMO Maligned or Aligned?

這篇也是我在網路上看到覺得很棒想分享給大家的文章。 我這幾年,看過太多人想做整個組織的專案管理時,還在幻想要直接套用PMBOK或是去哪裡抄個標準管理模式。 甚至碰過很多人居然還去找考PMP時的老師或是補習班來幫忙導入專案管理(結果又只是套用PMBOK XD)。 但這都一定會撞車的。 因為所謂「導入專案管理」對於一個以專案(產品、服務、或一次性)為導向的產業而言,其實就是意味著重塑整個營運流程與管理規則。 這涉及的變動非常廣、也極為全面;必要時甚至包含了組織圖變動或工作執掌重切、以及量測KPI的改革。 如果參與者不能了解該產業案子細微之處,只是套用

(轉貼) No Cut-and-Paste PMO

這是「非常棒」的一篇文章,原文出自於Project At Work。 談的是PMO建置並沒有捷徑,並非套用一個Best Practice就可以,執行者該考量各類分析、了解「真正」需求,以及量身訂做。 尤其設計要以組織的真正改善為出發點,不能以最大公約數的角度來設計,更不能隨便拿別人的作法來套用。 (我也寫過類似文章,不過不像他這麼直接) 尤其他在文章中,把一些政治議題解釋得很清楚,是任何想建立PMO的主管或人員都該一讀的文章。 --------- by Abid Mustafa, August 29, 2011 Abid Mustafa D

為何該少用SF (Start to Finish)

很久沒寫技術性的文章了,所以來這麼一篇,談個重要的概念! ------- 有人曾經跟我說SF很好用,可以用來承接一個固定的里程碑。 比方說「開店」、「驗收」、「上市」,並以此來反推前續活動的開始時間。 比方說如下圖: 換言之,他先用Constrain訂出一個上市日,並用SF的關係連結前續的軟體測試,並讓系統幫你排程出軟體測試的開始時間。 這聽起來還滿美妙的不是嗎? 但為何我會建議你不要用呢?  

不下重藥 不亂下藥

最近有個朋友在規劃公司的管理方向,列了一個計畫要推動的管理規則,並拿來問我的意見。 我是大概知道他們公司的狀況。 他們是個消費性3C產品的公司,但營運主軸一直不明確,老闆在數個產品線中猶豫不決。 而這也讓各主管對於營運方向有了各自解讀(權勢)的空間。 先別說產品線之間吵雜不休了,光是同一產品中都分好幾派。 有一派覺得案子中功能豐富會是成功關鍵;有一派覺得Time to Market是關鍵;剛好也有一派希望成本管控要很仔細(真巧,金三角各有擁護)。 加上中階主管對於管理的概念很薄弱,法制精神不夠強。 過去都是靠強人來維繫著。  

重文輕武、重武輕文 - 專案與業務該重視誰的爭議

之前版上有朋友提問:「到底公司應該重視PM的意見?重視業務的意見?甚至該重視技術部門的意見?」 我們部落格一直有個好處,就是所有網友都很熱情,每次問題一丟出來,大家都會努力從各種角度給當事人不同的意見。 不過在這議題上,大家的觀點都不太相同;對於權力到底該集中在哪個部門上,倒沒有統一的結論。 事實上,這問題我常被人問到,也常常被考倒。 為何會說被考倒呢? 因為每次別人問我,我的答案都是:「其實我也不知道耶。 這應該沒有標準答案吧? 應該關乎你公司的方向而定!」 哈,這回答很爛嗎? 但老實說,這可不是爛答案;這樣回答也不是逃避問題。 反而是我「

「物理嫉妒(Physics Envy)」

最近在iPad的iTunes U上看了這場演講。 我覺得很精采! 所以想在此分享給各位。 演講者名叫Andrew Lo,是一個Finance的教授、也是MIT Sloan School的Management Director。 他演講的主題是Physics Envy(物理忌妒)。 可能得要先說明一下,到底「物理忌妒」是啥。 所謂「物理忌妒」,指的是在很多專業領域中,大家認為其中的理論最終應該要像物理學一樣,能透過數學模型的方式加以解釋或呈現。 最完美的,希望要像牛頓定律那種,靠簡單的數字與模型來「標準化某些反應」。

向上管理的五個原則

周六上課有朋友提到,向上管理是一件很難的事情。 剛好最近我在寫這篇,就趕快趁著周日寫完並分享出來。 這裡我將提供大家五個原則。 若你能把這些原則放在心裡,應該將能大幅提升你與主管的關係。 更好的事情在於,這些原則其實不難。 大部分人不執行往往只是因為他們沒認真想過這幾個要點罷了。 所以算是一個非常80/20的管理概念 – 花些小力氣,卻能得到不錯的效用!  

一次買好、未必挺好

時間拉回到1997年間。 3D加速卡這東西在那時候剛問世。 當時,我要買一台新電腦,在猶豫著是否該順便買張3D顯示卡。 猶豫的原因,在於當時手邊根本沒有能用到3D功能的遊戲。 甚至那時候根本連DirectX都還沒出現,OS是完全不支援3D顯卡的。 但另一方面呢,則又想說:之後這樣的遊戲一定會出現,3D顯示卡需求也一定會普及的! 既然要買新電腦了,怎麼能不順便考慮日後這些遊戲的支援呢? 想了半天,最後選擇買了一張ATI的顯示卡。 型號是甚麼我是有點不確定,隱約記得好像是Rage Pro。 ATI在網頁上宣稱這款顯示卡日後將可支援D

(轉貼) 點錯餐!?領錯餐!?

今天有幾位讀者來公司拜訪我與Bryan,並與我們討論到他們目前公司的管理流程設計。 聊的過程中我跟他們提到一個觀點:「在於SOP要視狀況來展細,並非一股腦切到最細就叫做好」。 到了下午,看到另一位網友Varo貼在他Facebook網誌的一篇文章。 我覺得很巧,剛好他寫的議題就是關於「該花多大力氣標準化流程的議題」。 文章很有意思,尤其非常淺顯易懂,所以特別取得他的許可轉貼於此。 ----------- 本文開始 : 報完稅回家途中, 突然興起去買了麥當勞作中餐。 果然是中午特價時間, 人可多的。