Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2007年11月27日

「少數服從多數」還是「多數暴力」?

這個話題挺有趣的,是「少數服從多數」呢,還是其實是「多數暴力」?

記得應該是小學時,學校為了讓學生們開始有所謂的「民主」觀念,開始教導「少數服從多數,多數尊重少數」這樣的觀念,小一時幹部應該會由老師指定,小二或小三之後幹部就開始用「投票」的方式進行。隨著年紀的增長,越來越多「表決」的事件開始發生,例如贊不贊成該週小考取消?某個自習課可否臨時改體育活動?校外教學要去哪裡等等。

大概自小五小六或國中時,學校課程開始教到自然科學與物理化學,開始介紹到像是牛頓、伽立略等人,這個時期我們學到了,原來在十六世紀以前,人類是認為「地球」是宇宙中心,地球是平的,太陽從東方升起,從西方落下(註1)。直至「哥白尼」、「克卜勒」、「伽立略」等人相繼提出新的天文觀點,質疑過往認為地球是靜止不動的宇宙中心,甚至伽立略還「激進」的提出地球應是繞著太陽而轉,這樣激進的言論不能被教會所接受,伽立略因此終身被禁錮在家中不得與外界接觸。

註1:西元二世紀的「托勒密」認為地球為宇宙中心,其他的天體分別固定在許多不同的球面上,繞地球作圓形運動。


所謂的民主便類似這樣,當你與多數人的意見不同,即使若干年後證明你是對的,但在當時你就是錯的。只是較為先進的民主觀念,希望能夠尊重少數人的聲音,大抵是很多事情並不是明顯的對或錯,只是多數人比較傾向於某種做法或看法,在能力所及,如果能讓少數不同意見的人也能夠有所滿足自是最好。就好比說即使紀律嚴明的軍隊也會特別為素食者另行準備餐點,更別說一般人的宴客也常見會為素食者準備特別餐點。

但是多數暴力是怎麼回事?簡言之就是多數的既得利益者僅為自己的便利而行事,並未去考慮其他少數者應有的權益。

偶爾我會搭乘捷運上班,正好我上班的路線與尖峰時段的人潮方向相反,更詳細的說,我上車地點本身就是個商業區,因此從捷運站出站的人潮相當的多。捷運站在地上畫有進出站的動線,但上班尖峰期,出站與進站的人數比例可能是 50 比 1 ,甚至是 100 比 1 。也就是說突然間湧出 100 人出站,同時卻可能只有 1~2 人進站。即便四部手扶梯動態的調整成三部出站一部進站,但通到卻總是塞滿出站的龐大人潮,大約八成以上的出站人潮無視於地上的動線,大辣辣的逆向走在應屬進站的動線上,大概心想反正沒什麼進站的人嘛,有何不可。僅有大概一至二成的人遠遠的若看到有進站的人靠近,會盡量空出通道讓進站的人得以行進。這就是一種多數暴力的表現。

多數暴力,大概是群居動物的天性吧。偶爾電視轉到 Discovery 或是國家地理頻道,看到拍攝野生群居動物的生態,有時就會看到某些較弱勢的個體被群體所排擠,搶不到較暖的地方避寒,或是搶不到足夠的食物,漸而變成體弱多病,當遇上獵捕者時,則往往成為必然的犧牲品。

想要改善,還是只能盡量自發的去關懷周遭,注意他人的感受,在行有餘力時多給其他人一些空間吧。這種風氣是要靠群體養成的。

2007年11月25日

何謂專案

有些人對於專案的定義不是很清楚,甚至容易與常態性的管理事物混淆在一起。簡單的說,專案是指在一定時間內,為了完成特定目標的組織活動。好比說一家做進出口貿易的中小企業,如果老闆擬定了一個目標,要業務與相關行銷人員針對年終至隔年農曆過年期間進行某一產品的進口促銷方案,這就可以被當作一個專案來看待。

因此,專案包含了以下的幾個特性:

  1. 明確的目標
  2. 特定的時間(明確的開始與結束時間)
  3. 非重複性(非日常例行姓事務)
  4. 特定的人員
視應用的領域不同,專案的複雜度與組成要素也會有不同。小至學校裏的各班可自由發揮的校慶園遊會,雖比較像個活動事件,但也可用專案的角度來加以管理;大至一項新產品的開發至成品產出,或是一棟摩天大樓的規劃至完工,都可用專案管理的方式加以有效率的管控。

哪些事務不屬於專案管理的範疇?例行性事務,例如公司總務或行政人員每日每日的例行性事務,發放薪水、三節禮金、勞健保管理等;系統管理員每日的系統維運工作;學校老師年覆一年的教學工作等。簡言之,屬於重複的例行性工作事務並不屬於專案管理的範疇。

如果看一個產品的某一版本,他的規劃直至產出的過程是一個專案;但如果把焦點放在這個產品線是會持續延續下去,例如 2.0 版開發將至最後完工階段,便會開始研發下一個 3.0 的新版,那麼這個產品線本身應屬於一個計畫(Program)而不是專案。

2007年11月15日

是文化入侵還是全球化的常態?

生活周遭有越來越多的文化入侵的跡象出現,但是,究竟是文化入侵,還是全球化的常態之一?

當你在跟別人允諾你一件事情時,過往的人或許會說「好的」,但你說「OK」好像也並不會怎樣特別。當你發現你統一發票中獎了,你或許會說「太棒了」,但你如果說「wonderful」就似乎有點刻意了。有些詞語是隨著各國之間的文化交流越來越多之後,便會逐漸的習慣在日常生活的詞語裡頭夾雜著來自其他國家或地區的特定詞語。

生活在台灣這片土地,外來用語的逐漸普遍,似乎多數的人感受不深,但喜愛看日劇的人,或是有學日語的人,便會知道現代日語裡有相當多的外來語,有些外來語在日本統治台灣的時期甚至沿用至今,很多人還誤以為是台語。例如「機車」,你說「歐都麥」也不太有人會聽不懂,但其實他是日語裡的外來語,原是英語的「autobike」。

自從台灣解嚴之後,各地方語言開始重新被重視,台語也有相當數量的用語被「國語化」或者說生活化了。生活周遭會經常聽到國台語夾雜的對話,多數的人也習以為常了。

然而,玩電腦的人大概是較早面對來自對岸用語的其中一個族群。過往有不少中文的資訊來自對岸,或是有不少的軟體被翻譯成簡體中文,早在 Intel 80286 的倚天中文時代便已經有簡體中文轉換繁體中文的程式了,於是,只要簡單的轉換內碼,簡體中文便可用繁體中文對應的內碼與字體來呈現。例如「工厂」可以被正確的轉換為「工廠」,「电视」轉換為「電視」等。

但有些詞語是在不同的文化背景之下衍生出不一樣的慣用說法,或是有些是翻譯自國外的詞語,翻譯的結果略有不同。舉例來說,常見的「Default Value」台灣慣用「預設值」,大陸的翻一則是「默认值」;「password」兩岸雖都說「密碼」(密码),但大陸那邊也有說「口令」的;Windows XP起安裝後必須要「Activate」,台灣翻譯成「啟動」,大陸說「激活」;當要建立一個新的文件時,台灣說「新增文件」,大陸說「创建文档」......

對於說慣、用慣「預設」、「啟動」、「新增」、「檔案」等這些詞語的台灣人,看到「默认」、「缺省」、「激活」、「创建」、「文档」等字眼,應該多少會感到不習慣。

還記得給年前我初次到大陸出差,那邊的同事對我說要請我向上面申請一樣東西,他連說了數次我都全然不知他在說什麼東西,我甚至請他乾脆講英文罷了,最後才知道他是說「U盤」,也就是早期我們說的拇指碟(現在很少這麼說了),或是隨身碟。

現在隨著兩岸開放,許多電視劇往大陸那邊發展,兩岸的演員合作來演,已經分不清究竟屬於台灣電視劇或是大陸電視劇了。也因兩岸的文化交流越來越頻繁,更多大陸那邊的用語開始出現在生活周遭,好比有些新聞主播開始把「火紅」放在嘴邊,過去台灣是不會用「火紅」來形容一個藝人正值頂峰時期,通常是形容某某人很「紅」。在大陸那慣用「很火」,等同於台灣這邊說的「很紅」。

我著實想了好一會,這是文化入侵還是全球化的一環?即使像是全球化的一個部份,但怎麼想也覺得與「外來語」不太相似。外來語,直覺會覺得是近似於「歐都麥」、「韓都魯」(方向盤,handler)、「OK」、「soga」等這一種類型,但來自大陸那邊的用語融合進台灣這的日常生活,卻怎麼也不像一種外來語。想了想,如果說把大陸的用語,與國台語混用的情況作個比較,卻突然發現這樣的相比挺相似的。

說慣台語,或是處在很多人講著地方語言的環境,自然而然對於國台語夾雜的狀況能夠適應。一個原本不太會說台語的人,久而久之也會習慣這種國台語混用的情況。大陸用語出現在台灣這邊的日常生活中,情況挺類似的,如果就把他視為是某個地區的慣用語言,簡言之,把他視為方言的一種,似乎就很能理解了。

2007年11月14日

店內人氣與營收之間的關係

一些可讓顧客久留的商店,例如餐飲店、書店等,人氣的多寡,與其營收不見得成等比例。其中一個因素在於顧客的消費額度,以及顧客的流通率。

設想一個步調很快的早餐店,姑且不看外帶餐飲的顧客,若這家早餐店在店內用餐的顧客,平均都是大約 10 分鐘就會離開,假定店內共有 30 個座位,則一小時內大約會有 180 位顧客,也就是說平均每個座位在每小時可以服務 6 位顧客。

如果對比一家咖啡連鎖店這種顧客往往會喜歡在店內待較久的店,同樣我們以早餐的熱門時段來作推估,假定顧客平均待 20 分鐘後離開,也就是說每個座位平均每小時可服務 3 位顧客,若該店同樣有 30 個座位,則一小時內僅能服務 90 位顧客。

如果說你今天開了一家店,一開始客人不熟悉你這家店,但逐漸的你的知名度越來越大,客人也越來越習慣與喜歡你這家店,直到有天你店內開始在黃金時段以及前後一~二小時之間高朋滿座,先別高興的太早,也別高興太久。要分析一下營收是否真的增加了。

我有時候看到有些店,顧客可能進門只點個基本餐,然後就在裡頭待上個 2 ~ 3 個小時,如果說是人少的時段也就罷了,若是尖峰時段,那將會影響到可服務的客人數,自然也就影響到總營收量。最明顯的例子是速食店這種屬於半開放式的餐飲店,顧客在一樓點完餐就到二樓以上的樓層用餐了,結帳完畢之後,店員將不需要再為顧客進行服務,也不會去理睬顧客。則當顧客在店內待很長的時間,那麼當座位不足時,想要內用的顧客便將受到影響。

在鬧區或是補習班密集的地區的速食店經常是一位難求,仔細一看,會發現很多學生在裡頭看書,桌上僅有一杯飲料,這些學生可能一待就會待上三小時。類似這種例子,將會是營收的一種盲點,即看似高朋滿座,但實際的進帳卻有限。

因此,假若在鬧區開店,要斟酌一下希望可以讓顧客待多久。或者說,必須要好好評估總成本,然後去計算平均每位客人的消費額,再比較平均每小時必須要能夠服務多少顧客才能攤平成本,以這樣的角度思考應該怎樣規劃店內的桌椅擺設,以及店內的氣氛。

如果說希望客人只是到店用餐後就離開,並不希望客人久留,那就應避免讓店內氣氛過於悠閒。如果希望提供一個可以讓客人久留的地方,那麼不僅是店內應舒適之外,也要好好考慮提高餐點的單價,必須有類似「出租空間」的概念,才能攤平成本。

2007年11月12日

差異版本翻譯

之前提過關於同步翻譯(不是同步口譯)的主題,在這裡繼續提同步翻譯的想法。不過我想到其實有時這也是一種差異版本翻譯的概念。

翻譯領域裏藉由電腦輔助翻譯軟體(Computer-Aided Translation,通常簡稱 CAT)以及翻譯記憶庫(Translation Memory)的技術,可以有很多方式處理新舊版本之間既有翻譯的沿用。

舉例來說,假定以下為檔案A在1.0版時的前10行:
properties.A.01.name=File
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
#
properties.B.06.name=Open
properties.B.07.name=Save
properties.B.08.name=Save as
properties.B.09.name=Close
並且其對應的中文翻譯為:
properties.A.01.name=檔案
properties.A.02.name=編輯
properties.A.03.name=檢視
properties.A.04.name=格式
properties.A.05.name=工具
#
properties.B.06.name=開啟
properties.B.07.name=儲存
properties.B.08.name=儲存為
properties.B.09.name=關閉

當下一個 1.1 版新增了一行,而使得前11行變成下面這樣:
properties.A.01.name=File
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
properties.A.06.name=Insert
#
properties.B.06.name=Open
properties.B.07.name=Save
properties.B.08.name=Save as
properties.B.09.name=Close

我們的目標是既有的翻譯要能夠盡量的被沿用,以程式開發者的角度來看,假使比對 1.0 與 1.1 之間的差異,事實上是在第5 及第 6 行之間被新增了一行,其他部份並沒有異動,理論上在中文的翻譯檔案裏只需要對應的插入這新的第六行的中文對應翻譯即可。於是 1.1 版的中文應如下面所示:
properties.A.01.name=檔案
properties.A.02.name=編輯
properties.A.03.name=檢視
properties.A.04.name=格式
properties.A.05.name=工具
properties.A.06.name=插入
#
properties.B.06.name=開啟
properties.B.07.name=儲存
properties.B.08.name=儲存為
properties.B.09.name=關閉

不過事實上並沒有這麼簡單。版本之間的差異往往不會只有數行的新增這麼單純,複雜時數十行的新增、刪除、以及異動都可能有,目視差異來進行手動的版本同步將不再可行並且易有疏漏。

不過,暫且沿用上面這較簡單的例子,一些翻譯的技術可以辨識出既有的翻譯對與新的來原是否相符,若相符則可沿用既有的翻譯。

然而,為了使翻譯能夠更精確,能夠處理相同的來源文字在不同地方具有不同的翻譯,部份的技術採用了上下文比對的方法,以滿足來源文字與目標文字一對多對應的需求。

簡單來說英文的 State ,查一查字典,它在不同地方將可能代表了「州」或是「狀態」。在地址輸入的欄位中把 State 翻譯成「狀態」可就不妙了。上下文筆對的方式便可以使翻譯配對能夠有更廣的選擇。

然而,也因為上下文比對的採用,像上面再簡單不過的例子,也可能導致一些既有的翻譯無法被配對而採用。某些上下文筆對的方式,是取前、後一至數行的文字作為參考文字,因此以下的兩個例子會被視為不同的文句(灰色文字表示為參考的上文或下文):
A:
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
#
B:
properties.A.02.name=Edit
properties.A.03.name=View
properties.A.04.name=Format
properties.A.05.name=Tool
properties.A.06.name=Insert

於是,僅僅因為新增了 Insert 這一行到第六行,將可能導致第四行被認為在新的版本裏上下文與舊版不同,而既有的翻譯配對將不會自動被採用(被視為不是完美配對 Perfect Match)。即使它的相符率可能僅僅是降為100%或是99%,但是這也將可能導致額外的工作量增加。

過去提過的同步翻譯,或是協同翻譯的想法,其實是在討論像這種差異版本之間的翻譯應該怎樣來處理較好。以程式開發者的角度來看,當同時有多人在開發同一套程式時,開發人員經常要做的一件工作便是程式合併(code merge)的工作,必須進行版本間的差異比對,然後將自己的版本與另一人的版本、或是與主版本進行合併。

簡單的說,如果過去我曾經複製了檔案A的 1.0 版,一個星期後檔案A異動至 1.1 版,我可以藉由比對 1.0 與 1.1 之間的差異,發現是在第六行新增 Insert 這一筆,則我可以將這差異加入我手上的 1.0 版的第六行位置,而達到與 1.1 版同步的效果。

目前常見的翻譯軟體對於這種差異版本的翻譯沿用技術並不全然是如上述這般,這導致其實我們僅僅需要針對「
properties.A.06.name=Insert」這一行進行翻譯,然後加入中文版裏,變得更加複雜。

這問題大致是因為現有的翻譯技術僅是基於翻譯對(Translation Pairs)來進行比對,頂多再加上該翻譯對的前後文作為參考資料,但並沒有真正去記錄檔案版本間的差異。

過去至今已有很多程式版本管控的系統,諸如 RCS (Revision Control System) 、 CVS (Concurrent Versions System) 、 SVN (Sub-Version) 、或是微軟的 Source Safe 等,儘管有些只是單純的版本管控,有些是為了可應付多人同時開發的版本管控,但大體而言都解決了版本間差異的管理。翻譯的技術如也能處理這種版本間的關連性,應該可以為翻譯的效果帶來不錯的改善。

簡而言之,上面提到的例子理想上僅需翻譯「
properties.A.06.name=Insert」而得到「properties.A.06.name=插入」後,藉由 code merge 的概念再次加回目標語言中。

如果有次版本開發概念的人應該更容易理解。概念上就好比在程式的主版本支幹上,另行建立一個分枝(建立另一個語言的分枝),每當主支幹有異動時,藉由比對主支幹新舊版本的差異,將差異同步至分枝裏,而達到與主支幹同步的目的。

2007年11月9日

軟體平行/同步/協同開發下的軟體翻譯工程

6/19/2007


過往比較常見的軟體翻譯工程,普遍鑑於原始版本 (source version) 已經完成或是接近軟體開發的最後階段,才會開始進行軟體的翻譯工程。對於大型商業軟體而言,由於軟體開發週期常,加以引用不少先進軟體開發技術,當軟體開發已達80%左右的完成度時,多數的規格以逼近底定,此時不太會有新功能的引進,因此諸如操作流程、界面、功能呈現等皆不會有大的變化,在這個時期提前開始進行翻譯工程,即使在最終 RC (Release Candidate) 版本仍有外抽字串的變動,也僅是小幅度的變動。


在這種傳統的開發模式,亦即非平行開發 (parallel development) / 同步開發 (concurrent development) / 協同開發 (collaborative development) 的模式下,翻譯工程是基於來源語言 (source language) 是處於穩定狀態下來進行的。因此,即使在軟體完成度僅達 80% 便開始進行翻譯,直至最終軟體邁進 RC1 甚至 RTM 版本,之間的來源語言頂多只會有小幅度的變動,例如低於五次的小改版。

在此類來源語言處於一個穩定的狀態下,翻譯工程常見的是在第一次進行全面翻譯,當翻譯完成時,會建立翻譯記憶庫 (translation memory) ,則之後每次的小改版,依舊拿新的來源語言版本來進行翻譯。藉由翻譯記憶庫的對應 (mapping) ,未有變動的字串將可獲得 100% 的對應翻譯,則翻譯僅需針對變動字串以及新字串來進行即可,篇幅以及工作量將會很小。

試想,假設當翻譯工程開始進行,直至最終的 RC 或是 RTM 版本之間,來源語言有太多次的變動,例如多達十次以上的變動,或是週期性的,每週甚至每天皆有一個變動,並且希望翻譯可以盡量跟上來源語言版本,那麼既有的模式便會變得過於煩瑣、擾人、且不太實際。

另一種狀況,若是翻譯工程在軟體開發的很早期便開始進行,例如在軟體開發完成度達到 50% 便開始,加以期間的變動相當頻繁,且希望翻譯的目標語言可以盡量與來源語言版本同步,那麼翻譯工程勢必得思索一個更有效率的方式來進行。

舉一個例子,當第一次進行翻譯時,假定此時是基於 Rev.010 來進行,並且此時來源語言共有 1,000 行(假定每行對應一句來源語言),翻譯進行了一週完成,此時來源語言版本已更新至 Rev.011 ,並且新增/異動了 10 行。姑且以每週會產出一個新的版本 (Revision) 並且預期每週平均會有 10 行的來源語言字串的異動,那麼意味著每週進行一次的翻譯工程,其實只需確保這異動的 10 行能夠同步至翻譯的版本。若採用傳統的模式,則每次皆是進行約 1,000 行的自動翻譯(自翻譯記憶庫找尋已有的對應),然後再找出異動的字串來進行翻譯,以其達到與新的來源語言版本同步。

如果採用另一種方式來進行,即利用比對工具,將 Rev.010 與 Rev.011 之間的差異匯出,只針對差異進行翻譯,然後將翻譯完成的差異,匯入原已翻譯好的目標語言版本 Loc.Rev.010 ,則達到與 Rev.011 同步的結果,因此可稱為 Loc.Rev.011。這樣的模式,僅需要針對差異來進行翻譯,而不須頻繁的針對 990 句不會異動的字串一再的進行重新翻譯(自翻譯記憶庫自動比對)。

業務的外移

6/11/2007

企業為什麼要把業務委外?

先回頭想想自己家裡有沒有哪些業務算是委外了。家裡有哪些工程是比較困難的呢?油漆粉刷、冷氣安裝、衛浴設備更新、熱水器安裝......通常這些工程我們會請店家來進行施工。過去主要是因為技術門檻較高,不得不請專家來進行。隨著人工越來越貴,另外加上自動機具越來越普及, DIY 風潮開始風行,較為簡易的像是粉刷、實木地板拼裝等,已經有不少人開始自己著手進行。前提自然是要有時間,外加有這樣的興趣,並不單單為了省錢。

上面看似舉了一個反例,其實,再仔細想想,自己周遭有沒有哪些事情,在過去五~十年以前,多半都是自己來的,現在卻逐漸變成「委外」了?肯定有的。諸如洗衣、燙衣、裁縫、三餐、甚至是住宅清掃。不少雙薪的夫婦,由於上班皆必須穿著正式西裝或是套裝,而這些衣服基本上自己處理挺為麻煩,因此多半送洗,當然這麼做的人一方面也是經濟負擔上較輕,以金錢換取時間;三餐呢?試想,老一輩的人,早餐在家吃,午餐是早上會是前一夜準備的,晚餐依舊回家吃,等於三餐都吃家裡,而現在有多少上班族,甚至三餐都在外吃!?那麼,把外食視作個人餐飲委外,是不是一個合理的說法呢?

企業為什麼要把業務委外?假設一個重視整體產品品質的公司,逐漸發現到長期雇用專人來編寫產品使用手冊,似乎有點負擔不了了,不管是手冊量越來越多,或是因為行銷國際的關係,使得手冊必須編寫多國語言,假設依舊自己編寫的話,勢必得要聘請更多的專人來負責。編寫本國語言的手冊也就罷了,一個文筆不會太差的專科生可能就可以勝任,但是要編寫其他語言的手冊呢?至少得聘請個大學外文系生,還不見得能寫的一手通順的文章,工資比起專科生馬上貴上許多。更別提還得寫多國語言!這時怎麼做呢?請翻譯設翻譯吧!這就是委外的一種了。

很簡單的一種想法,當你用自己的時間與人力來作,對比外包給其他人來作,省下來的金錢比起你自己做來的多,或是省下的時間你可以產出更多的產值,那就值得外包。

舉個例子,一個知名律師假設在其下班後兼差沒有什麼疑慮的狀況下,單單的法務諮詢每小時以500元計(這真的已經是很少的了),試想,這位律師週末是要花八小時來打掃家裡上上下下,還是花個兩千元請人來打掃,然後自己去做這法務諮詢,扣除雇傭花費,還可淨賺2,000?

業務的外移,如果不是為了省更多的錢,那自然是不需要去考慮的了,誰都想要自己一把抓,因為總是自己親自參與才會確保事情能更盡量如己所意,交給其他人,不見得能符合自己的想法。但是,只要藉由一些有效率的管理方式,便可讓事務快速的交給專業人士來進行。不管是自己找出有效率的交辦方式,或是找尋專業的人士來全權打理。

想想看自己上班的公司,有哪些業務是委外的吧!
清掃肯定多數都是委外的吧!
影印機的維護也多半是委外!
空調的定期保養也是!
地毯的定期清洗更不用說!
有些公司甚至把IT委外了!

委外這樣的事情,小至從自己身邊便開始發生,大至公司、政府多種事務都有委外的事實。
不驚不怪、不稀不奇!

Applications that are easy to be used

3/23/2006

In the "Designing Interface" book which wrote by Jenifer Tidewell, one section is quite interested.
One could say, "The applicatuions that are easy to be used are designed to be intuitive."
The author think that's almost a tautology.

The author also wrote:
Except that the word "intuitive" is a little bit deceptive. Jef Raskin once pointed out that when we say "intuitive" in the context of software, we really mean "familar".

跟不上全球潮流的外資企業

7/11/2006

其實原本就針對一些相當自大的外資企業頗為感冒, 拜讀黃彥達先生的[外資網際網路企業的中國失語症]更有感觸.

從過往接觸不少外商的經驗, 包含直接飛到國外在外國企業的辦公室裡直接與他們共事, 或是在台灣或是在大陸藉由電話會議與外商進行定期與非定期的進度討論, 類似的經驗當中, 其實可以發現, 與各國文化和企業文化相關的, 會看出一間外商公司, 其實究竟有沒有跟上產業全球化的腳步, 以及究竟懂不懂全球化之後應該要放下身段的道理.

多數的外商企業來自美國, 美國是一個比較特殊的國家, 除了他原本就土地廣大資源豐富之外, 民族的大熔爐也是一大特色. 但是, 包含一些朋友的經驗看來, 美國的公司, 反到普遍有自大與自以為是的傾向. 怎麼說呢, 大概有研究各國文化的學者可能可以提出比較精湛的解釋, 但是呈現出來的現象, 直覺的來看, 經常在與美國公司的人聯繫時, 會發現若是你的英語能力若是不夠好, 經常會感受到類似被瞧不起或是被輕視甚至嘲笑的狀況.

過去曾聽一個大陸朋友轉述在大陸他一個朋友很經典的例子, 處在外商公司, 跟美國總部匯報, 礙於民族性以及英語溝通能力因素, 產生了相當大的誤解與被嘲笑. 眾所皆知, 中國人普遍比較客氣, 講話時不會用很精確但是看起來挺不客氣的語氣來陳述一件事, 例如, 朋友來拜訪, 我們可能會說, 哎呀真是不好意思家裡沒什麼菜, 或是說哎呀家裡很亂對不起. 但是事實上明明滿桌的菜, 或是家裡諾大的空間, 也收拾的整整齊齊. 這是大家比較知道精典例子. 而其實跟外國公司共事久了的人也會累積到很重要的經驗, 就是歐美國家的人普遍希望聽到很精確的陳述, 看似毫無情感的, 但是重點在簡明卻精確.

過去在大陸待過一小段時間的經驗, 其實讓我驚覺到一件事情. 或許英語真的現實來說堪稱國際性語言, 但是你有沒有想過以人口比例來說, 講中文的人口數, 在全球總人口裏面, 佔了多少比例? 說實在的, 英語, 何德何能, 可以堪稱是國際共通語言?

去過德國, 法國, 以及日本, 我發現這幾個國家的民族自覺, 很明顯. 你在這些國家, 跟他們講英語, 常常會發現出乎意料之外的反應. 以我自己經驗, 在餐廳裡, 或是Coffee Bar, 明明店員是聽的懂英語, 也會講一口流利的英語的, 但是你用英語問他, 他卻用德語或是法語回答你. 問他們請問廁所在哪, 嘿, 雞哩瓜啦的一串德語出來, 還是搭配看了他們手比的方向才知道廁所究竟在哪. 從廁所走出來, 卻聽到剛剛那店員用一口流利的英語跟某個看似老客戶的人交談.

在日本, 你很難看到哪樣商品上面會只有英文標示, 沒有日文. 或是很難看到哪件進口商品上面依舊滿滿的英文. 日本人, 普遍認為, 你今天商品想要打入日本市場, 請先學會怎麼講日語, 請先學會怎麼寫日文. 一套軟體想要推進日本市場, 首要條件是 "全日文化", 裡頭除了 OK 以外, 沒有任何英文字.

到了中國大陸呢, 其實我感受到相類似的民族自豪. 那是在台灣感受不到的. 中國啊, 泱泱大國, 物產是這麼樣的豐盛, 覺對不輸美國, 以人口數來說, 中國大陸的人口更是遠遠超過美國. 技術水平, 只是起步比起歐美來的晚而已. 要超越, 是遲早的事.

話題扯遠了. 其實我很納悶那些號稱自己是國際型企業的外商公司, 這些國際性企業, 有相當多的企業, 在全球各地都有總部, 分公司, 或是辦事處. 這樣全球性的公司, 裡頭的員工應該是要體認到他們是在跟全球各地的人一起共事, 不僅僅是膚色不一樣, 語言, 文化, 觀念, 信仰等, 通通不一樣. 裡頭的員工, 應該是用更開放開闊的心胸, 去跟全球各地的人一起共事, 而不是還在那編自以為自己的英語多麼偉大多麼了不起的狹隘心態.

過去工作經驗曾有一些挺有趣的例子. 曾經跟一位大陸同事正在跟美國那邊進行電話會議, 英語很糟糕的大陸同事, 雞哩瓜拉的講了一堆, 聽的我都快從椅子上跌下去了, 並且我還是想好久才聽懂我那同事究竟是在說什麼, 基本上, 除了文法錯誤一大堆之外, 那講出去的英語根本是中文逐字直譯了, 哇天啊, 我正想幫他解釋, 卻神奇的發現, 電話的另一端講說"你是不是想說.........", 天啊, 對方聽的懂!?

再說另外一個例子. 以色列人用的是希伯來文, 那是從右橫寫到左的文字, 因此他們的閱讀習慣是從右到左, 而不是歐語系的左到右. 因為國際化的趨勢, 其實以色列人也多少都懂一些英文, 精通的更是大有人在. 但是日常生活中, 他們還是經常會習慣把英文從右看到左. 怎麼說呢, 一間飯店的英文叫做 Capital Hotel, 你跟路人問路, 問說請問 Capital Hotel 在哪, 他會反應不過來, 甚至不知道你說什麼. 但是如果你提示他 Hotel Capital, 他會突然恍然大悟那般, 告訴你這間飯店就在轉角那邊. 其實這不僅是文字從右到左的問題, 還包含他們原本希伯來文的字句結構, 是跟英語有諸多顛倒的. 在跟以色列人共事的期間, 由於雙方可以聯絡的只有英語, 他們不可能懂中文, 我也不會希伯來語, 這就有趣了, 雙方英語都不是母語, 除了偶有文法錯誤之外, 有時還會因為用了一些片語, 而造成溝通上的誤解. 明明我陳述的是正面的, 對方看成反面的. 或是明明對方想要說請我們暫緩某一項工作, 但是他寫出來卻是請我們繼續進行. 諸如此類, 還真要共事出默契, 才會警覺到對方有可能是溝通上的誤差, 必須用別的陳述方式跟對方再次確認.

像這種比較開闊的心胸, 以及比較把共事的對方(即是對方是客戶或是廠商)視同自己周邊的同是那般, 在認為對方應該是要說什麼之前, 再試著用他們的文化傾向去思考並確認, 才是一個所謂國際性的企業裡的員工應該有的態度吧.

自認為用美國那一套eBay的營運方式, 甚至是網頁呈現方式, 可以打通全世界, 那件等著看在日本在台灣的慘敗囉. 而認為自己的網路遊戲就是連軟體(光碟片)都得要玩家花上千元先買, 還得要付費連線, 這套方法想要推到台灣, 韓國, 那同樣的等著看到市場佔有率遠遠的落在低於10%吧. 怕是連一個玩家都沒有.

*外資網際網路企業的中國失語症: http://www.digitalwall.com/scripts/display.asp?UID=337

Professional

3/17/2006

Have you ever took a while to think about "Profession" or "Professional"?
Well, I am not talking about "Prefessor".
OK, you may be a very professional person in your job.But you may also be a very awful dad or mom in your family.
You may be a very talented programmer, but that doesn't mean your design will be widely accepted.
Emil Stenström, who owns the "frendly bit" web site, said "I’ve seen many sites that have great code but that still makes me want to kill someone. Don’t confuse good web developers with good coders. “Don’t be a rotten standardista” as Molly Holzschlag would put it."
Think about that. No one is professional in all the things. It's true that you may be a professional in some area(s), you you may be quite awful in lots of other areas.
Be more humble for all the things, even for the area which you are already a professional.

方法論

3/3/2006

你在拖地時, 有沒有曾經想過, 為什麼你要先把地掃乾淨, 再拖? 如果地板實在太髒, 你每拖一小區域, 就要洗一下拖把. 真要拖很乾淨, 大概要拖二至三次, 才會很乾淨?

這問題很簡單, 但是, 如果是一個從來沒做過打掃工作的人, 他只看過你拖地, 你現在麻煩他幫你拖地, 或許他直接拿起拖把, 就開始拖地.

拖地前, 要先把地掃乾淨, 這對多數的人來說, 已經是生活常識了. 但是, 其實他也是一個方法.

以往, 我在擦家裡一樓那排落地窗時, 先撣灰塵, 再開始擦, 擦沒幾片玻璃, 抹布已經很髒了, 抹布得換一條. 後來, 我注意到大樓那種玻璃維幕的玻璃清洗功, 他們玻璃是用洗的, 洗過, 擦乾, 就好. 我也學下來, 家裡的落地窗, 外頭那一面, 用水洗, 再擦乾, 省下的時間約略有三四倍以上. 這是使用不同的方法來達成同一件目標.

法方, 是人去創造的, 有沒有效率的方法, 也有很有效率的方法. 在沒有想到新方法, 也沒有管道找到有效率的方法前, 我們常常是土法煉鋼, 用傳統的方式去達成我們想要達到的目標. 但是人類社群的知識經驗累積, 以及資訊傳達的便利, 全球幾十億的人口, 古今中外的人, 累積出來的經驗跟方法, 其實可以大大改進傳統的老方法所耗費的時間跟人力.

不過, 我不是很能理解的, 是為什麼當有很多有經驗的人提出的方法在那邊, 可是, 我們還是會選擇用我們自己認為比較喜愛的方法去試著達成我們的目標? 例如, 你知道有機器可以協助你打鐵練鋼, 可是你卻偏偏還是選擇自己手工去打鐵, 難道只為了享受揮灑汗水的快感?

有方法被提出, 也有很多人是著去驗證,並提出改進, 後進應該是要學著去利用這些方法, 而不是仍執著於既有的偏好. 您說是不?

賺錢有素, 盜亦有道

3/3/2006

賺錢有素, 盜亦有道
臺灣人有點小悲哀, 過往在國際間不被成人, 四處被打壓, 藉著資訊科技, 跟一些特殊的產業, 在國際間闖下一片天. 但是無奈全球競爭的壓力, 輝煌的產業, 一樣不抵新興國家的低價勞工成本, 要維持競爭力, 降低成本, 只能產業外移.

外移到哪? 同文同種的中國大陸, 是最佳選擇. 你看有多少產業老早已經移到大陸去了? 過去身邊的許多同學, 家裡開工廠的, 老早在唸完大學服完兵役後, 就常駐大陸. 家裡不是開工廠的, 也很多人一年下來往返台海兩岸十多次, 或是一年下來將近半年都在對岸.

製造業是這樣, 軟體產業也是這樣.

眾所皆知, 軟體外包服務的軟體代工服務業的大宗, 印度, 以色列, 都是排在最前面. 曾經台灣也一度排了上去, 現在沒人看台灣, 全球幾萬隻眼睛看好大陸. 人多, 人才也多, 成本又低, 是個相當被看好的市場.

一些企業老闆, 為了企業的長遠經營, 自然得跟上全球趨勢, 哪裡成本低, 就該轉往哪裡去. 堅持不轉, 將會逐漸的因為成本過高, 而逐漸喪失競爭力.

只是, 像這樣的企業長遠經營, 我們所說的, 企業的根, 跑哪去了? 台灣土生土長的企業, 多少元老員工, 以及多少幫這企業打拚以及伴隨著企業成長茁壯的員工, 當企業開始外移, 這些員工, 便得要逐漸的自然淘汰, 自然凋零. 那麼, 企業的長遠永續經營, 最後留下的是什麼?

當一家土生土長的企業, 逐步拓展國際市場, 在全球佔有一息之地, 進展到在全球列為該領域屬一屬二的領導廠商, 我們聽到這樣的消息時, 經常感到很欣喜, 很自豪. 但是接著, 這樣的企業, 開始逐步縮減在台灣的人力部署, 開始將研發重心跟企業核心逐步外移, 到了有一天, 在台灣的所謂的總公司, 僅僅小到形同一個辦事處一樣的規模; 而我們可能在此同時, 在許多報導上, 包含國際的媒體上, 看到該公司的消息, 聲稱她們感到很自豪, 因為這一天, 她們是全球第一大; 因為這一天, 她們比過往成長了多少倍, 因為這一天, 她們在對岸的人力部署達到多少多少. 我們開始感到, 這個企業, 突然變的好陌生, 突然變的好遙遠, 突然變的好像與我們沒有關係. 因為, 除了我們自己知道他曾經在台灣紮根之外, 所有的報導, 完全沒有台灣的影子.

這, 或許就是商業吧. 你是一家想要長遠永續經營的企業, 遇到全球競爭的壓力, 你自然得跟隨全球的趨勢, 更加的加強你的競爭力.

台灣人, 得自己爭氣

Rosenbluth Travel's success - The customer comes the second

9/26/2005

The secret of Hal Rosenbluth's success, and his company's, is actually very simple. He concentrates on his employees first and his customers second. The formular works. Rosenbluth Travel was named one of the top ten in The 100 Best Companies to Work For In America, and happy customers have quickly transformed a small family business into a global industry leader, grossing over 1.5 billion annually.

In "The Customer Comes Second", Rosenbluth Travel's CEO and entrepreneurial genius, Hal Rosenbluth, reveals new ideas for hiring, performance reviews, technology innovation, and creative compensation. He shows how to build highly effective teams, inspire loyalty, and turn your workplace into a hotbed of creativity where people produce truly incredible results.

Find out why this book is causing such a stir; how it can transform you and your company. By the way, your customers will love it.


Link

Upgrade path

9/14/2005

All softwares have their own upgrade path. A mature software will provide you very clear way that how you can do on your upgrading.

My previous colleague ask my opinion about the software developing project which I used to be part of the co-worker. Well, my opinion is I agree to provide a moe flexible way and more professional way that user can easier upgrade their software and configuration from old version to latest version. This is including upgrading to a newly-implemented localized version.

Imagine a German who can only live on the English software and try his best to read those unfriendly English strings. Now, there is a new German version. He will think about to upgrade to German version which is the most friendly stuff to him.

That's why I agree the way to upgrade to localized version should be provided. I wonder why some policymakers will make the decision that it's not provided!

Testing all the possibilities?

4/26/2006

Have you ever planned to try to test all the possibilities and finally you surrendered?

When you are in high school, there is a lesson in mathematics class to teach you how to count the probability.
The lesson started with something like you need to pick up a red ball inside a black box.
The first thing you need to know is how many balls there, then you need to know how many red balls.
If there are 10 balls and only one red ball, then you will get the result that the probability to pick up a red ball is 1/10.

The lesson will then teach you how to count something more complex.
A similar example is to count the probability that you pick up a red ball and a blue ball from the black box.
If there is totally 10 balls inside the box, only 1 red ball and 1 blue ball. Then the probability is 1/10 * 1/9, which is 1/90.

In the real world, the reason it's so hard to list all the possibilities is due to we may not be able to find all the variables. In mathematics, you can, but in the real world, you can not.

A Sample Test Plan Structure

Below is a sample Test Plan structure which I created before for some project.

1. Background
2. Purpose of this Document
3. Reference
4. Features to be Tested
5. Features not to be Tested
6. Test Approach
7. Test Item Configurations
7.1 Rack Configuration
7.2 Platform Configurations for Each Testing Item
7.3 Environment Locale to be Tested
8. Resources
8.1 Human Resources
8.2 Hardware Resources
8.3 Software Resources
9. Test Cycle and Schedule
10. Risks
11. Assumptions
12. Test Entrance/Exit Criteria
12.1 Entrance Criteria
12.2 Exit Criteria
13. Defects Reporting
14. Contacts