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)   

2008年8月30日

最好的方法與最有效率的方法

處理同樣一件事,可以有很多方法來進行。

案例一:
要自行組裝一個四格簡易書櫃,你可以拿一把十字螺絲起子,慢慢的把總共 16 根螺絲鎖起來,時間花費也許要 32 分鐘(假定鎖一根螺絲要 2 分鐘);你也可以拿電動螺絲起子,花費約 8 分鐘鎖完 16 根螺絲,速度上快了四倍。

後者應是最有效率的方法,但不見得是最好的方法,因為你不見得有電動起子,跑去工具行得花個至少五六百元買一把,來回可能就一小時了,而鎖完這個書櫃後,大概一年半載內不會在用到這把電動起子。

案例二:
你有沒有想過,當每年快要接近報稅的時候,公司的行政人員是不是開始跟你確認你的戶籍地址有無錯誤,你回想一下他們都是怎麼進行的,是由專人逐一到每位員工座位那,一一的確認地址,還是利用電子郵件確認?

過去我曾待過兩家員工在 100 人以下的公司,前一家是行政人員將所有人的戶籍地址印出來,然後拿著逐一去跟員工確認,公司員工人數不算很多時看起來還是可行的辦法;後一家選擇了一個很有效率的方式,但是犯了一個嚴重的錯誤,行政人員將所有人的戶籍地址整理到 Excel 表單裡,然後新增一個「確認」欄位,接著將表單放到公司內部公開的檔案伺服器上,發信請每個人去確認表單裡自己的資料有無錯誤,無誤就標記為 OK ,有誤則請直接更正。

後者的方式確實很有效率,需求發出去,行政人員不必親自逐一向每位員工進行確認,緊接著他可以繼續進行其他事務,只要等到預定的底限到了,再將檔案回收即可,嚴格算起來花費的時間也許只有 5~10 分鐘。前者因為需要逐一親自拜訪並確認,確認完同樣的員工人數,可能花費了 30 分鐘,「效率」相差近六倍。

案例三:
有天我在對一個專案的各個子目錄逐一進行壓縮,準備要將專案歸檔備份,為了使歸檔後,未來有需要參照的人能夠較為易於找尋他想找的資料,因此我決定每個子目錄個別壓縮成一個檔案,這會比起整個類別目錄(例如所有測試相關的目錄)全部被壓承擔一的一個壓縮檔來的好一些。

但這動作大概接連做了十來次之後,我就開始感到不耐煩,礙於壓縮軟體功能的限制,我所想要的壓縮選項都必須透過多達五、六個操作才可以進行,每一個目錄都是進行相同的操作,我很概略的估算一下,應該至少還得重複個幾十次也許會超過一百次。這樣每個目錄大概會花費我五~時秒的操作才能依照我的要求來進行壓縮,五~十秒看似很短,但重複個 100 次那也快逼近 15 分鐘了。15 分鐘也許也可以算是短,但是一般人有個很大的弱點,就是不適合做重複性的動作太多次,特別是沒有像生產線上的作業員一樣受過專業的訓練的話,即使只是約五個步驟的操作,可能在重複個二十次之後不小心就會產生錯誤,遺漏某個步驟,或是做錯哪個步驟。

我心裡估量著,我花個三分鐘測試一下用一些輔助方式來改進,三分鐘後完成,之後我只要透過幾組的輔助步驟,便可以半自動的批次完成重複的步驟。若以原本全手動需要約 15 分鐘來算,我大概也沒省到多少時間,但是藉由輔助的工具,至少可以大幅避免重複性的工作產生的錯誤風險,算是值得。

全都做完後,我檢討了一下,也許以後可以把輔助工具改進成近乎全自動,但是先擱著吧,真要做到全自動,開發要花時間,驗證功能更要花時間。

討論:
不是什麼方式都絕對是最有效率並且同時是最好的方式,對於一個職業組裝工人來說,裝配傢具是他每日的工作,投資自動工具以達到至少四倍的效率提升,顯然是相當值得並且也是必要的投資,對於一般人也許一年才會自行組裝一次傢具的人來說,添購自動工具便顯得不太實際(當然近來有商家推出自動工具出租,這會是另一種值得評估的方案)。

但我也不是要全面否決追求效率的想法。檢討每一件事情有沒有採取較有效率的方式進行,時常是未來改進的重要參考。對於日常的工作而言,我們經常是在進行重複性或是同質性相當高的工作,因此,當某些事情並沒有採取較有效率的方式進行,意味著我們會投入較多的人力與時間成本,對於需要以營收來支撐的公司而言是不利的狀況。

添購工具以達到高倍的效率提升,並且衡量工具的採購成本對比傳統方式的相對工時成本付出,就可以大概有個底,知道投資值得與否。

好比製麵商家,用傳統方式,得聘請兩個全職員工負責製麵,才能達到預期的產量,當產量需求增加兩倍時,意味著至少得要再追加兩名員工(假定每人月薪為 3 萬,兩人一年的年薪則為 72 萬)。

若買進某自動化加工機器,得花 100 萬元,但只要對既有員工稍加訓練,使其能夠操作該機器,則兩倍產量便可輕鬆滿足。機器一次買進花費 100 萬元,雖然有每年折舊以及機器耗損風險與定期養護支出,但對比增加員工每年都得額外花費 72 萬元,何者較為划算,就很值得討論了。

==========

今天看到某 3C 賣場的廣告,「夏季家電最終特價」的標語居然已經打出來了,是的,將要進入九月了,秋季已然接近。對於事事要檢討有無效率的公司而言,六月時員工投訴辦公室室溫長時間過高的問題,居然耗了將近整整兩個月仍在「評估」中,同事們私下笑著說,待哪天總算加裝好新的冷氣時,大概時節已邁入涼爽的秋季,那台新裝的冷氣應該要等到明年才派的上用場吧。

事實上也不僅僅才兩個月,辦公室室溫過高,就有空調無法負荷,這不是今年才發生的事情,早在幾年前便已逐步惡化了。機具會老化是合理的現象,當老化時,即使再怎麼加以維修保養,終有不切實際的一天。老家客廳的冷氣,在服役了近十年後,老媽在我的建議下,換裝了時下最流行的變頻冷氣,並且買了目前評價最高且冷房效益最好的X金冷氣。結果新的機器在服役滿兩個月家裡收到台電的電費帳單時,電費對比去年同時足足省了近六千元。

我心裡只是納悶著,連老媽只是個國小畢業的家庭主婦,什麼事情值得投資(X金冷氣大噸位的買起來要比他牌貴上兩三萬),什麼開銷該節省,都可以拿捏的很準確。怎麼以營利為主的公司,事事要檢討效率,卻在行政事務上每每讓我覺得不是用了很糟的方式,就是用了很沒有效綠的方式。我甚至碰巧聽到行政人員講到「可是X金冷氣很貴!」的對話,是的,他確實貴,但是否值得?公司內人多機器多相對的發熱源很多的狀況,加以冷氣每天至少得開個近十小時的狀況來看,變頻冷氣理想上最高可省近 40% 的電費,是不是短短幾年內就可將價差給追回來了。

我認為事情的衡量準則不是絕對的,就像前面幾個例子看到的,看人看狀況,該有不同的選擇。我自己家裡幾個月前也添購了冷氣,我想很多人跟我會有類似的考量,約三四坪左右的房間若是裝個非變頻的分離式冷氣,約要一萬五,要想選擇變頻,則馬上貴上一萬。多這一萬,究竟要不要花下去?對於我們一般這種小老百姓,看老闆眼色吃飯的,一萬說多部多,說少也不少呀。最後多這一萬還是花下去了,因為估算自己在家時冷氣應該常常會開著的。但是去年老婆娘家添購冷氣實則選擇了非變頻機種,原因是因為丈母娘很節儉,平日很少會開冷氣,那麼即使變頻電費較省,但因用量低,反倒變成不是很值得投資。

當每年公司管理階層都會對我們這些小員工進行績效稽核時,我不禁想問,這些管理階層是不是也該讓我們來評評分數。

2008年8月28日

為什麼多語言軟體要做偽本地化(Pesudo-Localization)

即使軟體的國際化、全球化、本地化已經提倡了相當多年,產業的分分合合(在決定自己做、到決定外包、到再次的決定拿回來自己做)也發生了幾次,但是依舊有為數不少的新加入者,或是從未涉足這塊領域的公司,對於軟體的多語化一問三不知,於是,其軟體的多語化,依舊是十年前的土法煉鋼。

為什麼將要進行多語化的軟體產品,建議要做偽本地化(Pseudo-Localization)?一個大學同學最近問了我這個問題,我想了想,我大概有近三年沒有回答過這類的問題了。不過,事實上我也驚覺我現今周遭的同事似乎有不少人也不了解這問題的答案,更有甚者,對於何謂偽本地化全然不知。或許也難免,當分工過於精細時,如果沒有機會碰觸到這一塊的領域,相當大的機會不會聽過這個詞,也自然不會知道其為何謂。

偽本地化其實是希望能夠解決以下幾件事情:
1. 驗證產品的 UI 確實有被適度的拉寬長度以適合語彙較長的語言,例如德文或是挪威文
2. 藉由偽本地化的技術,順勢驗證產品的各個控制元件是否可以正常顯示歐語的延伸字元(例如:ä ü ö é 等)、東亞(中、日、韓)、以及中東語係文字等。
3. 驗證產品是否會因為過度翻譯,或是因為翻譯的不一致,卻導致產品功能無法正常運作
4. 驗證是否尚有未抽取出的字串因而導致未完全的翻譯

同學問我,那翻譯後不就也知道上述的問題了嗎?理論上是沒錯,但是其實往往為時已晚。很多的狀況下,產品開始進行翻譯時,也就是程式以進入功能異動的凍結時期,甚至產品以進入 beta 或是 RC 階段了,若是此時才發現因為翻譯導致產品功能錯誤,其結果往往是部份的翻譯回復為英文不進行翻譯,然後使用者便拿到一份中英混雜的產品。

不過話說回來,有進行偽本地化的軟體商或是軟體專案,似乎仍舊是相當稀少。
看來幾個強調可以為軟體進行偽本地化工程的翻譯工具,還真難從這些軟體廠商身上賺到錢,也難怪接連的被併購....

2008年8月11日

Talk about "Ready for Localization?" again

Recently my colleague from UK ask me (and our team) for a favor. They encounter a problem that they thought they have localized everything, but the result is many text still show in English. I guess he is a guy who only have a limited knowledge of codes, but he has tried his best to dig into the deeper level of the materials. The localization project seems did not involve any engineer, I would said the project was under estimated.

There are several reasons which result in the fact that many text are still in English. It's pretty bad. The material seems never being examined if it's I18N ready or G11N ready. Not to mention to have a pseudo localization test.

The main product is a set of flash files. Ideally all the front end presented text are stored in the back-end database. The ActionScripts codes will then pull out the text from database and generate several XML in run-time, and then the flash will refer to those XML to present the text.

I saw one of the common problem which most of the UI designer may also make the same mistake. Normally when a UI designer create a new object like a button or a lable (a text field), s/he will also put a default string with it. For example, when creating a cancel button, you might put the "Cancel" in the button's text field, and then in design mode it will just look like what it will be in the run-time mode. It seems to be fine, but actually it's not. It will be hard to detect which object has not yet been externalized or linked with external text source. Because you will think everything "looks fine" in your testing.

A UI designer may not have enough knowledge in I18N or G11N area. In some cases, it's fine. But they'd better learn more from these areas.

A simple way to improve the process and prevent from the problem is to use code-like text. For example, use "_CANCEL_" to be the default text for the button.

Since the product will be localized into many languages, never thinking about to leave the English text to be the default text. Treat English as another language. Load all the English text from external text source just like what you plan to do for all the other languages.

In this way, it will be easier to localize this product and less problem will be.