Search This Blog

載入中...

2009年6月22日星期一

《從A到A+》(Good to Great) by Jim Collins

A to A plus Jim Collins,近年來最熱門的企管顧問、作家。1994年出版《基業長青》(Build to Last)一書,研究歷經歲月考驗的代表企業長青的秘訣,全球銷售逾百萬冊。而他的另一力作《從A到A+》(Good to Great),探討企業從優秀到卓越的轉變過程,被選為2001年最佳財經企管書籍。

Jim Collins 提出一個問題:為什麼相同產業、狀況相近的兩間公司,後來卻一盛一衰?Jim Collins 經過五年的研究,解答了這個問題。他發現,成功的公司往往有個低調、謀定而後動的「第五級領導人」;成功企業其實是是有意識地變得簡單的,他們弄清楚該取該捨的項目,然後有紀律地不斷重複正確的做法。

每個「從優秀到卓越」的公司在轉變期都曾經出現這類領導人,他們結合了謙沖為懷的個性和專業上堅持到底的意志力,不愛出風頭,但都有強烈的決心,會盡一切努力創造卓越的公司,這些卓越領導人身上其實有兩種矛盾的特質,意志堅強,但是宅心仁厚,勇敢無懼,但是謙沖為懷。

書摘:

第五級領導
第五級領導人兼具兩種矛盾的特質——謙沖為懷的個性和專業堅持的意志力。他們當然雄心勃勃,但是一切雄心壯志都是為了公司,而非自己。

先找對人,再決定要做什麼
推動優秀公司邁向卓越的企業領導人,並非先找出巴士該往哪裡開,然後要員工把車子開過去。他們反而先找對人上車(要求不適合的人下車),接下來才弄清楚車子該往哪個方向開。

面對殘酷現實,但絕不喪失信心
領袖魅力是資產,也是負債。你性格上的優點也可能埋下了問題的種子,員工會自動過濾資訊,讓你接觸到殘酷的真相。

刺蝟原則
擁有核心事業、核心競爭力,不見得表示你們在這個領域是全球頂尖的公司。如果你們在核心事業上,無法達到全球頂尖的水準,那麼你們的刺蝟原則就不應該以核心事業為基礎。

強調紀律的文化
卓越的企業多半不是因為機會太少而餓死,而是因為機會太多,消化不良而敗亡。真正的挑戰不在於如何創造機會,而在於如何選擇機會。

以科技為加速器
當用對科技時,科技可以變成企業發展的動力加速器。「從優秀到卓越」公司的轉型從來都不是始於開創性的科技,原因很簡單,除非你知道與公司發展密切相關的是哪些科技,否則你沒有辦法好好運用科技。

飛輪與命運環路
從優秀到卓越的公司轉型往往遵循穩定的形態——必須先厚植實力,然後才突飛猛進。就好像推動巨大笨重的飛輪一樣,一開始,得費很大的力氣才能啟動飛輪,但是,只要朝著一致的方向繼續不斷往前推動飛輪,經過長時間後,飛輪累積了動能,終於能有所突破,快速奔馳。

要讓公司從「優秀」變成「卓越」,必須在想清楚企業發展的方向之前,應該要先把適當的人請到公司,並且請那些不適合的人離開。找到對的人之後,也不需要給他們答案,反而要拋出問題,不斷地問問題以了解真實的情況,並激發出更多的火花。

企業領導人最重要的事在於能看出哪個人應該放在哪個位置上最能發揮,並且能夠培養出最優秀的經營團隊,讓公司的策略經由優秀的管理人才分享洞見、共同討論出來。

企業也必須能夠讓員工花更多時間來觀注可能受到忽略的嚴重問題,而不需要擔心高階主管的感覺,並直接把殘酷的現實攤在這些高階主管眼前,重點在於企業營運上的問題,事實與現況才是應該全力觀注的關鍵。

典型的刺蝟作風,就是一旦掌握了單純的指導原則,就始終如一,徹底執行。擬定計畫,有系統地執行。把決定的目標,轉換成簡單而清晰的概念,成為指引抉擇的指導原則,那麼就擁有了自己的刺蝟原則。

GoodToGreat_Flying_Wheel

強調紀律的文化,旨在於訂定「不做的事」,將挑戰聚焦在選擇機會,而不是如何創造機會。在這個前題下要管理的不是員工,而是制度,制度的貫撤不是要推行暴政,其最終體現是在企業文化的朔造上。這些作為需要的不是聰明才智,而是革除舊習、不屈不撓的決心。

科技的引用是由上述各項所引領,單靠科技是無法讓一間公司蛻變成長,更可能造成大災難。

找這本書來思考,是因為其中的幾個重要觀點,非常符合目前手邊的組織變革工作,七月要向高層提出整體改造計劃,在計劃的設計之前,有必要預先整理清楚自己的思維方向,避免失焦或是空談的結論。

簡單記錄一下這本2001年最佳財經企管書籍,希望自己能夠順利完成公司交代的重要使命!

延伸閱讀:
關於柯林斯 from 遠流博識網
柯林斯觀點 from 遠流博識網

...Read More

2009年6月15日星期一

專案開發的溝通與管理

Team Coding原本並不認為團隊一定需要嚴格的紀律,後來才發現這是因為自己運氣一直不錯,遇到的團隊成員都很優秀,在深知團隊合作重要性的前題下,不需要任何規範大家就可以合作愉快,很輕鬆地就把事情處理得很好。

一個人可以海闊天空,兩個人需要溝通協調,三個人就需要組織管理。from 何飛鵬先生

筆者相信只要尊重每一個人,相信大家都是可以自我控制、自我管理的人,就可以發揮很好的合作效績,但事實上是,到後來仍然必須面對管理的問題,尤其公司營運愈是成功,建立管理機制就變成絕對必要了,因為愈是成功表示工作愈多,溝通的過程愈繁瑣,管理自然也就愈是複雜。

現在,筆者仍然相信尊重可以讓被尊重的人展現高度的自由控制、自我管理,但前題是,成員的選擇過程必須完善,而且一旦選錯了也必須快速反應,盡快在災害擴大前解除該員的相關職務。其實專案開發的過程,都是人的問題,人對了事情就對了,但這通常很難達成,所以一直以來都在思考一個問題:那有沒有辦法藉由規範或是流程的控管來減少問題的發生?

筆者認為,對於軟體專案開發的管理來說,關鍵管理方式其實只有兩項:Version Control 以及 Issue Tracking。Version Control 解決複數人員同時開發、共用而衍生出來的衝突問題,是一種在設計與開發過程中的共享機制;Issue Tracking 則是問題的追縱與溝通的記錄。

哪這兩種解決問題的方式是否真的有需要系統工具來實施?

關鍵在於做與不做,而不在於有沒有好工具!

Version Control 的重點在於是否有依照規範的作法進行管理,工具是輔助的,工具濫用亂用,結果還是一樣亂七八糟,到最後 Version Control System 就會變成 Source Code 的備份系統。

Issue Tracking 也是一樣,Issue 被記錄後,是否有進行討論、修正,並將整個過程紀錄下來才是關鍵,簡單點用 Excel 不是比較快?每天大家告報一下狀況,然後由特定人紀錄下來就好了,討論時就把 Excel 打開來看,逐項討論不是明確而清晰?

建立共識的重要性遠遠超過訂定規範!

規範的重點在於效度,而這通常與獎罰有關,但這不是筆者所贊同的策略,所以回到根本的問題,也就是人的問題,做事的觀念與作法便是唯一的關鍵了。

既然重點在於成員的想法與觀念,所以專案開始執行前的 Kickoff meeting 最是重要。除非組織已有慣用的系統工具或是習慣作法,否則應該在開發實際執行之前,將相關的行政作法、管理規範說清楚,同時務必取得共識,確認所有人都清楚知道這些規範,並且願意遵照辦理。這也是在組織作法尚不明確下,最能避免「意外」變成「必然」的一個作法。

開始前先讓建立團隊成員間的共識,有共同的語言、共同的作業流程,減少認知落差,才能讓許多不同的人共同完成一個專案!

...Read More

2009年5月18日星期一

Android 在 Windows 的開發環境設置

考慮到公司未來的開發需求,Android 在 Windows 平台的開發環境設置變成一件必要的事,一方面自己利用機會熟悉這個技術開發環境,一方面也讓同仁可以快速地設置必要的開發環境,避免無謂的撞牆事件,特地將安裝過程紀錄起來,希望能夠讓大家很容易地安裝設定,集中心力在技術問題的開發研究。

eclipse_avd

下載必要的軟體:

  1. Java SE Development Kit:jdk-6u13-windows-i586-p.exe
  2. Android SDK:android-sdk-windows-1.5_r1.zip
  3. Eclipse:eclipse-jee-ganymede-SR2-win32.zip
  4. ADT(Android Development Tools):ADT-0.9.1.zip

安裝過程:

  1. JDK 安裝,直接使用預設值即可,一路到安裝完成。
  2. Android SDK 安裝,解壓放到C:\下即可。
  3. 安裝 Eclipse,解壓放到C:\下即可。
  4. 安裝 ADT:
    1. 請先開啟Eclipse,選擇「Help」>「Software Updates…」會彈出「Software Updates and Add-ons」視窗。
    2. 請選擇「Available Software」分頁,按下右側的「Add Site…」按鈕,會彈出「Add Site」視窗。
    3. 按下右側的「Archive…」按鈕,選擇之前下載的 ADT-0.9.1.zip 檔案。
      :網路資訊顯示要填入下列網址由網路直接下載安裝,但筆者怎麼試都失敗。(https://dl-ssl.google.com/android/eclipse)
    4. 「Available Software」分頁畫面會出現 Developer Tools 的選擇,展開後其下有 Android DDMS 及 Android Development Tools,直接勾選後按下右側的「Install…」按鈕。
    5. 安裝完成後會建議重新開啟 Eclipse,就請照辦吧~

環境設定:

  1. 開啟 Eclipse,選擇「Windows」>「Preferences」,會彈出「Preferences」視窗。
  2. 選擇左側「Android」項目後,於右側視窗的「SDK Location」項目選擇Android SDK 安裝目錄,筆者的是C:\android-sdk-windows-1.5_r1。
  3. 將 Windows 開始功能表中的「命令提示字元」做個捷徑到桌面上,然後在桌面捷徑圖示的滑鼠右鍵選單中擇選內容,於彈出的「命令提示字元 內容」視窗中將開始位置改為「C:\android-sdk-windows-1.5_r1\tools」,這是為了日後方便直接執行 adb 指令使用(Android Debug Bridge)。
  4. 製作 Android 模擬器(Android Virtual Device),點擊剛剛建立的在桌面的命令提示字元捷徑,輸入:
    $ android create avd --target 2 --name avd15
    即會建立第一個名稱為 avd15 的 avd (Android Virtual Device),之後開發的程式即可直接在這個 avd 中執行。

建立官方的 ApiDemos Project 方便學習參考:

  1. 開啟 Eclipse,選擇「File」>「New」>「Android Project」會彈出「New Android Proejct」視窗。
    new_android_project
  2. 在 Project name 中填入 ApiDemos。
  3. 在 Contents 中勾選「Create Project from existing source」,然後按下右側的「Browse…」選擇 C:\android-sdk-windows-1.5_r1\platforms\android-1.5\samples\ApiDemos
  4. 在「Build Target」中選擇 SDK 版本,筆者是勾選 Android 1.5
  5. Properties 應該會自動填入如畫面的所示。按下 ok 即可建立ApiDemos Project。
    new_project
  6. 在 Eclipse 的 Package Explorer 會出現 ApiDemos 這個專案,在 ApiDemos 的右鍵選單中選擇「Run As」>「Android Application」即會自動執行 Android Virtual Device,並將這個專案安裝到 Device 中。
  7. 下圖右即是「ApiDemos」>「Views」>「Date Widget」>「Dialog」中的「change the time」執行視窗。

apidemos

延申閱讀:
蓋索林(gasolin)所寫的《深入淺出 Android -- Google 手持設備應用程式設計》
史丹利部落格《Android模擬器adb命令介紹》

...Read More

2009年5月11日星期一

Free Software is not Freeware!

open_source

日前在噗浪上「硬是要學」兄發了一噗(原噗連結):

有人說:「新軟體真的比舊軟體好,那舊軟體過了一定年限為何不開放讓人使用」...請問每天 coding 的朋友,這段話看了會讓你熱血沸騰嗎?

這是筆者當時的回應:

再舊的東西用對地方就是好東西,支持開放源碼不表示就得免費提供,Open Source 和 Free software 本來就是兩件事的啦。

其實 Free Software 應該要修正為 Freeware,而且回得也不是很完整,想想還是特地寫篇文章來閒扯討論一下~

首先還是先進行一下名詞定義。

開放原始碼 Open Source(Wiki:中文English:軟體散佈模式的一種,指軟體散佈時需提供可取得的原始碼,並開放某些權利。須特別注意因為公開原始碼時所附加的限制條款,通常「公開原始碼」與「開放原始碼」是不一樣的,開放原始碼有諸如自由再散布(Free Distribution)等定義(詳情請參考前述 Wiki 連結)。

自由軟體 Free Software(Wiki:中文English):根據自由軟體基金會(Free Software Foundation,FSF)的定義,自由軟體是可以不受限制地自由使用、複製、研究、修變和散佈的軟體,通常讓軟體以「自由軟體授權協議」(GPL - GNU General Public License)的方式發佈,以及公開的軟體原始碼。與自由軟體相對的是非自由軟體(Proprietary Software),也常被稱為私有軟體、封閉軟體(其定義與是否收取費用無關)。

免費軟體 Freeware(Wiki:中文English):泛指一切不用金錢買回來的電腦軟體。

其中最常被誤解的就是自由軟體(Free Software)與免費軟體(Freeware)。

自由/開放原始碼的目的在於透過原始碼自由散佈的開放性,讓全球的軟體開發者得以取得原始碼,並依個人興趣、時間投入開發工作,使軟體功能更臻完美。「Free」這個字所代表的是「自由」,亦即軟體自由傳遞的開放性,而非成本上的「免費」,以最常被引用的自由軟體授權模式 GPL(GNU General Public License)為例,其中即明確指出,為產品提供額外保固以及為實體傳輸產品而進行收費是被允許的,也就是說在 GPL 授權下,營利來源主要來自於服務的提供,例如產品的導入、後續的維護服務等。至於其它授權條款如 BSD(Berkeley Software Distribution)或 MPL(Mozilla Public License),則亦允許藉由自由/開放原始碼軟體開發專屬軟體,因此除上述的服務模式之外,同時也增加了產品銷售的收入來源。

重點---->Free Software is not Freeware!<----重點

關於 Open Source 的概念,筆者找到一篇來自 o3 magzine 的文章:《Introduction to Open Source》,作者 John Buswell 特別用了可愛企鵝的示意圖,讓讀者可以更容易理解,推薦給大家參考。

有了這些基本概念,我們再來讀讀元毓說《針對「一則充滿錯誤觀念的留言」的回應》

商業利益最大化是企業的使命之一,微軟只要以合法的方式賺錢就是對的,如果要提到貪婪,要討論道德問題,那全球比 Bill Gates 捐錢多的人可是用手指算得出來的。

需求之所在才是利基之所在,「市場供需」才是影響價格的因素,名牌如果沒有人要買,也是會關門大吉的,就是因為有需求存在,才會帶動商品的價格上漲,房地產更是明顯的例子,只要有需求就會有價格上漲力道,這才是關鍵點。

微軟的暴利就是來自於消費者願意買帳,事實就是這樣。一些微軟作業系統中直接附加的軟體才有壟斷的疑慮,例如瀏覽器、音樂播放軟體,以及最近聽說很有可能 Windows 7 會直接搭載的防毒軟體。

該文章也提到了「剝削」,這是個很嚴重的字眼,正如之前在網路文章中看到不抽煙的人認為被抽煙的人剝削了一樣,筆者認為這是個很無意義的議題。在自由的台灣,很多人本來就可以選擇不被剝削,問題在於到底是「沒有辦法選擇」、「不願意選擇」,亦或是「已經選擇了」?人在評估事情時本來就會有諸多考量因素,例如不認同公司的規定,那要嘛離職、要嘛閉嘴,但有些人卻會繼續待在公司、然後繼續抱怨,接著就說被公司剝削…事實上呢?說真的,筆者一直想不通、也不想去問清楚這種邏輯。

舉個例來說,用 OpenOffice 有比用 MS Office 難用嗎?有影響作業效率嗎?筆者就不覺得,但很多人都說不習慣。重點來了,這是「不習慣」而不是「不可替代」,所以請為了自己的使用方便繳交軟體使用授權費,而這本來就是天經地義的道理。

整個看來,筆者的看法和元毓說的作者 alanc 兄還蠻一致,筆者尚無法一窺元毓說這篇《針對「一則充滿錯誤觀念的留言」的回應》寫作的背景始末,所以僅就文章所提及的部份來討論,另外,alanc 兄的法律專業也不是筆者所擅長,法律問題還請大家參考元毓說的相關文章。

筆者是支持 Open Source 與 Free Software 的,但這不表示就因此而「為反對而反對」,只要觀念正確就不會流於意識型態的爭論,意識型態的鬥爭最是容易變成無意義的內秏,這扯遠了,回歸正題…

支持自由軟體並不表示就反對商業軟體,這是兩件事,大家不都是使用 Windows 的同時也使用 Unix-like 的系統。支持 Open Source/Free Software 是為了讓技術能夠更自由地流通,愈是自由的流通愈能刺激技術的發展,專利有年限也是基於這個考量,否則關鍵技術一旦被特定人長期持有,世界的進步也就被迫延緩了。

請大家支持 Open Source/Free Software,但請也尊重商業軟體

延申閱讀:Why “Free Software” is better than “Open Source”中文英文

...Read More

態度對了人就對了,人對了事情就對了!

這段時期很忙碌,很多事情都在意料之外發生,好不容易找到時間來重新審思這整個過程,發現很多值得記錄下來,讓自己能夠更加成長,特別撰寫此文一方面整理整個思緒,一方面加強自己的記憶。

TeamWork

這段時間筆者在工作的遭遇到的問題,突顯出筆者的工作團隊中,某些個人的問題與行為影響到整個團隊的運作,或許這些人在並沒有想到自己的行為對於整個團隊會有這麼大的影響,筆者在顧及這些同仁的顏面下,尚無法有效讓這些同仁正確理解團隊合作的許多觀念,個別約談或許是方法,但這也是最後的處理方式了。

蕭萬長副總統接受訪問題說過如下的一段話:

默契有了,就可能建立良好的團隊,小到公司,大到一個國家,Team Work 的精神發揮出來時,就會是一加一大於二。

很可惜,筆者並沒能處在一個具有默契的團隊中,筆者團隊中資深人員的個人行為對整個團隊的運作產生極大的負面影響,但筆者想知道的是怎麼繼續向前走,怎麼讓團隊繼續成長,繼續讓這些人理解過去的行為造成的負面影響,以及能夠怎麼改善並求追自我成長。

1062期商業週刊有提到一個概念:開發式創新。

摘錄部份內容:

打破企業圍牆,把使用者、供應商、創業家,甚至競爭對手,都變成公司外圍的創意平台,就可能找到新的商機。

克服「非我發明症候群」(Not invented here syndrome)。內部的研發人員不信任外來的技術,基於自我保護,員工花了很多力氣去證明外來的東西不管用。

跟上市場的步伐,研發的新角色將是知道上哪去找到最好的人才與創意,並將外部的創新整合到企業系統,創造出最貼近市場的產品。

文中提到的「非我發明症候群」系指許多公司內部對於使用外界創新與技術可能抱持排斥心態,筆者在此借用此一概念解釋工作上遇到的狀況。

從企業經營的角度來看,花費一樣的成本,能獲得最佳的投資報酬率才是營運重點,人事成本當然也是這樣,企業主並非沒有良心善意,許多同仁都是被公司長期照顧的,否則就不會有彼得原理的產生。

一個和「非我發明症候群」很類似的情況是,有些資深同仁在面對新進同仁時(這邊的新進非指資淺,單純指進入公司的時間早晚),或許擔心被比下去而有自我保護的行為,很容易變成在技術細微末節上爭論,而且往往在自己的意見並非最後結論時,執行工作時會採取消極的不合作態度,例如:不盡心處理甚至拒絕接受任務指派、或是在執行過程中抱怨客觀因素的影響。

其實擔心害怕被比下去往往是成長的開始,重點在於這種心理壓力轉化出來的行為是什麼。

有的人反省自己的弱點積極面對,有的人則被情緒打敗行為出現偏差,先是影響自己的績效,再嚴重點就開始影響其他同仁的工作。像是前面提到的,對於一些細微末節的事物反覆爭論,很明顯地想在公開討論的場合下,壓倒其他人的論點,就像整個人佈滿了刺,看不到事物的真相,只想到自己的論點是否被認同。

另外團隊中有些人並沒有很大的企圖心,只是想追求安穩的人生,然而在企業成長的同時,一旦停下腳步便會被新進同仁超越,所以是不可能一方面不成長,另外一方面又想保持自己在公司中的既定狀況,尤其是企業成長的速度愈快,這樣的情況就愈明顯,縱使組織允許這樣的人存在,當事人在其中的地位也無可避免愈來愈低,早晚會變成被較晚進公司的人管理的情況,如果沒有積極前進的企圖心,那很抱歉,請做好被人指揮管理的心理準備。

這個團隊沒有默契的原因,是因為團隊目標與個人目標並不一致,很明顯的一部份人充滿鬥志,積極追求成長與績效,另外少數資深人員則只想守著既有的地位安穩渡日,或是擔心被淘汰卻用了錯誤的方法,結果是跟不上整個團隊前進的速度,甚至造成整個團隊發展的障礙。

關鍵其實並不在於學經歷,而是態度。

態度對了人就對了!人對了事情就對了!

在好不容易找到時間休息的這個週末,蒙長輩眷顧得到一些提點,長輩特別說了一段話,筆者感觸很深,這邊特別也記錄下來。

人要學會放下!

長輩的意思是,人要能夠放下才能跳脫出來觀想整個事情,也才能夠讓自己成長。

像是放下面子問題,才能客觀看待人,看待事情;放下問題,才能離開思維的困境,從外向裡看才能找到盲點,再回到問題的境地中,自然會有不同的想法,原來的問題就比較容易找到不同的處理方式。

感受很深,有機會想讓同仁知道這個觀點,或許能讓大家有不同的思維,找到重新前進的方式與動力。

...Read More


 
^

Powered by Blogger Original template by UsuárioCompulsivo Revision by Fried Eggs Rice
Original Washed Denim by Darren Delaye
Creative Commons License