產品說明書反應該廠牌的專業度還是對客戶的重視度？

打算為家裡買一台空氣清靜機，盤算了很久，今天做了一下訪價，最後到了大賣場去比價。終於，抱了一台自己還算滿意的款式回家，拆封，翻說明書，插電，開始運轉。

一向不愛看說明書的我，基本的翻一翻還是會的。一項產品，說明書裡可能會告訴你，開始使用前，請先做哪些動作，也會告訴你，這產品該怎麼使用，該怎麼保養，應怎樣避免耗損，以及該怎麼排除故障等。因此，即使我個人不是很愛翻閱說明書，但是總是會大致瀏覽一遍。

不過，說實話，看到這產品的說明書，其實挺失望的。買了一個國內知名品牌的產品，並且他的產製地也是台灣，是台灣字有的國產品。說明書，小小本，簡簡單單不過十來頁。別說空氣清靜機的說明書有什麼好寫，事實上，用新的廠商，可以將一台空氣清靜機的說明書，寫上至少三四十頁。

姑且先不把範圍侷限在空氣清靜機，就光談說明書吧。

過往我也陸陸續續買過不少商品，像是家用DVD播放機、全平面映像管電視機、光碟燒錄機、電風扇、無線網路路由器、有線網路IP分享器、電子琴、硬碟機、硬碟外接盒、數位相機......林林總總的商品，國產、日製、美國製等來自不同國家的商品，並且有的是原裝進口，有的其實是國外廠牌但是產自第三國等。

從這些不同屬性的商品，以及同屬性商品但是不同產地，這樣來作比較，其實我約略發現，普遍來說，台灣廠商不管是原製造商或是代理商或是台灣分公司，普遍對於說明書不甚重視。

拿我過去曾買過的日本原裝進口的數位相機來作例子，因為那款項機是專做外銷的，裡頭並沒有附上日文版說明書，但是有英文說明書，以及中文說明書。英文說明書大約有三百頁以上，然而中文說明書卻僅有兩百頁左右。雖然說，說明書在不同語言的確會因字句的長短而使頁數會有一些小差異，但差異到一百頁應該是不會有的。並且，實際比過章節以及內容發現，有兩百多頁的中文說明書雖算是詳盡，但是有三百多頁的英文說明書裡卻有很多進階設定說明是在中文說明書裡看不到的！

這表示些什麼？廠商不夠用心不願意認真的把說明說詳盡的寫好？還是國人其實普遍也不重視產品的說明書，跟我一樣，電器買回家，插電後就馬上開始用了，不需要說明書？

我在公司裡有位資深的業務，他剛好最近跟我聊到，有一些類型的客戶，當他們在審視廠商時，或是交貨驗收時，他們就是會預期希望看到厚厚的一本說明書。如果你只能給他幾十張雷色印表機印出來然後用釘書機釘起來的說明書，他會認為你這廠商很不專業。並且他們會認為能做出厚厚一本說明書的廠商，某種程度上，這家公司肯定規模夠大，也夠專業，也夠重視他們的客戶。

試想，若你是廠商，你究竟是認為你的客戶都很聰明，一點就通，不需要編制非常詳盡的產品說明書，還是其實你是當他們是傻瓜，只要跟你買產品就好，事後有問題，再說？

反過來講，你是希望你客戶只要跟你買東新就好，其他相關服務不管他，產品買回去不會用不關你的事；還是你希望你的客戶包含將你的產品買回去之後，對你的產品以及公司形象都很滿意，包括認同你對客戶的熱心服務與尊重？

量販通路、便利商店、以及傳統通路的價格迷思

記得約略十年前左右，先是萬客隆開始營業，他起先的經營模式是倉庫式的。受限於當時法令規定，萬客隆採會員制，且會員的申請必須是公司行號。早期會員的申請審核還有點嚴格，你還必須出具公司證明，當然各分店落實的程度再談。此外，萬客隆的商品，都是真的量販的，比方說，你要買個A4紙，你只能一次買半打或一打，他不單賣一包的。

過些時候，家樂福開始開張，他起先也是採倉庫式的，也是要會員申請，但是會員申請的規定就比較疏鬆，你可能給張公司名片他就讓你申請。目前大家所認識的家樂福，基本上已經不是過往那種倉庫式的營業了。

為什麼要提這個主題呢？因為在過往這些大型量販店開始營業時，由於他的商品「普遍」都很便宜，大家一窩峰的往那邊跑，傳統所謂的雜貨店或超市生計受到影響。以往大家習慣的消費模式改變，例如你憑常會在鄰近的雜貨店或超市買日常的用品，如衛生紙、奶粉、沙拉油等，這些東西大家開始往量販店跑。

不過，當時，母親的研究卻發現，鄰近的大型超市，很多商品卻往往比大型量販店還便宜！？奶粉、沙拉油、醬油等，量販店常常還貴個一、二十元！？那大家為何印象中量販店東西便宜，開始第一優先想往量販店跑？

你有沒有想過，量販店哪時真的跟你保證他裡頭所有的商品一定比外面便宜？

量販店打的主意，不過是針對某些重點商品，他策略性的超低價，吸引你過去。由於他裡頭的商品上千種，你一旦去他那裡，你由於一方面對他的印象是東西都比較便宜，另一方面因為商品齊全，你會乾脆把日常生活相關的東西一併購買。食、衣、住、行、育、樂，樣樣全包。
食：量販店內，從乾糧如餅乾等，蔬果，料理相關如醬油、調味料等，飲料，酒等
衣：量販店往往有自有品牌的服裝，從襪子，內衣褲，休閒服，鞋，到西裝套裝等都有
住：油漆，簡易傢具如櫥櫃、床墊、書櫃等
行：汽機車相關配件用品
育：量販店內現在多伴有一些書，適合一家大小不同年齡層觀看的書
樂：休閒用品，例如烤肉用具、野營、體育用品等

量販店打的主意就是這樣，他一方面盡量讓他的商品齊全，一方面吸引你過去消費，並且希望你在那邊盡量把你日常的食衣住行育樂所有相關用品一次夠齊，還包含一家大小的全部買齊。但是量販店真的有跟你保證每樣商品都一定便宜嗎？沒有。

舉最簡單的例子，台灣啤酒玻璃瓶裝，傳統超市一瓶賣45元，量販店一般定價也是45元！雖然台灣菸酒公司的商品價格是比較硬一些，但至少這就是一個參考了，尤其在台灣菸酒公司從早先的菸酒公賣局民營化之後，其實價格也已經比較符合市場機制了，量大，其實價格都可以很漂亮。但是你還是看到，量販店銷量大，但是賣給你的價格卻比你鄰近的超市沒有便宜到哪去，甚至更貴！

接著來看看傳統通路，傳統通路包括社區性的超市，跟已經很難看得到的鄰里的雜貨店。
一個量販的迷思繼續存在著，為什麼在量販店已經很普遍的現在，還是有不少商品居然還可以在傳統通路買到比量販店更便宜的價格？

例如離我住的地方不到30秒路程的一間沒有加盟的便利商店，其實就是改良版的雜貨店，裡頭賣的一公升裝美樂、ASAHI、麒麟等啤酒，幾乎永遠都比超市跟量販店便宜？量販店在沒有特價時，一公升裝麒麟啤酒，還要賣你一瓶115元，我附近的雜貨店卻可以全年賣你105元！

跳到便利商店好了，現在全台的便利商店，在都會區已經算是很氾濫了，方圓5分鐘路程的一個範圍內，可能會有超過三～四家便利商店，例如7-Eleven、全家、萊爾富、OK等，稍微離市中心遠一些的地方，便利商店其實也還不算少，對於在都會區生活的人來講，方便是很方便，半夜渴了，肚子餓了，都還可以到這些24小時營業的便利商店買些東西充飢。

可是便利商店卻也同樣的從來沒跟你說他的東西便宜，他只是想跟你說他想做你的好鄰居。大家都知道，你如果在外租房子，平時買包裝水在家引用，你不會到便利商店買，因為貴。你會找空去超市或量販店一次買個幾瓶。偶爾缺個什麼，或臨時想吃個餅乾，是會到鄰近的便利商店買沒錯，但是你可能還是會計畫性的不定時的到超市或量販店買些東西，例如洗髮精、沐浴汝等，你通常不會在便利商店買。

但是再拿傳統雜貨店來比較一下，如果你很「幸運」的，住家附件還有雜貨店還營業著，你大概會發現，像是飲料、零食等你本來可能會在便利商店購買的，這些東西在雜貨店裡，卻幾乎都比便利商店便宜！！

你有沒有發現什麼不對勁？

為什麼像量飯店這種每天單日可以賣出數量非常龐大且產品線非常多樣性的商店，以及在全台擁有非常多據點、每天累計起來總銷售量也很驚人的便利商店，他們店內的商品卻往往並沒有比傳統通路賣的還要便宜！這是不是一個合理的現象？

如果你經常到了量販店，就會某種程度的認為裡頭東西幾乎都很便宜，然後會盡量把你日常相關所需一次購足，或是你是平常覺得方便就好，所以經過便利商店就會消費的人，你是不是要稍微思考一下，你的消費行為，在供需機制下相對於商品的價格，合不合理？

傳統通路下，只有零售店才可以直接販售貨物給消費者，製造商、代理商、大盤商、中盤商，乃至於小盤商，在過往都是禁止直接販售商品給消費者的。那麼對於量販店這種具有中、大盤商規模但目標客戶確實消費者，以及在全台有相當大規模的連所便利商店，他們的售價究竟合不合理？

您好好的想想看～～

責任與承諾

什麼叫做承諾？什麼叫做責任？承諾與責任，又是怎樣的關係？

邁向下一個階段

終於要離開現在的公司了。數一數日子，也超過三年的光陰了。比起第一份工作，待了將近四年，第二份工作超過三年，加起來正好七年。

第一份工作雖是在學術單位，好歹也是個組長，帶了個小組做些技術開發與維護。第二份工作被當作正式踏入社會，新的工作領域，想說就多學學吧，先是個工程師，也幹了兩年，邁入第三年才升資深工程師。工作資歷不能拿年紀來比，要拿實際的工作年資來比。沒服兵役也沒念研究所，大學畢業後直接工作，這樣比起一些有念研究所又有服兵役的人來說，工作資歷馬上多了四年。雖然念研究所的，在一些公司裡的職等是會跟大學畢業的有所區隔啦。

現在堂堂邁入第八個工作年頭，還是一屆資深工程師。

我想，假設有人試著要了解我為什麼要離開工程師，他可能要問很多人，也才能拼湊出約略50%。當然問我是最快的，可是基本上人都是看對方是什麼人，才決定對他說些什麼。總是有親疏遠近，總是有職務上的直接間接相關。

其實，人家說，要想留住優秀員工，不是等到他提了離職，才開始想辦法留住他。這麼說，姑且說我是優秀員工吧，我待了三年，之前都沒走，或許可以說是公司的一些相關福利、制度、升遷等等之類的，沒讓我想走。那麼現在想走了，是不是算是對現狀不滿呢？還是說我不算是優秀員工？

無論如何，有不少事情自己心裡其實很清楚，時機時機吧，每個人有每個人在不同時期所適合的不同的職場。比如在第一份工作裡，那裡的職場很能讓我好好發揮，一來工作內容跟自己專長有相關，也有興趣，二來當時的架構來看由我帶領一個技術團隊也很適合。

人或許該要盡量忘卻過去的不愉快不歡喜，少講些過往的閒言閒語，多看看未來，多規劃以後的路，是吧！

下一個階段是怎樣呢？

中平籤詩一首

事端百出慮雖長
莫聽人言自主張
一著先機君記取
紛紛鬧裡更思量

What kinds of testing should be considered?

Type of Testing	Description
Black box testing	Not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
White box testing	Based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing	The most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
Incremental integration testing	Continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
Integration testing	Testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing	Black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
System testing	Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
End-to-end testing	similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Sanity testing or smoke testing	Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state. Smoke tests get their name from the electronics industry. The circuits are laid out on a bread board and power is applied. If anything starts smoking, there is a problem. In the software industry, smoke testing is a shallow and wide approach to the application. You test all areas of the application without getting too deep. This is also known as a Build Verification test or BVT.
Regression testing	Re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance testing	Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
Load testing	Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
Stress testing	Term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance testing	Term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability testing	Testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing	Testing of full, partial, or upgrade install/uninstall processes.
Recovery testing	Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Failover testing	typically used interchangeably with 'recovery testing'
Security testing	Testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
Compatibility testing	Testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
Exploratory testing	Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing	Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
Context-driven testing	Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
User acceptance testing	Determining if software is satisfactory to an end-user or customer.
Comparison testing	Comparing software weaknesses and strengths to competing products.
Alpha testing	Testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
Beta testing	Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing	a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

Triangle of project QCD

When a project is running, what will you do to balance the triangle of QCD?
Q=Quality, C=Cost, and D=Delivery

We all know we wanna make more money from a project. But if the quality is too bad, you probably won't get any money.

When the project is phasing into another stage, you probably find out you'd better to add some more human resources or hardware resources. But it will bring more cost.

If you can not add more resource, but also need to remain the higher quality, then it might bring some impacts on the delivery date.


For a project management, there are many phases and tasks need to be take care. But the most simple way is to balance the QCD triangle.

What do you think about that?

再談選購NB

再談談選購NB吧

拿最近NB市場的實例，或許會比較有趣

* 大尺寸，還是小尺寸
買NB，你要買大尺寸，還是小尺寸？
12吋NB，長時間使用，螢幕大小真的太小，眼睛肯定會很酸。回想以往使用15吋CRT，然後把解析度設定成1024*768的時代吧～～
14～15吋的NB，對眼睛來講，輕鬆多了，可是，2~3公斤的重量，帶來帶去，可真不方便。次數多了，乾脆不帶了，那又失去NB容易攜帶的利基了！

* 高階還是中階？
你要買 Pentium M 還是 Celeron M？要最新的 Sonama 、Dothan 還是要普通的 Pentium？

* 內建顯卡還是獨立顯卡
其實我不太玩遊戲，所以獨立顯卡對我來講不需要

實例：
Acer TravelMate 2303Lci: CM1.4, 40G HD, Combo, 15": $28,000
Acer TravelMate 382Tci: PM1.6, 40G HD, Combo, 12": $40,000
Acer TravelMate 4102Lci: PM1.73(Sonama), 60G HD, Combo, 15" 64M ATi: $40,000
Acer TravelMate 3002WTci: PM1.73(Soname), 60G HD, 512M, Combo, 12": $50,000

你會買哪一台？

從小處著眼看大局面

很多事情都可以從小處著眼，來看整個大局面
一個人、一件事、一個物品、一個局面，都是由很多小的元素所組成，懂得從這些小元素來拼湊整個大局面，你就比較容易了解為何事情會是那樣的發展，會是那樣的呈現，會是那樣的結果

所謂的名正言順，以及不在其位不謀其政

相信名正言順、名不正言不順，這道理很多人都懂，也都認同。簡單講，做什麼事，要做的光明正大，首要條件是要先正名。

這裡不是想要提政治議題，正不正名，在各種領域都會有關，不僅是國家、政治的事務。

在一個團隊裡，總是有一些不同階級的領導者，姑且稱之為領導階層。這些領導階層之間一定有層級關係。某些層級的人具有某些權限，負責某些不同層級的事務。越是影響層面較大的重大決策，就越是要比較高層的人才能做出決定。

如果有個人被指派負責某些會有很大影響的決策，但是他的階層並不夠高，那麼事實上他並沒有辦法做出有效的決策。

道理是本來就在那邊的，並不是有人去講出來，它才變成一個道理的。

想要一個人可以把事情作好，就要賦予它足夠的權限。反過來說，不賦予足夠的權限，別指望一個人可以把指派的事情作好。

換不同的角度來看，被賦予很重大的責任與願景，但是卻沒有被賦予足夠的權限，那麼，事情永遠是不可能會順利完成的，層層關卡，只因為權限不夠，位階不夠。

不是那樣的位階，相對的在很多決策上並沒有資格去做出決定。或者說，並沒有權限去讓這個決策落實。

所以就會到了「不在其位，不謀其政」的境地

選購NB

最近想要添購一台自己用的NB。有經驗的人都會審視自己的需求是什麼，預算有多少，想花多少錢，以及想要怎樣規格的NB。

我的想法是怎樣呢？
拿來跟PC比較好了，一台全新的PC，連同17吋液晶螢幕，中等以上的規格，約略三萬左右可以買到滿意的。
但是NB呢，拿三萬元所買到的NB，可能約略用兩萬元就可以買到同等級的PC。

這麼比當然不見得公平，但這正是審視自己需求的一種考量。

說說門檻好了，我總喜歡拿硬碟機來當例子。當60GB甚至80GB已經開始成為基本配備時，假定40GB硬碟只要$2,000，你要不要多花$1,000來買80GB硬碟？這時，$2,000我把他定義成門檻價格，或者也可以說是入門規格的底價。

一台全新入門級PC包含螢幕（17吋CRT），總價約略一萬多一些，姑且當作一萬五，這是添購全新PC的門檻。

一台NB的門檻價，假定約略要三萬元，可是，NB不比PC，PC方便擴充。入門機種的PC，主機板多半是All-in-One，嫌效能不足，再另行花個三五千添購獨立顯卡。NB呢，NB多半沒有這樣的擴充能力，因此，在考慮添購NB時，得要提升規格底限才行。

一台三萬元的NB，可能在一兩個月後停產，半年後你開始受不了他的龜速，一年半後你開始想把他丟掉。但是相對於一台三萬元的PC，時間可能延長為一年半後你才開始感覺他的龜速，四年後你才想把他丟掉。

既然這樣，我會建議NB的門檻價要提高，比如提高到四萬，這時，入門價跟門檻價就是兩回事了。

就是說，假設我真的要買NB，我的起始價是四萬，四萬元買的到的規格，是我可以接受的中階產品。

如何？是你的話，你會怎麼選擇？

責罵？還是給予鼓勵？

處理事情的方法，需要經驗，也需要智慧。

舉養寵物的例子做一下鮮明的對比。養貓或養狗的書上，多半會告訴你，寵物不全然懂得人們講的字句，但是常見的語句，以及人們講出來時的語氣，包含抑揚頓挫、以及速度是急促還是緩和，其實貓、狗是會辨認的。

寵物犯錯時，主人可能一時火冒三丈，想說牠怎麼講都講不聽，越是生氣越是大聲謾罵，腦子裡可能不會想到為什麼牠會有那樣的舉動，只顧發洩氣憤。這一般而言 是無濟於事。假設是有耐心的去想，牠可能要做啥，可能發現牠其實是肚子餓了，或是想上廁所，或是其實是要跟你告知外面有陌生人靠近！

人跟人之間的溝通，當然複雜很多。但是人跟人，講人話啊！不是應該更容易溝通嗎？

某人犯了個錯，不管大錯小錯，是要罵他呢，還是要給他機會，請他小心一點不要再犯？

那麼第二次又犯錯了呢？第三次再犯類似但不盡相同的錯呢？屢次犯錯呢？

屢次犯錯，或許表示，這當中存在著一些大問題，不是這個人的問題，就是他所處的環境有問題。舉個例子，或許這個人老是被栽贓，因此他老是背黑鍋，資歷問題或是個性問題，默默承擔這莫名的錯誤，真的想要事情能夠改善，那還真得想辦法找出這真正的原因。

所以，處理一件某人犯錯的事件，是要責罵他呢，還是你要給他指點迷津？？

Well, wanna know where is there and who are in the photos? 

建設性的言論

在跟客戶的協同合作開發軟體的過程當中，因為團隊成員的疏失，造成客戶方的不便，甚至是客戶的原定時程受到影響，身為廠商(vendor)的一方，認錯是必要的。但是除了認錯之外，提供建設性的言論更是相對的重要。

單純的認錯道歉與補救，對於團隊形象與公司形象並沒有幫助。認錯、道歉、補救，只是最基本應該要做到的，在此之外，適度的檢討本身團隊的疏失在哪，並告訴 客戶我們有注意到這些問題，希望能夠提供一些改善方案，或是找出團隊出錯的癥結所在，跟客戶一同討論，看是否有改善空間，類似這樣比較具有建設性的言論， 是比較妥當的做法。

當客戶方有錯，可是自己這方也有錯時呢？例如問題出在於客戶未給予正確版本，或是未充分告知異動；但是自己的團隊並未很嚴謹的去檢視每一項工作，以致於未 及早發現客戶的疏失，像這樣的狀況，正所謂「嚴以律己」。身為廠商，雖不必要一味的矮化、委屈自己，但是更不能隨意的指責客戶本身的疏失，必須用更高的標 準去要求自己的團隊。正因為自己應當是要很嚴謹、很專業，客戶才會放心跟著自己協同合作來開發同一套軟體。

類似這樣的狀況，更是要提供具有建設性的言論，及早告知客戶，我們發現他們哪些地方有些疏忽，導致我們這邊哪些工作受到影響，以及時程受到影響；接著檢討 我們未能及時發現這樣的狀況，然後認真的提供一些可行的改善方案，以及可能的影響，甚至分析各個方案的優劣，提供給客戶作為參考，並請他們做出決定。

怎麼樣準確評估團隊效率

如果想要精確的評估團隊的效率，我想，正確的分析資料是最主要關鍵，其次是正確的分析觀點。

先歸納手上所有可用來作為分析的資料類型，接著找齊這些資料。

至於分析觀點，在分析初期，不妨試著用不同的角度去分析，取出某一類型的資料作為主軸，再取出另一個想要對比的資料來作為資料軸。

例如，若要分析每個人的產能（效率），以人作為主軸，以產量作為資料軸。
這樣可以很快做出第一張分析表，記得為它套上圖表。

不過，很快的，你應該會發現，光是這樣的分析表，並不足夠。因為每個人所負責的事務並不盡相同，有些任務比較艱難，需要花比較多的時間；有的工作必須等待其他人的結果，就像生產線那樣，你必須等待產線前端完成後你才能進行你的工作。

所以，如果分析表只是很單純的考慮人與產量這樣兩個類型的資料，並不見的能夠精確的反應實際的效能。

這應該是說這樣的分析觀點並不夠客觀。

To Leverage Translations and Apply Pseudo-Localization

My collegue ask me one localization question:
If the resource file has a great updated, and I have an old version's translation. How to leverage the translation, and also, how to apply pseudo-localization to those the newly added un-translated strings?

OK, here are the steps, seems to be a long list, at least it works.
To leverage translation from old version, you need to:
1. Create a new Catalyst TTK project file
2. Insert the original English RC file which was sent out for translation
3. Save this TTK file (OldRC.ttk)
4. Right-click on Resource.rc in Navigator window, and then select "Import Translations" function
5. Find the translated RC file which was translated from the same version as mentioned in step 2, use it as input file, wait for importing complete.
6. Save thsi OldRC.ttk
7. Create a new TTK project file
8. Insert the latest Resource.rc
9. Save this TTK file (NewRC.ttk)
10. Select from menu Tools -> Leverage Expert
11. Select OldRC.ttk as input file, wait for leveraging complete
12. Save this TTK file.
13. Use Extract function to extract the leveraged Resource.rc

To apply pseudo-localization to newly added un-translated strings:
1. Open the leveraged NewRC.ttk
2. Click from menu Tools -> Extract Terminology -> Glossary
3. Select "Tab Delimited", ,"From untranslated strings", "Include ampersands (hotkeys)", "Exclude locked/frozen strings". Then generate the glossary file.
4. Open the generated glossary file with Excel, there will be two columns of data, delete the second column, then save the file
5. In Catalyst, create a new TTK project file, insert the glossary file, then perform Pseudo translation. Save this TTK file.
6. Open the NewRC.TTK file again, use leverage function to leverage translation from the TTK file created in step 5.
7. Save NewRC.TTK, then extract Resource.rc

An I18N-ready Blog service?

My colleague asked me to input some Traditional Chinese characters to examine if Blogger can display them correctly.

Well, let's see what will happen:

許功蓋

The Killing Point of a Project

Joseph Philips, the Director of Education for Project Seminars, has an interesting description for the project phase deliverables and examing the project status and project advancement. He said, "The idea of killing a project at phases is why phase completion is also called a kill point."

Well, I do think it's quite interesting. The point to kill a project, project team, or the project manager?