在台灣建立研發中心？

現代經濟學鼻祖：亞當斯密的國富論中，描述產品價值有三個主要來源：「土地」，「資本」與「勞動」。其中土地泛指自然資源，勞動在現代社會不僅僅指人力，更重要的有執行力和創意的人才。

而今資訊社會中，因為交通和電信費用降低，以至於人才流動成本也跟著巨幅地降低(註1)。資本主義當然會讓「看不見的手」運作，而讓企業組織的經營，朝向最低成本最高效率方向前進。人才的取得也不例外。

最近一兩年已經有太多企業巫醫在討論「台灣人才外流」的問題。其中不外乎以聳動的標題。例如：

＊「我在台灣看不到工作的未來」... 或許只有你看不到也說不定？
＊「低薪惹禍誰想待在鬼島」... 低薪是一回事，但是台灣在所有地球上居住人口超過1萬個人的島嶼裡面，絕對排不到鬼島行列，請想一下菲律賓印尼加勒比海這些島國。
＊「台灣小而亂普遍又低薪」...的確台灣不大，但是普遍低薪和亂這兩個形容詞，卻在該文中沒有任何支持的數據和研究，只是個人感想當作新聞來操弄。

有時候，單看客觀事實並不有趣，不太能成為焦點，然而客觀事實卻是，想確實進展的最佳依據。所以，我們應試著了解，就經濟學的角度而言，企業組織應該「移動台灣人才」還是「在台灣建立研發中心」比較適合呢？(註2)

首先，要簡單區分「人才」，「員工」和「人力」。人力泛指勞動力，在最基本的教育水準下，就可學習工作得稱為人力，資本主義天生會使用最低薪資，在當地合法的範圍內榨取人力。員工指的是企業內受雇的所有人，可能需要某種訓練過的技能，但其學習能在短時間達成。人才比較難定義，在此暫時指需要長期間的教育培養，並且已經有7年以上的實務工作經驗的專業人士。而在此要討論的，就是「人才」的移動，而非人力或者員工的移動。

最簡單衡量人才流動應該是看「實際獲利」，包含薪資，居住成本等等。衡量一個國家的薪資有很多方式，雖然沒有最好的方式，但是觀察GDP和NNI都可以考慮。

可是，更有趣的數字在於GDP和PPP的差距。

最最粗淺的說，人均GDP表示此國家平均每人在該年生產的價值。三大組織：聯合國，世界銀行，國際貨幣組織：每年都會公布此數字。彼此間資料收集方法略有不同，數字彼此有一點點差距。

讓我們專門看五個國家的2016 GDP：台灣，中國，日本，韓國，新加坡。

	GDP美金
台灣	22,453
中國	8,133
日本	38,917
韓國	27,632
新加坡	52,961

這和我們內心理解差不多，台灣似乎遠不如其他先進國家，不過大陸的「平均值」仍然很低(當然比較特定區域：例如上海，那結果可能不太一樣)

然而，更有趣的數字是PPP：平均購買力。PPP其實和GDP的計算方式雷同，只是將匯率和物價也考慮進去。而PPP才是在該國家裡面的人，實際上消費真實情況。將GDP和PPP之間的差距，除以GDP就是「購買力相對於生產力的增額」。參見下表：

(本文的數字都是美金計價，並由wiki節錄國際貨幣基金會取得)

	GDP(美金)	PPP(美金)	購買力相對於生產力的增額
台灣	22,453	48,095	114%
中國	8,133	15,399	89%
日本	38,917	41,275	6%
韓國	27,632	37,947	37%
新加坡	52,961	87,855	66%

這個表顯示幾個事實：

(1) 在這五個國家內，日本的GDP和PPP最接近，而台灣差距最大。

(2) 單純看GDP，台灣遠不如日本韓國。然而，單純看購買力，2016年台灣比日本韓國都要來得高。

(3) 假設這五個國家的人才能力差不多，則在台灣建立以人才為主的研發中心是「最划算」的選擇。因為同樣價格的人才，在台灣實質獲利是最佳的。同樣100單位的錢，在這五個國家中，台灣實質可花費214, 日本是106, 中國目前是189,韓國為137,新加坡是166。(註3)

(4) 購買力和物價很大的關係，然而購買力要和GDP同時考量，因為就算有極低的物價，GDP不高也是沒有意義。

(5) 絕大部分先進國家這兩個數字都很接近，某些國家(例如GDP一直都排名前三名的盧森堡)甚至購買力增加率是負的！


然而，單就這兩個數字，很容易看出缺陷。例如把菲律賓加入之後變成下表：

	GDP(美金)	PPP(美金)
台灣	22,453	48,095	114%
中國	8,133	15,399	89%
日本	38,917	41,275	6%
韓國	27,632	37,947	37%
新加坡	52,961	87,855	66%
菲律賓	2,991	7,696	157%

難道字面上的解釋，菲律賓比台灣更適合建立研發中心？吸引更多人才。這張表可以解釋菲律賓可以找到更多「人力」。無法解釋為什麼沒有更多人才。因此，需要再加上另一個指數：HDI 人類發展指數。

人類發展指數計算很繁雜，最粗淺的說，指數越接近1表示這個國家越先進，先進包含基礎建設，教育等等。(註4)

	GDP(美金)	PPP(美金)	購買力相對於 生產力的增額	HDI	HDI權重之PPP	人才庫 划算指數
台灣	22,453	48,095	114%	0.885	42564.075	90%
中國	8,133	15,399	89%	0.738	11364.462	40%
日本	38,917	41,275	6%	0.903	37271.325	-4%
韓國	27,632	37,947	37%	0.901	34190.247	24%
新加坡	52,961	87,855	66%	0.925	81265.875	53%
菲律賓	2,991	7,696	157%	0.68	5233.28	75%

將HDI的權重考慮進PPP中，並按照購買力對比於生產力的增加，計算出「人才庫划算指數」。在此指數很簡單的看得出來，建立以人才為主的研發中心，還是台灣最划算。(註5)

當然這個模型有很多缺陷和假設，但是起碼它是以確切的事實作為考量，並且可以具體的討論和修改。相較於譁眾取寵的喊叫人才外移的嚴重性，相信來得有用。


NNI, GDP, PPP三者的細節，請自行參考wiki

(1) NNI (國民收入)
(2) GDP(國內生產總值)
(3) PPP(購買力平價) ：要注意的是，購買力評價，並不是很好衡量生活水準的方式。此方式較適合用於國家間互相比較，不太適合同一國家不同時間內比較。
(4) HDI 人類發展指數 
(5) 人才庫划算指數：=((PPP*HDI)-GDP) / GDP

---

註1：就在不遠的15年前(2003)，當時出差到歐洲每個月要額外花上5千元台幣左右的電話費網路費，用以和家人聯繫。如今出差到歐洲每個月頂多花1千五百台幣元，就可以獲得比15年前更高品質的視訊通話。

註2：這裡有很多假設，假設國際企業需要的是人力而非人才，假設企業組織是理性的，假設台灣人才也是理性的。

註3：這裡的增額，和個人在單一國家內花費的感受會有所差異。換言之，要有所感受，必須要在差不多時間，同時在日本和台灣取得相同工作的類似薪資才能做比較。

註4：也因為HDI指數很大一部分涵蓋教育，因此數值越接近1，國民教育水準會越高。

註5：沒錯 人才庫划算指數 是自己的推測 並沒有什麼研究根據...XD

畢業前六個月 - 建構職業生涯

在台灣的碩士生，畢業前六個月通常忙於論文。如果不考慮繼續就讀博士，畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說：畢業前六個月是讓你日後容易取得理想工作的最佳準備期間！

為什麼需要強調在6個月前建構職涯規劃？

環境上有許多現實的情況，例如，大部分好工作機會，其主管都傾向雇用有經驗的程式設計師。然而，絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此，剛畢業的學生如果剛好獲得一個適合自己，能夠成長，能夠有所貢獻的工作，那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作，或者即便不換工作，也能在目前的組織中成長。


反之，剛畢業的學生如果找到一個不適合自己，到處瞎忙，只是以時間換取薪資的工作，那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作，即便勉強換工作，也得靠運氣。

如果不想靠運氣，也沒有富爸爸，也不想自行創業(註1)，則要做的事情很簡單：

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實

考慮現況

首先，最重要的是，取得一些關於自己的事實。是不是想要做關於軟體開發相關工作？想要做哪一類型的相關工作？是否知道自己還缺乏哪些能力？哪些地方的工作，可在短時間有巨幅成長？

如果想要當個程式設計師，要考慮的現況：

1. 能使用哪些程式語言：是真的會，而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project，或者工讀經驗。

2. 能掌握資訊技術工具：是真的能掌握，而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如：工讀經驗，利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式：例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業，但是一開始就做SA/PM類型的工作，在軟體開發職涯裡其實不太腳踏實地，不過，真不得已可以參考這篇：資訊科技學生畢業後只想當SA/PM (三個創意作法)

設定短中期目標

某些職涯教練，或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在：例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣，但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期，讓自己在畢業前達某些技術性和非技術性目標，對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例，在畢業前六個月可以訂立以下目標：

* 開發並且將一個Android APP放在googlestore上：熟悉在android平台上開發APP，因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍，並且運用在現在的專案上。(含建構測試案例，執行測試，系統化記錄錯誤，...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」，則最後有沒有達到此目標是非常模糊的，但是目標是開發android APP並且上架，就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標，當然可以設定長期目標，但是需要伴隨可以逐步前進的短期目標。例如，或許你想要成為java大師中的大師，這可能要花上數年，但必定可以有個6個月能達到的前期階段，例如：「不靠任何補習方式，就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段

建立事實

在畢業前六個月，是最適合建立「事實」的時候。

建立事實，和畢業前花時間美化履歷表有很大的不同。

美化履歷表，是可以靠一兩個禮拜，找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分，再怎麼美化也沒有意義。

前一段關於短中期目標，只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生，對自己的技術能力非常沒有自信，然而又想從事軟體工程師的工作，可以考慮建立以下三個事實：

* 透過自己決定的開發專案(例如Android APP)，徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具：可以參考這裡。
     (b) 在開發專案的過程中，徹底運用此工具，確保自己的專案品質。
     (c) 將結果詳盡記錄，就成為自己能當QA的事實

* 透過自己決定的開發專案(例如Android APP)，徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎

      (b) 需要徹底了解如何branch，如何merge，如何處理conflict

      (c) 其結果構成了解專案開發的基礎事實

* 取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大，但是取得成本不高的情況下，展現了你至少是瞭解Scrum。

---

註1: 想要自行創業的準備不太一樣，首先要了解創業如何必然成功，再參考其他相關資料。

註2: 花大錢考管理類型證照其實不划算，但是可以考慮花小錢，請參考這裡。

註3: 對，我們知道React Native可以讓你不需要寫java，但是這裡只是舉例而已。

Scrum - 檢討完了...然後呢？

定時檢視目前的進度與問題，是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後，舉行檢討會議(驗屍會議)，找到在過去一段時間最需要改善的事項。

請參考前篇：Scrum - 回顧。檢討？驗屍！

假設團隊依照正確的Scrum的事實認定原則，踏實的列出問題。接下來就應該「解決」它。誠如前篇，所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」，這種情況的歸屬就屬於Scrum Master。

稍微強調一下，只要Scrum Master稍微不注意，就會讓歸屬人這件事情變成互相指責，試圖鞭屍，對人不對事的謾罵。但是，如果不試圖歸屬某人，就常會讓問題懸空，無法真正解決。

只要確切的定義真正的問題，就等於是產生了一半的解決方法。

不過有些常見老問題，還是值得探索一下。

例如：

(1) PM/PO 常常在Sprint中間要求修改規格，甚至新增額外的項目...

(2) 某個人的產出和績效，明顯的比其他人差很多...

(3) 某個功能的實際時程遠超過預估，以至於某些團隊成員需要很大幅度的加班...

而常見問題都有其共通性，常見的試圖解決方法也有共通性。然而，以Scrum而言，Scrum Master在此扮演非常重要的角色，因為所有的問題，其有效解決方式，應該都和Scrum Master本身有關。

Scrum Master必須要掌握以下原則：

原則一：試圖做到完美是不可能

    完美的team不可能存在，每次sprint應該試圖解決最重要的幾個問題就好。

原則二：持續做同樣的事情，不可能產生一樣的結果

    參考愛因斯坦的名言：Insanity: doing the same thing over and over again and expecting different results.

原則三：任何創意方式都應該嘗試：包括「無作為」

    
    當定義好問題之後，下一個sprint應該要試圖改善問題。但是，改善問題的本身有時候需要「時間」，而由於Scrum每個sprint都只有4週，Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟，有時候過度反應某個未來可能不存在的問題，也沒太大意義。

但是也請謹慎區分「無作為」和「逃避」，這兩者只有一線之隔(註1)。
    

針對身為Scrum Master的人，在此提供一些解決問題的範例：

(1) 時間相關的問題

由於時間是軟體專案衡量進度的唯一單位。時間是最初，也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。

--- 在Sprint中某些時間估計錯誤，導致加班 ---

這在專案前幾的sprint特別常發生。建議解決方式有：

(a) 探詢真正的需求點和重要的事情，移除根本不重要的工作事項

(b) 減低時間浪費，特別是大型專案中開會的時間

(c) 無作為：因為團隊已經了解問題，而且下個sprint估算也應該會比較正確，加班問題很可能自然消失。

(d) 厲行「最大時間」單位，假設是1天。換言之，工作項目超過1天，就需要分拆成不同的項目，或者不同的完成階段。這樣可以在比較短的時間內，很快發覺時間錯估的規模。


絕對不建議解決的方式是：讓某些人繼續加班；犧牲品質；謊報進度...

--- 某個人的事情老是做不完 ---

這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而，絕大部分的團隊都應該利用分工導致的比較利益法則（參考這篇），根據相對優勢來分工。

細節請參見下一節：(2)人才和人力的問題


建議解決方式有：

(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人，無論再怎麼調整，也都沒有意義。應該用最快的方式讓他好好離開。

(b) 讓他做可以用時間苦勞換取績效的工作，而非需要能力才拿達成的工作 ，例如將其人力保留用於意外任務或者PM臨時修改需求 

(c) 找到他的相對優勢，換言之，Scrum Master要略為調整scrum的精神，改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。

--- 團隊有意外任務 ---

這個問題也很常見，可能的解決方式有

(a) 無作為：經過一番思考，發現這只是意外，下個sprint應該不會發生

(b) 根據前sprint所耗在意外任務的時間，重新估計下個Sprint意外任務要花的時間

(c)  設定意外任務防火牆：可以找一個專門的人，處理所有意外任務。不得已的時候也可以找工讀生，委外人員等等。

(2) 人才與人力的問題

許多軟體開發的相關研究，都一再顯示，一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍，當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說，超過5個人的團隊，就自然而言有人能力以及產出比較好，而有可能有某人能力和產出都比較差。

一個團隊裡，人力和人才必須要平衡，並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力，哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之，即便大家都認為他能力很好，但是某些原因，他的產出只有一般般，那麼他就不是人才，而是人力。

但是，無論是人才還是人力，團隊的組合的先決條件就是1+1>2，團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時，應該優先考慮分配工作上的比較利益法則。（台灣經濟學的入門書通常會用蓋木屋與磚屋的例子：參見這裡）

要注意的是，過於追求表面上的公平，但是反而會團隊績效的降低。公平雖然重要，但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標，而非追求個人公平。其方法有：

(a) 讓團隊成員看這篇文章

(b) 不要設定表面的績效衡量標準(例如：bug數量) 而是設定每個人不同的標準

(c) 所有不同的標準，朝向同一個目標。例如，在籃球比賽中，得分籃板助攻失誤阻攻...等等都是指標，而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。

(3) 目標的問題

目標指的是現在要做什麼，現在什麼事最重要，要達到什麼效果...簡單的說，每個專案都有其最終目標，但是在專案開發過程中，都有中間目標，PM/PO理論上應該會透過各類型中間的目標，達到（也有可能會修正）最後的目標。

然而，Scrum為了讓開發人員專注於工作，在一段短時間的Sprint是不允許修改目標。因此，如果遇到PM中間亂入，常常會造成團隊困擾。

但其實更為重要的是，如果團隊方向具有很大的不確定性，Scrum Master應該視其為「機會」，而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。

--- PM客戶或其他長官常常突然要求修改做的一半的規格---

(a) 無作為：因為這可能是專案開始的意外插曲，Scrum Master很確定下個sprint不會發生

(b) Scrum Master作為擋箭牌。在Sprint中間過程，用盡一切手腕，擋住所有需求修改，直到sprint結束為止。但是，允許PM重新開始一個sprint。

(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌，將擋下需求，或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼，放在另一個branch(分支中)，每個sprint結束之後，才檢討他的branch是否要合併。這個做法的依據在於，通常會修改的規格，都會被一改再改，與其影響團隊作業，不如將影響範圍降到最低。

--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---

這樣的抱怨也很常見，它不是問題，而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可：

(a) 我們頂多白做4個禮拜，如果是project結束才發現這件事情？那浪費的成本是高得嚇人。

(b) 如果是PM不喜歡，那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤，在檢討會議應該要求PM改善此項目。



如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。

---

註1：許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外，還有「足夠自信」vs 「自我感覺良好」；「自卑」vs「謙虛」...

註2：請參見這裡

註3：如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com

資訊科技學生畢業後只想當SA/PM (三個創意作法)

很多畢業生，資訊相關系所，擺明就不想要寫程式，但是卻又想要加入資訊科技產業。老實說如果是做行銷(Marketing) ，業務(Sales)，或者支援類型工作(admin, finance)倒是也無不可。

只是很多資訊科技學生，似乎想要當SA(系統分析師)或者PM(專案經理)，也許只是覺得名字好聽，或者認為：既然是資管學生應該做點管理工作也不為過。

這種想法其實很危險，也不可靠。

系統分析師(SA, System Analyst)扮演的角色在各公司都很不同，有些很像是業務助理，有些是專案經理的小跟班，有些是扮演IT對外採購的角色，不一而足，單看是去哪個公司。

而專案經理(PM, Project Manager)情況可能稍微好一點，顧名思義就是：負責某一個或者一些專案的進行。20年前PMP證照流行的時候，專案管理本身被視為一門複雜的學問，當然在軟體或者新創網路科技產業，PMP那套不太可行，Agile/Scrum/XP 等等方法論興起，讓PM多少都不太可能單純只做管理。

不管如何，缺乏實務經驗(指的是起碼3-4年努力寫程式的經驗)就去做SA/PM等同於是碰運氣，就算花大錢去取得PMP證照以及其他相關證照，也沒什麼用。這就像是從來沒打過籃球的人，想要當NBA籃球教練一樣幾乎不可能。

雖然很不贊成這樣的事情，但與其碰運氣，不如提供實務作法。

(1) 創意一：讓自己真實變成SA/PM (要花一點錢)。

在學校的專案課程中，讓自己變成PM然後讓某同學變成主Co*(註一) 是絕對沒有用的。任何有經驗的主管，一定看得出來你只是負責動動嘴巴，補補文件。

你可能需要付出一些代價，例如100美金，然後想一個app的好主意，到outsourcing網站，像是upwork.com，雇用一些印度，巴基斯坦工程師，實際上幫你寫程式，這時候你100%是PM，你控制了整個專案的進行，負責製作需求與控制工程師進度。更好的是，這還是個跨國專案。

不過，實際上這樣做出來的東西，失敗率很高，特別是假如這次你第一次當PM - 這裏的PM同時兼具Project和Product。因此，對此創意方式要有正確的期待，也就是說事情的成敗並不是重點，而是在此過程經歷了什麼。這非常接近NBA例行賽開打之前的練習賽，練習賽獲勝固然可喜，但比勝利更重要的是團隊的磨合以及戰術的演練執行。

註一： 主co = 負責主要coding。這個名詞是最近幾年面試學到的，意思差不多就是這個專案課程，程式都是我寫，事情都是我做，其他人出嘴巴。

(2) 創意二：組織同學來做專案

等一下，前一段不是說在學校專案當PM然後某同學來主co是絕對沒用的嗎？為何這裡又說要組織同學來做某專案？

不一樣是，組織同學來進行非課堂的任務，遠比修課需要的專案來得困難，但是更實際。

第一種可能是，到市場上接專案本身到不是問題，因為一開始取得專案的目的，並不是獲得高額利潤，因此價格競爭是有可能的，畢竟你的目的是要取得成為SA/PM的事實，並不是真的要從專案獲利。

然而，業主可能也知道，這種情況下的專案可能不見得做的很好，因此價格競爭有時候也沒太大用處。

第二種可能是，自己找事情來進行。十幾年前BBS風起雲湧的時候，大部份架設BBS的人，都並非學校課程，也不是因為賺錢獲利，只是覺得好玩有趣。架設BBS讓當時的學生取得寶貴的UNIX（FreeBSD等）的營運經驗。如果想當PM，也可以自己找事情，組織同學來進行。不過通常這種情況需要是以技術強度來領導，因此遠比接專案困難。

(3) 創意三：尋求業界導師

由於linkedin和其他社交工具的發展，很容易可以找到業界資深的學長學姊。只要是在他們時間允許的範圍，很容易可以請求協助。當然，每個人的時間有限，所以最好的方式是，互相幫忙，互蒙其利。當你在與不太熟悉的人聯繫上之後，可以用交換的方式，讓他們指導你，並且為你的成就背書。

舉例來說：你可以作為業界導師的私人虛擬助理*(註二)一段時間，幫他處理非機密的相關業務，例如，調查研究競爭對手產品，處理文件，處理linkedin或者其他socail media的日常文章，業務聯繫等等。而作為交換的是：他可以指導你實務專案上"他實際上做了什麼"。數個月後，你甚至還可以取得業界導師的背書以及推薦。

另一個做法是尋求成為學徒的機會。學徒制度是一個非常古老的學習方式，在某些情況下，學徒制度非常有用。如果你是一個剛進學校的研究生，尋找指導老師是最重要的一件事。而如果你是一個畢了業就想要當SA/PM的人，找到正確的業界導師，會讓你事半功倍。

我們會在未來的文章探索學徒制與軟體專案發展的關係。





* (註二)：關於虛擬助理，請查Virtual Assistant

---

沈思 

如果本文對你沒幫助，還請與我們聯繫取得免費協助。

1.  再次強調，在沒有技術背景的情況下，最好是別真的想做SA/PM

2.  如果真的想做，那麼務必考慮這三種方式。

3.  當你想要什麼，執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項，想要什麼最好是先構思自己要怎麼取得。

軟體專案的啟動：三件必要事項

萬事起頭難，但是軟體專案的開始卻不很難，至少比收尾容易。


專案在開啟之前，相關人等必須一定要聚集在一起，至少達成一件事情：就是要討論專案如何開始。這個討論很多地方稱之為Kick-off會議。（專案啟動會議）。

在啟動會議結束前，就必須要能至少完成，或理解以下三件事情。如果不能完成或理解以下事項，當然還是可以開始。不過好的開始，雖然是成功的一半，但壞的開始，一定是失敗的八成。

要注意的是，這三件事情只是開始，並沒有涵蓋技術上的真正開始（例如High Level Design）

(1) 了解專案目的

一個軟體開發專案的目的，一定不會是完成某些程式碼功能。通常是帶有應用意義。瞭解其應用意義，才是真正的專案目的。在不了解專案目的的情況下，隨著專案進行走偏的機會很大。

舉例來說，也許某企業組織在一些腦力激盪之後，想要有自己的即時通訊app（類似line），並且也組織了一個小組來進行開發。而它的目的是希望企業員工在用手機的時候能有完整保密的訊息功能，而且非企業員工不可能使用。

單就以上描述而言，重點是在於(a)企業員工使用手機(b)完整保密的訊息估能(c)非企業員工不可能使用。

然而，是不是手機app並不是目的。是不是自己重頭到尾開發，還是利用現有套件也不是目的，有沒有上架也不是目的。

有些時候，專案目的不是這麼容易清楚了解，許多大組織有很多隱晦的目的。即便是人數極少的新創組織，有時候也容易把將組織目的和戰略執行方式混淆。因而，在專案啟動會議的時候，務必再三確認專案真正目的。

有一個簡單的方式可以判斷是否為真正目的。如果目的的描述，非常具體的指名特定技術，在盈利企業的專案裡，它就很有可能不是目的。舉例來說：『我們要開發一個Android APP他可以在開機的時候就自訂在背景執行，而且當發現手機的GPS位置到某一個範圍時，就寄出email』，這非常有可能不是真正的目的，而如果團隊照著進行，也許沒有大問題，但如果能真正了解目的，有可能有截然不同的開發方式。例如真正目的可能是：『我們是個高級西餐廳，需要一個行動裝置，了解某個之前的客戶，如果剛好在我們餐廳附近，我想們要通知他一些折扣訊息』。當目的和技術脫離，軟體團隊才會找到更正確地解決方式。以這個例子來說，寄email大概不是什麼好方法，在背景執行的app也遲早會被使用者發現過於浪費電而停掉。

專案目的也許隱晦，但是要再三確認，實務上也花不了多少時間。

(2) 專案設定

任何專案一定有其限制和背景因素。這些暫且叫做專案設定(setup/config)。

專案的限制有很多來源，有可能是先天限制，例如奧林匹克訂票系統，自然就有在某月某日結案的先天限制。也有可能是後天限制，例如最多能花多少經費。不過無論如何，一定有很多很多限制。在這一階段我們要了解的限制，最少要有以下這一點：在範圍，時間，成本這三個變項之中，哪一個是可以犧牲的。所有專案管理最基本的認知：範圍，時間，成本中一個專案最多只能控制兩個，細節可以參看這裡。

當然有些人可能會列出6個變項，或甚至9個大項目。但重點不在有多少變項，重點在於專案的開始就要先有認知。

專案的重要背景因素，如果有的話，也需要先行認知。背景因素有可能是限制的一種，有可能和目的有關。例如，企業目前營運狀況極為良好，是一種背景因素，他可能會讓專案遇到困難時，有額外的助力。又例如，這個軟體專案是為了新產品，而目前，在市面上已經有競爭對手：這是一個可能在不預警的狀態下，改變專案目的或者增加專案限制的背景因素。

通常只要開口多問幾次，不需要花多少時間就可以了解很多專案設定。

(3) 如何合作

專案成員如何合作的方法論有很多，但最根本的概念就是，合作的本身，不會造成合作的困難。合作本身，能讓團隊效益提高，讓1+1>2。

(a) 認知事實

團隊活動有很多事實會發生，最不好的事實就是『大部份的人都有認知偏誤』。偏誤很難完全屏除，但盡量貼近事實是最好的做法。

事實最好在一開始就是大家所先認定好，特別是困難的事實。舉例來說，專案有三個人，其中兩人才剛畢業，另一個人已經在公司工作35年，事實就是一定會有溝通障礙，技術銜接障礙等等。另一個例子：專案有三個人，其中一個人正在負責其他專案，一旦認知到這點，就一定要把此人在專案未來時間分配上，特別減少某個比率。而這減少的比率應該在這個階段就已經先認知。


(b)角色定義

許多專案管理的方法論，會對角色有各式各樣的定義，例如RACI，PMP都有各自的角色定義。然而，也許比較適合軟體專案的還是Scrum的定義。

但不管採用什麼方法論，至少有個角色一定要有明確的指名。那就是這個專案的負責人，無論是叫他PM也好，team leader也好。明確地找出這個人，讓他負責專案合作上的各種安排。

(c)工具

而軟體專案最少的必要使用工具也要在這裡簡單定義。例如使用git來作為版本控管工具，簡單的使用便利貼加上白板來作為目前進度顯示的工具。工具不見得要是某軟體，在專案執行過程中，要確定工具的本身不會變成專案的負擔，不會變成阻礙，不會耗費過多時間，更重要的是，一定不能成為某些事情的藉口。如果在專案過程中聽到有人反應：『XXX還沒做，是因為build server要執行編譯android的時候，』因此過多的指定工具只會造成問題。

(d)溝通

專案溝通最好還是以面對面為主，我個人是非常反對大型報告會議，但是非常贊成Scrum的每日站立會議的務實方式。每日站立會議作法是：每天固定某一個時間，大家聚在一個地方，每人用1-3分鐘的時間，只說明三件事情（要記得大家先說明，然後要討論是說明完之後再討論）：

   第一：上次會議到現在為止，完成了什麼事情。

   第二：接下來到下次會議之前，打算完成什麼。

   第三：遇到什麼困難。

所有人都說明完畢之後，再根據每個人遇到的困難，也許是一起討論，也許只有某幾個人討論。這樣的會議，會讓大家集中心力在之前決定好要完成的事項上，而且有兩個人在會議室裡面相談甚歡15分鐘，其他人都在看自己的筆電的情況。

如何合作有可能是最花時間去討論的項目。採用過去成功經驗，摒除失敗的經驗是最好的方式。



以上三件事情在大型專案中，也許頂多花上一兩天的時間就可以完成。最不值得做的，就是因為『乍看之下專案好像很急』而草草啟動，忽略了這三個必要事項。

---

沈思：

如何知道這三件必要事項有產生？這三件必要的事情完成後，應該有相對應的簡要文件。如果專案開始的時候，沒有簡單的一頁說明以上三件事情，恐怕表示大家沒有真正的共識，或者這些共識很快就遺忘。

但是相對的，假如在這個階段，就已經產生了鉅細彌遺地各類型文件，那麼專案成員也應該要警覺。帶領專案者，可能有很大的管理上的障礙或疑慮。也有可能這個專案的真正目的和實際上說明的不同。

創新公司軟體專案時程管理 (三個基本概念)

絕大部份創新公司，其實在衡量任何事情的時候，其所消耗的標準，並不是真正的金錢，而是創業夥伴們的時間。

每個人一天只有24小時，雖然今年是2015了，但是你還是不可能有時光車讓你爭取更多的時間。因此，專案的時程管理變得很重要。

時間管理的技巧方法很多，如果沒有概念可以先參考這裡。但最好先建立一些基本的觀念：

(1) 觀念一：每個人的時間效率有天壤之別

特別是技術類型公司，單指寫程式的效率來說，最好的程式設計師，和最差的有很大的差距。有些研究說是10倍，有些說是上百倍。

不只是程式設計，其他工作類型也一樣。更有甚者，品質的產出也被證實和速度沒有很大的關係。換言之，又快又好是絕對有可能的。

(2) 觀念二：每個人時間的比較利益不同，因此可以分工

那麼，這樣來說我們雇用三個強人不就搞定一切事情了？首先你不可能有機會在一開始找到三個強人，因為強人早就已經有非常好的工作。就算你運氣好到不行，真的雇用了三個強人，有趣的工作可能只有一個，也不可能三個人做同一件事情。

所以分工變得很重要。比較利益法則（參見wiki)解釋了為什麼多人合作有可能1+1>2。只要大家負責的部份，是相對其他人比較專長的部份。

不過分工是否得當，會有相當大的差距。在超大型組織裡面，以現代科技發展的程度而言，分工會自然發現，即便沒有效率也會發生，例如，任何開發中國家，經濟發展的時候，投入初級產業(農林漁牧)的人自然就會慢慢變少，換言之，只要少數人的努力就可以提供食物給其他人，而其他人就可以去做更多讓生活更愉快的事情。

但是在小型組織，例如只有5個人的startup，就必須要時常檢視這樣的分工是否合理，能否達到綜效。

(3) 觀念三：中短期的專案，其完成時間早就已經固定

一個為期1-5個月的專案，當目標和資源已經定義出來的時候，其實完成的時間早就已經被上帝決定好了。問題在於，創業夥伴們，能不能事先看出來。如果一開始對時間的估計有誤，接下來新的專案就要把失誤考慮進去。

對，沒錯這就是Agile/Scrum的基本要素，無論什麼理由，當你打算完成的事情決定好產出的目標之後，時間早就已經被決定，你能夠做的就只是盡自己的能力，縮短預測的失誤，而經過幾次中短期專案，理論上，創業夥伴們的能力和資源調配方式，已經讓大家可以準確預測完成的時間。



越是能了解時間的控制，就越不被時間控制。

---

沉思：

考慮以下說明：時間基本觀念很重要，因為創新公司，事情完成度是以時間來衡量，而不是以事情的進展來衡量。為什麼呢？

跨國專案，發生於startups的三個原因

談到跨國軟體開發專案，大部分的研究或者討論案例集中在大型組織。但其實，最有機會跨國界發展專案（特別是軟體專案）的其實是創新公司startups。

什麼是跨國軟體開發專案？很簡單就是一小群人，分別處於不同的國家，為了同一個專案目標而一起努力。

為什麼跨國軟體開發專案會發生在創新公司？

第一個原因是創新企業的彼此合作。

創新企業，越能取得全球開發資源 越能專業分工。前一陣子很多與container技術相關的創新公司(cloud startups)，許多除了取得很多投資者的注意，彼此之間也會互相合作。例如coreos.com，除了把自己的產品以開放源碼(open source)的方式放在市場上測試之外，他肯定還是得與其他新創公司合作，讓產品可以先行在比較願意嘗試新技術的組織裡試行。

在同一個所謂育成中心的新創公司彼此合作是很合理，但如果你的新創公司鎖定於全球市場，最好一開始就先嘗試接觸其他國家的新創公司。因跨距離的合作而成功，這樣的例子屢見不鮮。（當然因為距離與文化失敗的也不是少數）

第二個原因是委外開發。

由於網路發展太過快速，使得大部份的國家(也許中國例外？）互相聯繫的管道速度變快非常多，而軟體開發專案，理論上彼此之間只要有共同的開發工具平台（例如git 加上 jenkins 加上 jira）再配合視訊電話工具 -- 目前最跨國的工具仍是skype，就可以一起合作。對於企業來說，只要妥善面試，外包給印度，巴基斯坦，白俄羅斯的軟體程式設計師，其實效果跟雇用當地的工程師其實差不多。（前提是要面試得當）

另外一種委外開發是因為個人背景關係。舉例來說http://www.cognitivescale.com/ (算是2015年最受重視的startups之一）他的創始人是印度人，雖然總部是在德州Austin，但很明顯還有許多研發資源直接設於印度。

第三個原因取得跨國客戶。

internet快速發展的讓人忽略轉捩點的發生，各個國家的資訊障礙彼此之間差異越來越小（恩..也許中國再次除外）換言之，如果一個新創公司的產品，是屬於internet上銷售並且使用的產品，那麼一開始就要考慮取得跨國客戶。

如果要取得跨國客戶，某些時候還是必須要利用非本國資源。以台灣初創公司的角度來說，由於距離世界另外兩大市場（北美，歐洲）仍然有距離，在產品開發上，至少在介面，使用者功能部分，如果委外由英語母語者合作開發會比較接近現實。

跨國專案有其困難度，但如果分工得當，其效果遠比在單一區域來的好。

---

德國柏林的創業環境-三個觀察

在台灣看2015年相關的國際新聞，會發現德國一直都是某些事件的主角。從希臘債務問題，到中東難民大舉前往德國，再到前陣子VW發生造假事件。然而，眾多新聞之中，其實悄悄然一直有件事情，在過去5年中慢慢發酵。

那就是柏林的年輕化以及歡迎各國（嚴格上來說應該是歐盟各國）年輕人加入柏林創業。


在跨國合作的經驗告訴我們，每個人其實都不一樣。如果有人概括性的說，某個國家的人都怎樣怎樣，那幾乎都是某種類型的偏見。通常認識一兩個某個國家的人，就會把這一兩個人的個性行為，當做該國的代表人物。偏誤率實在很高。

我認識並且有私交的德國人做事很務實認真精細，當我去德國政府網站查詢創業相關資訊時。實在很佩服該網站務實的精神。這個半官方網站是德國工商總會(IHK)，類似台灣經濟部底下的半官方機構。在他的網站上，你很快能找到重點，

例如你可以下載這篇（Starting a Business in Berlin) 來看看要怎麼在柏林創業。這篇雖然說是A Beginner's Guide，但是其實重點都有講到，而且幾乎沒有廢話，也幾乎沒有官腔官調。順道抱怨一下，以前台灣某些政府網站以及公開資訊，實在都很官腔官調，感覺上是要建立一個門檻，讓老百姓越不了解越好。

這裡建議，只要是想創業的，最好把這份文件詳細閱讀一下。它一開始先希望你自己了解一下，自己為什麼而創業。並且實務的建議你，哪些創業類型適合你，甚至也會警告你，哪些創業的原因很難成功（像是如果是因為長期找不到工作而想要創業）。

接下來不能免俗的要說明哪些註冊公司的方式適合（例如合夥公司，股份有限公司等等）但是在法規的說明上，講的清晰易懂，在註冊公司的種類上，甚至會說這個種類是最多人選的，或者是最少人選的。然後，它就開始說明，如何計畫自己的生意，從business model到Elevator Pitch都有。最後還列了在德國完整的相關資源。

重點在於，它把創業的從頭到尾描繪清楚。讓讀者有概括性的認知。這的確是我看過最清晰易懂的政府文件。更重要的是，它是英文版，不是德文版。

三個觀察：

(1) 相較於英國美國還是稍微保守一點

在不前往英國的情況下，台灣人絕對可以去英國註冊一個公司並且開始營業。如果是經營資訊產業，例如經營一些手機APP，那麼甚至可以永遠不去英國。

美國資訊產業對於創新有極大的樂觀性。對於招募資金甚至極為寬鬆。

相較之下，德國還是略顯保守。原則上要成立股份有限公司需要25000歐元的門檻（這個門檻跟台灣差不多）。無限公司容易成立，但失敗了要賠身家，大概很少人想這麼做。因而相較於英國美國，其法規略偏保守。

另一方面，對於哪些人可以來經營企業也較英美保守。

在英國基本上，只要能證明存在感，大概就可以開公司。美國也是，但是如果人住在英國美國當然需要工作證（綠卡）或某種簽證（工作簽）。但如果不住在當地，英國是可以註冊公司並且營運的。

然而在德國，不管有沒有住在當地，你必須要是(a)德國人，或者，(b)歐盟某國家的人，或者(c)有商務協定關係的國家，目前是美國，加拿大，瑞士。這三種條件下的人，才能在德國創業。如果不是以上三種，必須要先到德國大使館取得特別的簽證才行。但就目前歐盟28個成員國，加上美加以及鄰近的瑞士，應該也足敷柏林成為夠國際化的都市。

(2) 相對便宜的環境聚集了人才

在歐洲主要150個主要都市中，柏林的物價是排名(2015年)很後面。單指所謂西歐先進國家而言，根本沒有任何一個城市比他還便宜。

當然相對便宜，而且容易發展的環境，很快吸引各國的人才。事情總是有正反兩面。已經開始有很多人認為這樣的環境不見得是成功的：可以參考這篇 (作者甚至抱怨柏林沒人在講德文)

當一個環境聚集許多遠道而來的人的時候，幾乎一定會發生各類衝突，然而良好的衝突也是創意發生的所在。不同的人也因而在具有刺激性的環境激勵與成長。

(3) 年輕的老都市

柏林這個名字有紀錄已經有七百年，而存在已經四五百年之久。然而由於之前東西德分裂，柏林花上近10年才真正完成整併基礎建設（例如地鐵）。透過基礎建設的重建，柏林成為一個嶄新的都市。

柏林相較於倫敦它的地理位置接近於歐洲中心點，無論是北歐中歐南歐東歐，與柏林的交通距離都差不多，在兩德合併之後，它很快速的再次轉變。

雖然在金融產業上，倫敦仍然是歐洲最大的都市，但是在文創，軟體，網路等等新產業上，柏林已經後來居上。簡單的搜尋"柏林 創新"就可以找到很多相關資訊。

---

沉思：

* 再次強烈建議一定要拜讀一下這份官方文件（Starting a Business in Berlin)

* 沒時間看的可以與我們討論。

* 數年之前，有機會與一位玉山創投的德國人（Volker Heistermann）吃飯聊天，當然對他一個人能來台灣試圖建構創業環境是蠻佩服。如果有想要了解德國創投對於創業者的看法，倒是可以和他詢問一下。

* 在本文撰寫的時候，剛好看到中國買房團想要到德國柏林投資房地產。就德國對於房價物價的長期控制來說，也許一開始會有影響，但是大幅炒作的機率應該不大。

委外(outsourcing)軟體開發的三個要點

委外開發outsourcing行之有年，它只是另一種形式的分工方式。

然而，委外的軟體開發，卻是困難異常。即便是簡單的網站設計，不複雜的智慧手機程式(app)，在缺乏正確的溝通認知情況下，還是有可能以意想不到的結果。如果你的專案經理，或者是負責與外包商溝通的人，以下是你最少需要知道的要點。對於不了解的事情，有些時候可以用嘗試的方式學習經驗，但很多時候最好還是參考一下過來人的經驗。

這三個要點，是在已經透過正確的方法選到正確的廠商的前提下。如果還不知道怎麼選擇正確廠商，可參見這裡。

(1) 知道這次外包想要的結果是要什麼

作為專案負責人，你需要知道期待的外包的結果。

假設所有的軟體開發，都是外包商進行，那表示你必須期待外包商有負責管理整件事情

所謂的整件事情，是從設計，細部設計，定義管理的方法(例如Scrum, agile)，程式碼版本管理(例如github)，測試，檢查驗收。換言之，雖然你不負責整件事情，但是你卻要比外包商更了解，這整件事情要怎麼處理。這樣你才能有效控制外包結果。

當然如果外包的範圍很小，例如繪製android logo，那麼你只要確定外包廠商知道android logo有哪些尺寸與標準，約定好時間，就可以等著看結果。

如果外包的範圍中等，例如處理前端網頁javascript以及html部分，但是需要存取後端的API，而後端API是核心任務，因此是內部自行開發。那麼就要界定清楚範圍，你需要能完整提供API文件，不然至少要有API簡單的訓練課程，以及範例程式。由於開發活動必須有一致性，因此還得提供廠商版本控制系統的權限(例如gitbucket)，另外還需要控制開發週期，以及哪些使用者功能(user story)需要先完成，哪些後完成。換言之，如果外包範圍是軟體開發的一部分，那有可能關鍵的結果在於某段程式的正確產出。

(2) 清楚說明規格

在台灣對規格書(spec)其實不那麼重視。尤其是所謂的系統整合商的IT專案。因為有太多情況，規格和最後實際的結果已經截然不同，而規格書很有可能是一邊開發，一邊才跟著寫。根本不切實際，最後都淪為最菜的SA所負責最無聊的工作。

清楚說明規格並不代表要有250頁這麼厚的規格書。而是要有在做重要的事情上，有不可否定的結果。舉例來說，google.com的搜尋畫面，其實也有很多功能，但是必有一個規格是：一個讓人輸入資訊的欄位，並且按下enter之後會直接進行搜尋。某些SA/PM在撰寫規格時會無窮盡的增列細節，例如欄位是要多寬，最多輸入多少字元，反斜線要不要處理，諸如此類。當然重要的規格細節要詳述，但是不能無止盡的窮數之。

對於規格書沒有基本認知的話，可以先參考這裏。

已經有很多撰寫規格書的經驗，但自覺從來沒寫對的話，可以參考這裏。這個spec只有短短20頁，去頭去尾真正的spec可能只有17頁，他沒有很多細節，也沒有用很複雜的UML圖。而且spec徹底與實作方式無關。

(3) 確定對方理解什麼

這點聽起來很不可思議。但是在現實，實在常常發生。那就是即便語言上沒有問題，在溝通認知上，還是有極大的差距。有些幫助有效會議的技巧，通常會提到，會議結束的時候，請最重要的幾個人，用很短的時間，簡單說明會議之後他要去做的事情。如果在一個常常進行無聊會議的組織裡面，可能會有很戲劇性，很荒謬的效果。(請參見"開會開到死")

對委外開發而言，很多時候不是面對面的會議，再加上語言的不同，更容易產生誤會。執行者(就是外包商負責人)必須要有創意的使用結構性合理的方式，來讓彼此理解工作內容。

首先，使用文件是最合理的。尤其是對跨國廠商而言。而文件的長短與格式並不是重點，重點在於有沒有表達你要傳達的資訊。

更有甚者，文件常常有先後次序，你需要知道外包商到底有沒有看那份最重要的文件。

一個簡單的作法是：在最重要的文件(例如規格書Spec)的莫約3/4處，夾一段文字，說如果你看到這份文字，要立即email給某人，並且夾帶一段簡單的"口令"，因為這可以證明他有認真看過，如果在X月X日前，沒有回覆給某人，你會假設他無法完成第一個milestone。

這個作法不管在第一次有沒有達到目的，接下來外包商自然就自動被訓練為，你的重要文件，他一定會看。

管理委外廠商有很多創意的作法。可惜的是，這些作法必須根據靠經驗和實際情況而改變與適應。很難光是用教學的方式就體會。

---

參考：

* 虛擬助理

資訊系所學生的國際觀- 三個觀察

過去幾年來交換學生越來越盛行，基本上跟大學一樣，沒有交換不了的，只有想不想交換這回事。然而，資訊系所學生的國際觀，整體來說似乎沒有跟著地球扁平化，世界縮小話而改變太多，相反地類似美國種族融而不合的情況似乎更多。

(1)：想要國際化

隨便問幾個學生，認不認為國際化很重要，想不想加入跨國公司取得國際化工作經驗。幾乎沒有一個學生說不。

然而，除了少數加入open source計畫的學生之外，很少有參與國際軟體開發活動，除了交換學生之外，也很少有學生能想到"長期"培育自己國際觀的方式。

(2)：片面資訊

最最常見的片面資訊在於：

外國人＝美國人 ......(外國人說話都很直接，老實說恐怕只有美國說話很直接)

國際觀 = 美國觀 ......(International View = American View)

進入大公司 = 有很多"國際化"機會..... (這部份是事實，但某些小公司更多)

學生要有國際觀 = 要留學 要交換學生 要遊學 ......(部分是事實，但也看過太多留學交換的時候都跟華人混在一起，那老實說也沒特別意義)

google = 搜尋全世界....(起碼要扣掉中國和斯拉夫語系國家，這樣就少17億人耶)

(3)：等著別人來幫忙

在面試的時候，常常會被問"公司是否能提供訓練"。組織根據需要當然會提供訓練，一個好企業也絕對不會吝嗇於訓練費用。

但更重要的問題在於，你除了上學之外，花了多少時間在訓練自己。

同樣的問題在國際化視野上也是，除了讓學校老師幫忙，你自己曾經為了想要"國際化的視野"為自己做了什麼事情？

---

沉思項目：

在不使用google/yahoo的情況下，你上網查詢資料會是要怎麼開始？
你是不是能找到在東歐常用的web mail (除了gmail, yahoo之外)？
你是不能推測這個世界人口的各大洲比率大概為何？
你是不是能直覺猜測斯里藍卡人均收入？
除了BBC/CNN 的強烈報導之外，你覺得最近幾個月(2015年秋天)為什麼梅克爾會歡迎難民。