顯示具有 outsourcing 標籤的文章。 顯示所有文章
顯示具有 outsourcing 標籤的文章。 顯示所有文章

8/17/2017

如何學好工作英文 - 極簡計畫書



在台灣職場上,英文能力是工作能力重要的一環。英文能力不好,並非職業生涯就會失敗,也不是就不能賺很多錢,只是會「受到各種限制」。有正確足夠的英語文能力,會讓職業生涯有「更多選擇」。

除了在自己的職位上,有需要以英文讀寫和對跨國組織的溝通之外。還有兩件極為重要的
其是:

(I) 擴大其他知識學習的能力。當你可以順暢地閱讀聽取英文資訊時,你路上的知識來源,就遠比只會中文多了數倍。

(II) 擴大資源取得的範圍。當你可以流暢的使用英文,就可以把想做的事情,透過網際網路外包給其他國家。


就和其他計劃一樣,執行力永遠比計畫詳盡來得重要。而執行力是透過「限定時間」的「分階段」採用「正確方式」達成。


如果你目前還沒有自己的方法,或者,曾經試過自己的方法只是不太成功。那麼請考慮這個極簡一頁計畫書。

到此下載計畫書

這個計畫乃是參考(註1)的做法,與實務驗證改善而來。此極簡計畫適用於TOEIC 695分以下的上班族。


「如何學好工作英文 - 極簡計畫書」的使用步驟如下:

(1) 找到原因,定義目標


第一個,也是最重要的步驟是「坦白原因,定義目標」

每個人真正想學好工作英文的原因都不同。而真正的原因才是讓個人努力的動力。

找到自己想學好工作英文的真正原因。可以用消滅法,判斷這個原因是不是最重要原因。在計畫書中,將最重要原因填在80%欄,次要和第三原因填在16%欄與4%欄。將80%欄遮起來,想像一下,當這個原因消失之後,自己是否就不想精進工作英文了。如果這個原因消失,但是自己還是很想精進工作英文,表示不是真正原因,或者描述的不正確。

請填寫找到真正原因填寫於左上角。

目標是在未來一段時間(14週)預計取得的成長。

極簡計畫有兩個既定目標:

(a) TOEIC 800以上 
(b) 能以英文簡報10分鐘關於現在的工作進展 

另外,可以去掉目標(b),也可以自己制定目標(c)。但是,沒有特別原因的話,必須要留著TOEIC 800的目標。

在右下角的目標準備,就是為了確保自己已經報名TOEIC


(2) 學習材料準備


極簡計畫學習教材都是不用錢,而且對工作英文來說效果很好!

「起床後15分鐘」的教材是BBC網站,需要電腦或者手機才能使用。

「空閒的10分鐘」教材是一本英文書。


(a) 聽/說教材


聽和說請用BBC網站教材。這些課程都是以影音方式大約3-7分鐘。
請先設定好書籤於瀏覽器中,或者用手機也可以。實際學習方式請看: (3) 執行 


BBC英文學習課程:有用!簡單!又不花錢!

BBC English You Need
http://www.bbc.co.uk/learningenglish/english/course/english-you-need

BBC English At Work
http://www.bbc.co.uk/learningenglish/english/features/english-at-work


(b) 空閒時間的純閱讀:How to Read a book


建議直接列印出來。目標是看完第一,第二部分。約138頁,每天10分鐘閱讀一頁半左右。


(3) 時間分配


太長時間等於是挑戰自己的意志力,但是每天工作很累的人的意志力是有限的(註2)。

這個計畫是以3個月(14週)為目標時間,每週6天,每天僅25分鐘。這25分鐘,分成早上起床後15分鐘,和空閒10分鐘。

早上起床後15分鐘


早上一起床,要花15分鐘學習英文。如果你平常是9點起床,就改成8:45,如果是8點起床,就改成7:45,如果是7:30起床,就改成7:15。無論如何,一定是起床後的第一段15分鐘是在學習英文。早點起床學英文,絕對比晚點睡學英文的效果強太多太多!

空閒的10分鐘


在每天空閒的時候:坐捷運,上廁所,上班休息時間等等,花10分鐘閱讀。強烈不建議在睡覺前閱讀。這10分鐘最好是連續的10分鐘。

實際作法請看(3)執行。

在計畫書中央有個6x14的表格。在表格上有開始日期,下方有結束日期。直接填好開始日期以及14週之後的結束日期。

時間耗費其實很少,所以要確切執行,其實不會是時間問題,也大概不會是意志力問題。恐怕只是「習慣」與「執行技巧」的問題。

14周之後,無論如何,時間到就結束,並且以實際方式檢討結果。

(3) 執行!


當極簡計畫準備完成,接下來當然就是執行極簡學習計畫。
計畫執行非常非常簡單,所花費時間也非常非常少。

執行是每天,或者說每星期至少六天,做三件事情:
(a) 早上起床學習15分鐘以上
(b) 空閒時間閱讀10分鐘以上
(c) 把計畫書上的進度表格塗黑,並且自我檢查是不是有按照計畫進行

(a) 首先是起早學習15分鐘


所要做的事情是到BBC網站上,在BBC English You Need或者BBC English At Work選擇一個課程來「聽」。只聽不看,有聽不懂的暫時不理會。BBC的課程很短,大約5分鐘而已,聽完之後,在看上面的英文說明,還有不懂再查字典。

經過3-4天,如果你認為太簡單,BBC也有進階教材:

http://www.bbc.co.uk/learningenglish/english/course/towards-advanced

但是對於簡單的教材必須熟悉到「輕而易舉的理解」,才能進展到進階教材。而坦白說,倘若你的TOEIC成績不到850分,進階教材可能不太適用。

(c) 其次是每天空閒閱讀10分鐘:


找空閒10分鐘閱讀
教材是How to read a book。閱讀方法是印出來,在每天空閒的時候:坐捷運,上廁所,上班休息時間...等等,任何空閒的10分鐘都行,連續10分鐘閱讀。強烈不建議在睡覺前閱讀。


閱讀方式是,直接看完,中間看不懂的字先圈起來,如果可以的話,猜測一下不懂的字的意思。讀完一個段落,約1.5頁,閉起眼睛回想一下這一頁的意思,然後,再去查字典。切勿背單字,應該去了解整個句子的意義。

How to read a book是本經過設計的老教科書,用到的單字有限,其目的是在教學生「如何閱讀英文書」所以,當你看完這本書就可以一舉兩得,確保可以你的英文閱讀能力,真正往前進。

(d) 每天檢討:把計畫書上的進度表格塗黑,並且自我檢查是不是有按照計畫進行。

這個部分最重要的是,不要欺騙自己。請參考下一段(4)過程檢討。


(4) 過程檢討


極簡計畫書中央有個6x14的表格表格。每個格子代表一天,每天當你完成「早上起床15分鐘」和「空閒10分鐘」的學習之後,就可以把它塗黑。只完成一項就塗一半,都沒做就留空。

必須要把這個計畫放在每天都一定會看到的地方,例如辦公桌的某個小角落。表格上面只有開始日期跟結束日期,中間並沒有日期,但請不要趕進度,每天最多也塗黑一格!

如果有不預期的情況發生:例如連續兩天沒有按照進度進行。不要試著去彌補它!不要在某一天連續趕兩三天的進度,而是要找到一個方式,讓這不預期的事情,「以後」不要再發生。不彌補是因為過去的事情本就「已經過去」,和彌補錯誤比較起來,在極簡計畫中,更重要的事不讓錯誤再發生!


(5) 計畫結束


極簡計畫的概念是,無論如何,結束時間一到,計畫就結束了。

這時候必須要知道和原定目標有多少差距,如果TOEIC考了815就表示達成,考了790就表示沒達成。如果可以輕鬆地用英文解釋現在的工作狀態,就表示達成了。

然而,因為是你自己自定的目標,其實在計畫結束後,可以很清楚的看到過去14週以來的成果,即便沒有達到目標,應該會有大幅進展。也不見得要對自己太嚴厲。

重點在於結束之後,可以再次啟動下一階段的工作英文學習計畫。把握原來的極簡計畫的關鍵:限制時間,清楚目標,過程執行,檢討結果,並且不要花太多時間,當然就可以讓自己的下一次計畫效果更好。

到此下載計畫書


問題與解答:


Q1:可否修改計畫書?


Ans:極小幅度更動當然可以,例如把14週變成12週或者15週,把每天25分鐘改成30分鐘。但強烈不建議進行大幅更動。因為此計畫是經過設計與驗證,對絕大部分上班族是最能在耗費最短達到最大的工作英文進步。

Q2:我沒辦法早起學英文。


Ans:無論你現在做的是什麼樣的艱難工作,早起15分鐘通常是可接受的範圍。如果你沒辦法早起學英文,大概就表示你不太想或者不需要精進工作英文。

Q3:這計畫對我來說太簡單?


Ans:此計劃是用於大學研究所畢業後開始工作2-3年的上班族。如果你英文已經很好了(例如,TOEIC已經850分以上)當然就不適用此計畫。

Q4:此計畫對我來說太難?


Ans:如果你已經大學或研究所畢業,然而仍然覺得很難使用英文聽說讀寫,這計畫可能是有點難,但絕對不是做不到,只看你有沒有決心而已。

Q5:為什麼一定要去考TOEIC?


Ans:TOEIC是目前為止,比較有公信力的商用英文測驗,它並不困難,很適合「不準備」的情況下完全按照實力去應考。當然應考前還是要看一下題型,考試方式,跟考試用具。




參考:

* 註1:在義務教育的語言學習,大部分的人都認為沒效率而且也不實用,不僅只是台灣而已,而是放眼世界皆然。有本書可以參考一下: Fluent in 3 Months。這本書有中文版。

* 註2:意志力的研究有很多矛盾的地方,請參考這裡




12/05/2016

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




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


假設團隊依照正確的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

12/25/2015

給不寫程式的人:發展手機APP事業的三步驟



有智慧型手機的人,都會使用某些應用程式(APP)。

你一定也有常用的APP,多少也有自己想要的功能。也許你覺得自己有一些創新的APP想法。或許,你覺得現在用的Line總是有些地方很不滿,你覺得只要照你的想法去做,一定會讓使用者更滿意。

但是,也許你完全不會寫程式,或者雖然是資訊科技背景,但是對於手機應用開發缺乏經驗,也或許只是沒時間學... 最後自己總是覺得無法實現想法很可惜。

其實APP和一般的電腦應用程式不同,不會寫程式的人,其實也可以創造自己的APP,加入這個競爭激烈,但卻很有利可圖的市場。

如果規劃得當,是一個能以極少量成本,兼職創業的好方式。更重要的是,如果規劃得當,這是個極低成本的lean start-up,可以讓你多方嘗試可能性,但不用負擔失敗的風險。

不會寫程式,或者沒時間,但仍能發展自己的APP的成功案例是很常見的事情。例如airbnb,uber等。

事實上,有許多創業家一開始就選擇踏入手機市場,就是因為APP是能在極端有限的資源下,實現自己的創新想法的最容易的選項之一。

主要原因可能是:


在技術上:兩大主要智慧型手機陣營:iOS和Android都盡可能APP的開發方式標準化,簡潔化。目的是在於吸引更多開發群眾。而市面上也有太多工具,可以在某種程度上產生APP,例如appopus.com 或 appsgeyser.com 都可以把文件轉變成APP。技術上來說,等同於擁有一個可以個別銷售的電子書APP(註1)。換言之,APP的製作有越來越簡單的傾向。

在環境上:智慧型手機的市場遠比傳統電腦來得大,而進入市場的門檻極端的低。根據實際的經驗:以電子書而言,撇除掉撰寫的成本,僅就上架與行銷可能只要200美金。如果是具有傳遞訊息(類似Line)加上社群功能(類似facebook登入等等),大概只要準備700-1000美金。如果是多媒體播放(類似youtube)則僅需要800-1200美金。而以上的參考數字,都涵蓋完整的完成具有完整前後端功能的APP,上架以及基本行銷。換言之,市場環境,大幅傾向低成本門檻。



在實際經驗中,任何人只要能學習以下三步驟,一定可以開發APP並藉此開創事業。(註2)

三步驟:想法具體化,找到正確的人完成APP,進入市場。



步驟一:將想法具體化

將想法具體化:是指把自己對APP的想法盡量用文字以及圖形表達出來,並且對於APP決定好基本的定義。

表達APP的方式有很多。首先要簡單地寫下自己的想法:例如一個可以互相傳遞即時訊息的APP(類似Line)但如果對方沒即時看到,就改用傳統手機訊息傳出。

接下來,使用網路上免費的畫圖工具,例如invisionapp.com 或者 fluidui.com,將自己的心理的想法具體化。


簡單的通訊APP(類似Line)的設計,練習個幾次,任何人都可以做簡單的設計。


想法具體化不是只有手機流程設計。最起碼還包含兩件事情的具體化:誰是使用者,以及:定義成功。


誰是使用者?

在你的心目中,用有哪些屬性的人會使用這個APP:就是所謂的市場區隔。雖然他可能會改變,但在這個階段,你需要自己具體化一個清楚的使用者描述。例如:「在台灣,25-35歲,單身男性,就業中,未與父母同住,使用Android手機」。

如果你的目標客群很大,例如:「在台灣,使用Android手機」。也並非不可,但是在之後進入市場時,可能不容易看到基本行銷的效果,或者需要極大的努力才能看到行銷的效果。目標客群越清晰,越容易看到行銷的效果。


如何定義成功?

在你的心目中,當APP完成放到市場上,經過3個月,達到哪些事情才算成功?自我具體定義成功,是發展APP的重要基礎。

成功可能是獲利。例如,假設APP是要收費,或者間接收費(例如廣告),上架經過3個月,實際營收達總額達到1000美金就算成功。

但所謂成功,更有可能不是設定為獲利。例如,APP是免費,而且也沒有廣告,但上架經過3個月,希望實際使用者達到1000人。因為很多APP一開始是希望有大量使用人數,等到夠多人使用時,再考慮獲利模式就變得很簡單。(例如Line是免費使用,一開始是沒有廣告)

有創意的定義成功,能夠讓不寫程式的人,更容易看到手機APP的事業的可能性。例如:APP是免費,也沒有廣告,但上架經過3個月,希望所有已經安裝的使用者,解除安裝的比率低於15%,而且每天使用這個APP的比率要超過65%。換言之並不在乎多少人使用,只在乎這些使用者是真心的黏著在這個APP上。


步驟二:找到正確的人完成APP


好像很明顯,你需要找人幫你寫程式。

但是,其實你真正需要的是:找人幫你完整完成開發APP這件事情。

完整開發APP指的是:

(0) 將想法具體化   <- 這一點在步驟一中,一定已經完成。
(1) 先把APP的流程決定好
(2) 根據流程畫出APP的樣子
(3) 加上自己認定的顏色,圖樣,Logo
(4) 根據設計,撰寫程式
(5) 測試程式,確保品質大致沒問題
(6) 將APP上架:放到googleplay或者applestore
(7) 利用各種行銷方式,讓使用者下載,安裝,使用APP。
(8) 每一段時間收集相關資訊,了解此APP是否成功。


(1)-(3) 就是APP的設計,完成APP設計之後產生出APP的mock-up。這件事情可能在步驟一中自己做,也可以找人來做。

一般人都直覺地認為,「找人去做」表示執行(4) (5) 這兩件事情。但其實你真正需要的是(1)-(8)都需要有人執行。

找到正確的人的方式有很多,首先,先確定自己(1)到(8)能做哪些事情。然後,剩下的事情都要「委外開發」。

委外開發的最直覺方法,就是到外包網站上招標。例如:upwork.com ,guru.com, freelancer.com。外包的價格差異很大,而且軟體產生的品質和價格沒有直接關係。關於如何招標尋找正確的廠商,請參考這裡

基本的參考數字:一個類似line的訊息傳遞APP,開發需要120-200美金之間,如果要涵蓋基本的UI/UX設計,另外需要50美金,如果要含品質測試以及上架,另外還需要30美金。也就是整體大約200-300美金可以完成一個還不錯的APP。(這個數字不適用於遊戲APP)

委外開發的其他常見有:找有技術能力的志同道合的好朋友;找學校的相關科系學生專案,等等。不過,這些常見方式,都需要一段時間的磨合,以及一段更長的時間的互相體諒與了解。




步驟三:進入市場



進入市場包含「上架」,「基本行銷」。想要長期留在市場,還得進行「維護」以及「未來計劃」。


上架:

完成APP之後,當然就是要進入市場。進入市場第一步就是將APP上架。如果是Android,自然就前往googleplay,如果是iOS,就去applestore。

「上架」需要一些步驟,對於非資訊科技背景的人來說,可能稍微困難,因此,在步驟二:找到正確的人完成APP的階段,必須要把上架當作工作的一部分。

Googleplay上架請詳閱這裡。Applestore上架請詳閱這裡。強烈建議不要看市面上的書籍,或者參考某些部落格的文章來當作上架教學。因為,這些書籍文章可能都是「過期的資訊」。使用官方文件,作為上架的使用指引,才不會浪費自己的時間。



基本行銷:


不過,上架只是讓市場有機會看到你的APP。這個世界上有近千萬個APP存在,要讓使用者能真的下載使用某APP並不容易。因此所謂進入市場,必須考慮基本行銷。

行銷可以很簡單,也可很複雜。最基本的情況是:你需要盡可能讓很多人知道有這個APP,下載這個APP來使用,如果APP需要付錢才能使用,則還得包含說服使用者鼓起勇氣付錢。

最最最基本行銷的過程是:找到目標客群,針對客群送出訊息,等候以及檢視結果。


找到目標客群:


定義目標客群應該是在第一階段完成的事情。這階段的目的是找到目標客群的「資訊傳遞」方式。最簡單的方式,是透過小型行銷公司,直接把你要找的目標客群的email找出來。只要你的定義夠清楚簡單,可以在前述的外包網站,找到小型行銷公司,以30美金的價格,取得大約500個大約目標客群的email。或者,也可以用15美金的價格,送出1000個目標客群的潛在facebook貼文。如果願意在行銷投入更多的資金,可以用200美金,購買一個月的google ad,讓自己的APP廣告出現在某些google adsense能抵達的範圍。


針對客群送出訊息:

取得email之後,可以利用現有的email行銷軟體。常見的像是mailchimp.com,klaviyo.com或者zoho.com,送出廣告信。信中當然就是這個APP的介紹與連結,還有一些說服別人使用這個APP的方式(例如抽獎活動之類)

email 行銷是很老套,但也由於是老套,所以很容易看到效果:例如多少人有打開email,多少打開email的人真的有下載APP。

如果是facebook行銷,可以花15美金,送出1000個目標客群的潛在facebook自動貼文。也可以花60美金,雇用虛擬助理,以人工的方式,逐一在潛在的facebook粉絲頁或個人頁,貼上獨一無二的訊息。關於虛擬助理,請參考這一系列文章

如果是google adsense行銷,或其他網路廣告方式,預期每個月,可能會花上200美金。

但無論如何,手機APP事業的基本行銷費用,其實並不高。盡量利用前述的免費或者簡單的方式。不會超過200美金就可以達到某個程度的效果。

檢查結果:

等候一段時間,檢查看看APP的成功定義是否有被滿足。

如果你的成功定義已經被滿足。那麼恭喜你:你的APP是千萬中選一的好APP。你的APP事業發展在未來可能輕而易舉。只有極少部份的情況,是可以在一開始就這麼順利。
如果你的成功定義,沒有被滿足。那麼還是得恭喜你:你知道過去的做法一定某處可以被改善。根據手上有的資料,回溯之前的過程,找到可以改善的點,加以修改,然後重新觀察。一半左右的APP是落在這個情況。重點在於,如何根據現有資料修正APP或者修正基本行銷方式。


如果你的成功定義,不但沒有被滿足,而且實在差距太遠。那麼還是得恭喜你:因為你只花自己一些思考時間,以及500美金左右的成本,就證明某個想法在目前不可行。目前你的損失很小,可以再多嘗試其他主意。更重要的是,簡單而低成本的經歷失敗的「失敗經歷」極為難得可貴,是創業成功的不二法門。請參考確保創業成功一文。




參考: 

發展自己的APP事業,看似複雜,其實就是這麼簡單的三步驟。當你了解這些步驟,甚至可以把整件簡單事情,交由專門協助產生POC(Proof of concept)的企業來處理。

而你自己,只要專注在於「出個好主意」就好。




註1:如果你寫了一本電子書,可以在亞馬遜銷售,也可以在其他APP管道銷售。那為什麼需要自己獨立產生單一電子書APP?有很多可能:例如你想單獨獲利,不想讓各類銷售管道分享微薄的利潤;或者這是免費電子書,你想要免費分送,因為裡面可能有置入性行銷的訊息等等。

註2:開創APP事業如同本文所說很簡單,但要確保事業能成功極端困難,請參考這篇




12/15/2015

資訊科技學生畢業後只想當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.  當你想要什麼,執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項,想要什麼最好是先構思自己要怎麼取得。





11/09/2015

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



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

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

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

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

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

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


第二個原因是委外開發。

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

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


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

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

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



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






11/05/2015

選擇跨國委外開發商的務實流程:三個要點





不管委外開發什麼東西,東西有多複雜,時間有多長,正確的選擇委外廠商就等於成功了一半。

會使用委外開發的目的一定涵蓋兩點:

(a) 讓組織專注在重要的事情,
(b)成本效益。換言之,選擇委外開發的廠商或個人,也至少要涵蓋這兩點。

而對於新創公司來說,委外還有另一點優勢:就是

(c)迫使你自己更瞭解自己在做的事情

因為你需要完整的把細節用文件簡要說明清楚。如果你自己沒辦法把事情說明清楚,那麼不用說無法委外,你可能根本無法有效率的創業。這樣的創業只會讓你日以繼夜的努力,卻事倍功半,就算成功也是運氣成份居多。

在做任何選擇的時候,都要把握20/80法則,也就是用最省時間方式,確認最多關鍵成功因素。建議使用以下三個實際要點:

(1) 要點一:要確定理解規格


確認理解規格,很多人以為是外包商的責任,其實應該是業主的責任。因為業主不應該雇用一個不理解規格的人!換言之,業主要能在委外活動開始之前,確定外包商能理解規格。

這點聽起來很直覺簡單,簡單到就像大家都知道不能闖紅燈,上班不能遲到,開車不能喝酒,寫程式應該要有Unit Test一樣。可是實務上就是有很多人做不到。

根據經驗,所有外包的失敗,有起碼75%的源頭,可以追溯到對規格的不理解。因此確定外包商理解規格才能外包是第一要務。

那要怎麼在還沒簽約前,確認外包商理解規格?

用電話/email問他:Do you understand the spec?然後他會回答:Yes。....這做法是100%完全沒用。

請他看完規格書之後,問他一下:Do you have any question。然後他會回答:No。...這做法一樣100%沒用。

另外,規格也要對QA稍作定義,倒是不需要洋洋灑灑列出421的test case,只要簡要的把最重要的幾個使用者行為定義清楚即可。

最簡單的作法是用過濾刪選。實務作法如下:

1. 篩選掉不認真看文件的。


首先在發標之前,先把規格簡單的描述一下。然後在文件的中後段,穿插一句話:If you see this, please add the secret code "Bravo" in your proposal。這個目的很簡單,就是要刪掉,連看都不看就想要來投標的人。因為透過網站來投標的成本很低,所以有很大的機會亂槍打鳥。要投標的人,一定會提供proposal,而實務經驗來說10個來投標的,竟然只有5個有真的看文件,並且把Bravo這個字眼放在proposal的第一行。

換言之!用一個簡單的方法,就可以篩選掉一半根本沒認真看文件的人。沒認真看基本說明的人,可能壓根錯估時間跟成本,萬一選到這樣的外包商,最後吃虧的一定是業主。


2. 篩選掉無法回答三個技術問題的。


準備三個簡單但是重要的問題,讓外包商回答。舉例如下:

(a) Did you use dynamodb (aws) if you did, let me know why you use it.

(b) Please simply describe how to let android app use fb login.

(c) what is the most difficult things on our specification?


依照這三個問題的回答,業主很快可以判斷,剩下來個5個之中,哪些對於要做的事情比較有信心,哪些是完全沒信心。


3. 篩選掉估計時間不合理的。


前兩個問題都通過之後,就請剩下來的人估計時間。這時候估計的時間,請他要給完成的時間點,而非要花多少天完成。外包商花多久時間,多少人力完成,其實業主不會需要知道,也不可能知道。然而,業主需要知道,幾月幾號幾點,會取得什麼樣的東西。

如果完成的時間本來就預期很長 - 所謂很長是指超過2週。就應該請外包商分里程碑(milestone)分階段產出,分階段驗收完成。時間估計不合理的長或者不合理的短都會有問題。但是,在這個階段倒是可以多花幾分鐘,了解問題在哪?例如也許是他剛剛好這禮拜要畢業,準備畢業考試之類的?有些時間的延宕是可以接受,但是一定要知道原因。


以上三個篩選步驟都很簡單,任何複雜的專案,都只需要花15-20分鐘就可以完成上面三件事情。但是這三步驟絕對會讓你節省不少寶貴時間。

另外強調一下。規格不在於細節,所以鉅細彌遺地250頁規格書一定也沒用。不如一個兩頁的精要版。


(2) 要點二:要確定目標


讓外包商理解目標,以及確定外包商理解目標,也是業主的責任。

所謂的目標是指,根據規格完成的東西的真正意義。例如,規格書上詳述要完成一個android APP,並且可以用fb login,並且可以記錄帳款...等等內容。但是,所謂真正目標可能是:必須要在某月某日之前,讓具有某些功能的APP上線,並且可供使用者免費下載。這目標的確和規格書一樣,但通常規格書沒辦法表達優先順序,以及真正的完成,以此例子來說真正的完成是要放到google play上線通過。

當選定外包商之後,一定要花20分鐘,以電話或者視訊溝通這次外包的真正目的,而規格書是達到真正目的的最大參考,可是規格書本身不是目的。這點一定要說明清楚。

(3) 要點三:要有plan-B


選擇委外開發,通常不會是把核心項目委外開發。因此,理論上外包失敗應該不會有滅絕性的結果。

所謂的Plan-B就是要有外包失敗的計畫。Plan-B類似危機管理(Risk Management)不過遠比危機管理簡單,它只需要知道:外包失敗的結果,以及如何因應。


1.  定義何謂失敗:


首先一定訂清楚定義何謂失敗,每次外包行為只有失敗跟成功兩種,沒有中間的。模糊不清的選項只會讓事情變得更複雜。以前述APP開發為例,所謂成功指的就是在某月某日之前,具有某功能的APP上線,並且通過所有定義好的當初簡要的QA測試。所謂失敗指的就是不滿足成功的所有條件。換言之,失敗不見得我們就不付給外包商費用,有可能外包商分階段完成,但最後完成的日期比預期晚,那仍然是失敗。


2. 失敗如何因應:


一但確定失敗,就一定要用預設因應方式。以前述例子來說,因應方式可能有很多種。

例如,雖然功能都可完成,QA測試也沒問題,可是已經確定無法準時上線。所以因應方式就是把計畫往後推延N天。然而,這個N天必須要是事先定義好。不能是當失敗發生才定義。原因在於,唯有事先定義好的失敗處理,才不會讓其他事情跟著失敗,如同骨牌一樣,一路倒個沒完,那就等於是把核心關鍵任務外包。因為延宕N天是事先定義好,換言之,其他事項早就已經把N天計算進去,因而這個N天就變成無關緊要。

然而,如果不是時間,而是外包商倒閉,或者壓根就消失,當然就要啟動重新委外行動。一樣會延宕N天。這N天,一樣也是必須事先定義好。

換言之,失敗因應其實都和時間有關係。當然和外包成本也有關係,只是通常這樣的外包最後真正付出金錢損失通常不大,因為現行的外包平台大部份的情況下,都會保障業主不會付出冤枉錢。反倒時間與精神損失才是重點。


這三個要點,無論專案有多麼大,有多複雜,都可以在1.5個小時之內完成。根據我們過去N次規模不同的外包經驗來說,採用簡單的三要點作法,讓我們自己將外包成功率從30%提高到90%。







10/27/2015

委外(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。

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

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





參考:

* 虛擬助理




10/24/2015

使用虛擬助理的三個要點



僱用兼職的國外虛擬助理(Virtual Assistant),可以大幅節省許多庶務時間。再往下看之前,請先參考關於這篇虛擬助理如何幫助創新公司

如果你對虛擬助理已有基本認識,想要開始利用虛擬助理節省你的時間,這裡有幾個要點請務必留意。畢竟金錢損失是小,浪費寶貴時間事大。



(1) 明確定義工作範圍


假如你打算把虛擬助理當秘書用,要請記得他不是5x8的工作小時,也無法幫你泡咖啡,影印東西。

你必須要明確的定義工作範圍,如果一開始你無法定義明確的工作範圍,可以先與虛擬助理討論先試著僱用10小時看看(大約40-80美金),而第一個小時就請他列出,他最能做的事情。在最下方的"沈思"有我的印度虛擬助理所列的事項。

當然如果採用虛擬助理公司,那該公司本身就有可以明確定義的工作範圍與事項。

而接下來的重點就是交代工作也要簡單,清楚。老實說,其實你越能簡單清楚的交代工作,表示你對自己或自己的公司情況越清楚。

一個不好的範例:Please do some study on how can I buy things from taobao。 - 如果你只email給助理這句話,然後他就埋頭開始工作,那麼可以100%肯定,絕對不會達到你要的結果。

這個任務有太多基本事情沒交代清楚:沒說明什麼時候要完成,沒說明要完成什麼(是一份投影片?還是找到一個help文件?)。沒說明可以花多少時間,請要記得助理是算時薪。

另外,即便基本事情交代清楚,如果他不知道什麼是taobao掏寶,他還是得先花一點時間研究一件其實你講1分鐘他就會了解的事情。

所以基本上至少要做到這樣:

Please do some study on how can I buy things from taobao。Instructions:
(a) The delivery should be a 3-4 page slides。
(b) should deliver before Oct/25 10am GMT+8
(c) estimation of utilised time should be 1 hour. If spend more than 1.5 hours just stop and send me whatever you have on hand
(d) taobao is a chinese online shop, pretty similar with amazon in US but for some political reason, it is not easy for a taiwanese to buy things on taobao. However, it is still possible. I want to simple know how.


(2) 慎選

虛擬助理種類大致分成:虛擬助理公司,個體戶兩種。要選擇虛擬助理,先要了解這者的差別。然後,在選擇區域。這在虛擬助理如何幫助創新公司都有詳細的說明。

然而,在還沒開始之前,沒人可以確定你找到一個好助理,所以試用是非常重要。大部份的公司都可以提供一小段試用期間(可能要付費,可能不用付費),然而個體戶大概就沒辦法,所以可以先與個體戶討論一個5-10小時的試用,不管5-10小時結果如何,你一定會付給他15-30美金,根據5-10小時之後的結果,再來談合作。這樣的模式通常比較能選到不意外的結果。

試用的時候也有很多祕訣。礙於篇幅,有興趣的可以email與我們聯繫取得免費咨詢。對了,email需要寫英文,因為是我們公司的虛擬助理協助處理email:)

(3) 檢視成果

檢視成果的本身,必須要是簡單的,如果一份工作你自己可以花2小時做完,結果你讓助理幫你進行,之後你卻需要花2小時來檢查或修正結果,那其實也沒啥太大意義。

根據我們實際的經驗,兩個每週工作10小時的助理,似乎比一個每週工作20小時的助理來得有效。主要的原因在於,可以讓他們互相監督,互相備份,互相檢查對方的內容。舉例來說,如果其中一個助理負責每週定期blog文章,那他完成的條件就是請另一個助理來檢查,當檢查通過就算完成,理論上,你就少了很多檢閱的工作。




沈思:

  •   網路上有不少虛擬助理的建議,然而或許因為語言的距離,導致台灣使用的人很少。這一點有機會被打破嗎?
  •  我的印度助理所列出的她可以工作事項:


1. Email Management/Filtering
2. Setting up Autoresponders (Aweber, Mailchimp)
3. Booking appointments with clients
4. Following up with clients/customers (sending thank you and other reminder emails)
5. Receptionist duties (answering occasional calls)
6. Calendar Management
7. File Management (organizing files using Dropbox etc)
8. Database building (eg. updating email or contact lists on your CRM)
9. Research on certain topics for blogposts, newsletters or others
10. Personal errands (purchasing gifts for loved ones / family members online)
11. Hotel and Flight Booking
12. Transcription (transcribing voicemail, video or audio, podcasts etc.)
13. Taking down minutes of meetings
14. Creating basic reports (reports on weekly tasks, deliverables, sales)
15. Preparing Slideshows (Powerpoint Presentations)
16. Liaison between you and other team members
17. Recruitment (source for other team members like writers or graphic artists) 18. Set-up Social Media Accounts (Facebook, Twitter, LinkedIn, Youtube)
19. Manage and update Social Media Accounts
20. Manage your Blog (Basic WordPress Skills)
21. Publish posts on your Blog (content you provided)
22. Filter and reply to comments on your blog
23. Answering support tickets (with the use of Zendesk)
24. Blog commenting (to increase links to your site)


25. Participating in discussion forums or message boards (more promotion!)

10/20/2015

委外(外包)對創新公司的三個主要協助


所有網路創新公司,幾乎都不可避免利用某些廣義的委外服務。這些服務可能是免費,也可能要收費,因網際網路的快速發展,數十年前自己得動手做的事情,現在都可以找到對應的服務。

隨便舉3個例子。

email:現在幾乎很少人架設自己的mail server,而都改用gmail/zoho/godaddy等等,但先千萬不要再用msXX.hinet.net這類不能設置自己的domain name而且甚至還要錢的email服務。

server:AWS/linode/digitalocean等等都是常見的cloud server服務,讓你不用擔心server架設維護問題。

金流:以前都要自己設置刷卡,匯款等等問題,現在有paypal可供國際化付款服務。

然而,除了顯而易見的網路服務之外,在台灣似乎比較少人用軟體開發的外包服務。

例如:fiverr.com,可以協助你產生企業logo,快速設計網頁,進行SEO,測試軟體,撰寫部落格文章。upwork.com,可以找到很多軟體工程師,撰寫定義好的程式,做好網頁服務,做出facebook app,撰寫mobile app等等。

這些看似接近核心的任務,其實妥善分工,外包之後反而對自己有利。

對新創公司主要有三個協助:

(1) 時間與資源專注

新創公司最重要的資源其實不是資本,而是少數幾個夥伴在一起努力的時間。如果你要做的事特殊的big data分析演算法。你和幾個夥伴應該把時間精力集中在這個演算法上面,而使用者介面,企業logo,企業網站,介紹的blog文章統統都應該外包給其他人,只要你們能清楚定義並且審閱結果即可。

(2) 強迫模組化分工

如果一個三個人的小公司,每個人的專長都是programming,但對UI/UX都不擅長,一開始根本不應該花大錢去雇用一個frontend+UI/UX專家,而是根據自己的需要把UI/UX模組化之後外包。這樣一開始的設計就已經考慮模組化,將view確實分開之後,以後的維護,成長也都容易得多。更有甚者,所有人都還是集中心力做最專注的事情。

模組分工強迫對工作有清楚的定義。如果沒有清楚的定義模組與時間,外包的時程會越來越長,成本越加越多,最後失敗的時候還會宣稱不應該找外包來做。實際上應該是在當時沒辦法好好控制以及定義工作。參見這裡

(3) 彈性

外包可以產生組織彈性。只要不是外包的工作,就表示某個夥伴要做。而一個工作要需要進行,則大家的時間彈性就變小。例如,根據marketing的需要,一個新創公司可能得花時間維護blog文章,以及關心回應潛在客戶需求,這時候應該利用具有專業技能的Virtual Assistant,而不是讓少數夥伴花很多時間在一個一個的客戶回應上。



沈思:

1. 為什麼台灣新創公司好像很少聽過大幅利用外包資源,但是國外公司倒是很常見?溝通語言(英文)是不是一個顯著的問題?

2. 什麼是Virtual Assistant?它能幫助我們什麼?參考這篇blog