顯示具有 快速學習 標籤的文章。 顯示所有文章
顯示具有 快速學習 標籤的文章。 顯示所有文章

8/26/2019

系統化思考的秘訣 (軟體主管的31堂課)


系統化思考 Systems Thinking 是解決複雜困難問題的科學方式。而作為主管的工作,時常遇到困難的狀況,如果身為主管的你沒有一個科學性的方式來分析與處理困難狀況,自認可以依賴直覺和經驗,那麼很有可能你依賴的是運氣而已。


案例一:有位資深的HR M,憂心忡忡的問說,過去三個月我們的資深工程師招募好像不順利,快要一百人無法通過我們的評估,Hunter看到我們這樣都不太願意再送履歷表來了。我們是不是標準太高?要不要降低標準。

案例二:某主管A被要求和直屬於CEO辦公室的專案經理D合作進行系統整合,然而專案經理D常常會有不合理的要求 ,並常在會議中酸言酸語,讓A在系統整合上花了很多人力時間,但又打不到D的要求,而D又有CEO作為後盾。


上述案例都很複雜,牽涉的範圍廣泛。為了解決複雜問題,系統化思考會牽涉到各式各樣圖形工具,例如這個,或者這個。這些圖形工具其實都是為了簡化問題。系統化思考的理論與應用廣泛,但是針對軟體主管的工作特性,有幾個祕訣(捷徑)可以先試看看

(1) 無論如何,先畫張心智圖或者魚骨圖


心智圖可以拓展思考,魚骨圖可以先探索遺漏因素。更重要的是,圖形可以將你的思考模式放在紙面上,讓你用鳥勘的方向,有機會重新思考問題。並且,這圖型還可以留供未來檢討使用。

(2) 無論如何,先透過5Why找到真正的目的或原因。


以上述案例一,當我們先從一個方向使用5why探究原因,可能如下:

為什麼HR會覺得不順利?是因為招募人數不足。為什麼招募人數不足?是因為hunter不願意積極尋訪多送履歷表。為什麼hunter不積極?是因為我們篩選比較嚴格。為什麼篩選比較嚴格?是因為....

但是,從另一個方向使用5why可能如下:

為什麼HR會覺得不順利?是因為面試的多但都沒錄取。為什麼面試多但都沒錄取?是因為hunter送來的履歷不符合我們徵才的要件。為什麼不符合?是因為hunter不了解我們要什麼樣的人才。為什麼不了解?是因為....

找到事情的真正源頭,或者自己想達成的真正目的會是系統化思考要達成的第一個目標。

(3) 實驗性質的行動!兵聞拙速 未睹巧之久也


任何形式的研究調查,都可以無限期地進行下去,可能永遠都不會有結果。然而作為主管,透過行為有效的將事情推進下去才是重點。

案例二:當展開5why與心智圖,了解CEO的辦公室經理D其壓力來自CEO對他有時間限制時,而D由於無真正的技術能力,導致會將各種事情盡量轉交給主管A,探究其目的在於,萬一整合失敗,不會被歸咎責任。而A的做法就是互相對抗,兵來將擋。這樣的情況,可以持續下去永遠沒有結果。而後改變的做法是,先實驗性透過提供各式各樣教育課程給D的部屬,讓其部屬更了解系統如何運作,並且在各種會議中提及教育訓練一事,讓CEO理解其直屬的團隊的能力不足,因而會讓系統整合的設計本身交由A來進行,自然系統整合的最後結果就會順利達到CEO要求,也讓A與D之間的關係不會永遠惡化。

案例二看似政治問題,但其實透過實驗性質的活動(提供教育訓練)可以讓A快速證實D的團隊能力不足,即便教育順練活動辦得很粗糙簡陋也可以。


提醒一下,無法進行系統化思考的主管,最後更容易透過「恐懼」「運氣」「政治手段」等方式來管理團隊,至於能否達到目的就很難說。








2/08/2019

如何在工作中成長


過去招募時,常聽到軟體工程師的離職原因,是因為在公司已經沒發展空間,無法成長。在某些情況下的確有可能,但更多情況下是工程師限制了自己成長,並非公司已經沒有成長空間。

每個人所謂的成長有很多種類,有些人追求的是技術的成長,有些人則是職位的成長,當然每個人多少都會追求薪資的成長。無論如何,環境確實是職涯成長的重要因素,只是工作環境的選擇,通常只決定了個人成長的一部分,而非全部!

如何在工作中成長有幾個要點:

(1) 培養成長心態


成長心態與固定心態在過去幾年中常被討論,無論是ted還是書籍皆如此。

簡單的說,擁有成長心態的人會視問題與困難為自己的挑戰,知道克服了挑戰之後,自己會成功並且有所成長。並且,擁有成長心態的人,會審慎看到自己以及環境的問題,不會一昧地把問題歸咎於外在因素。並且,擁有成長心態的人比較容易知道努力不見得會成功,但是不努力鐵定不行。

關於成長心態還有很多常見故事,請自行上網搜尋。但在此舉個反面的例子:完全不具備成長心態的人,會將自己的問題歸咎於環境問題,直接的表現在職場上就容易極短時間換了許多工作,詢問過去做得不好的事情時常歸咎於環境等等。


(2) 建立能和現在環境結合的學習清單


只要是正常合理的公司,通常都有值得學習的地方。有時候,光是公司仍然還能賺錢這點,就已經值得學習。

然而,軟體工程師的天性就是學習「新事物」。對於已經熟練的技術和事物,久了總是會覺得厭倦。厭倦倒是無所謂,重點是厭倦之後怎麼辦?成熟的軟體工程師通常會了解,真實的環境需要的是「能正確無誤並且低成本有效率的工具與環境」,而非需要「最近好像很熱門的嶄新技術」

成熟的軟體工程師能找到環境與自己的平衡,如果要學習新事物,就應該建立學習的方向,最簡單的方式不外乎就是建立學習清單。

技術上的學習清單容易取得,但是,能和個人現在身處的環境結合就需要認真的想一下。

(3) 主動執行

執行自己的計畫聽起來容易做起來難。大部分的情況下,軟體工程師(特別是處於大公司中)都會認為自己在為別人工作。

事實上,至少在台灣就業市場上的勞工都是在「為別人工作的情況下為了自己而工作」。因為現行的台灣就業市場,已經非常接近自由透明的市場,只要「有能力」通常都可以有非常大的選擇。

執行各種學習計畫的要點在於「這是為自己而做」而非為了別人。



一個考慮離開目前環境的軟體工程師,通常會將「能在工作中成長列為尋找新公司的重要條件」。但其實更重要的是要讓自己有能力「無論在任何環境中成長」是為更重要要做的事情。





10/28/2018

企業巫醫:手寫的工作筆記,讓你跨越困難



筆記本加上一支筆,大概是最便宜,最容易改善工作的工具。

網路上有非常多「如何做筆記」的相關文章,特別是如何做學習筆記(例如這裡,這裡,這裡)。在職場上,特別是知識工作者,幾乎都有做記錄的必要,然而由於資訊工具的改良,許多人會改用手機,平板,電腦來做筆記。畢竟數位化還是資訊快速膨脹的主流。

在此並非建議走回頭路。數位化記錄,絕對是必要而且有幫助。企業裡面的知識庫,wiki以及追蹤工作工具(jira, redmine, trello等等),絕對是讓組織整體提高做事的透明度,持續傳遞經驗知識的最好方式。

然而,對於個人職涯發展而言,還是建議要透過工作筆記,來提升職涯發展,增加自己的能力與視野的人,最好還是擁有一套自己手寫記錄的方式。

原因如下:


(1) 手寫的學習效果遠遠超過打字


有太多太多研究顯示,手寫的理解與記憶效果,遠遠超過打字。請參考:這篇這篇這篇這篇。或許有人會說,工作筆記又不是學校筆記,但如果深究這些研究會發現,其實概念相當一致,也就說,手寫某件事情,會增強對這件事情的「理解力」,「創造力」與「想像力」,然而打字卻不會!而廣泛知識類型的工作也是,職場上對事情的理解和掌握越高,越有想像空間,當然工作本身做得越好。


(2) 成本低

當然,現在平板也可以手寫,所以廣義地說,如果習慣的話,平板也是可以。然而,再貴的筆記本,其運用成本,仍然比平板低。除了價格之外,運用成本包含環境限制(例如要充電)。


(3) 手寫讓思考聚焦


無論是用哪種輸入法,即便是最簡單的注音,只要一段時間,每個人的打字數度都會遠超過手寫速度。然而,正因為如此,手寫可以讓頭腦有思考聚焦的功能。腦中會自己思索,應該聚焦的關鍵,進而思考關鍵的意義,這對掌握工作的要點,並且讓一個人在繁忙工作中,找出一條正確的道路有絕大的幫助。請參考這篇


那麼,要如何做工作筆記?


(1) 立刻買一本


假設你沒有筆記本,也沒有做工作筆記的習慣,那麼就「現在馬上去買一本」。習慣的建立是需要時間。不建議去買很貴的Moleskine筆記本,即使是代購團購的Moleskine也是頗貴。當然它的質感,可長期保存,書寫良好,硬殼和收納設計都首屈一指。不過其實隨便到文具店買不到一百元的即可。



(2) 上班中隨身攜帶,隨時紀錄



聽起來簡單,但要養成比帶手機更隨身的攜帶是有點難。無論是開會,還是座位自己位子上,確保重要的事情,都應該即時簡單的紀錄。筆記本應該是隨著時間紀錄。而且,並不限制記錄內容。如果是開會,建議使用心智圖的方式記錄。
提醒一下,筆記本並不僅止手寫手畫,也可以將重要的檔案email,直接列印貼在筆記本上。未來當重新檢視工作時,有莫大的幫助。

紀錄的內容以「事實」為優先,同時當然要記錄時間。工作記錄並非你自己的日記。雖然,這是自己私人的紀錄,但最好不要紀錄感想或情緒;而是確切記錄事實,因果,困難,解決方案,效果等等。

除了記錄之外,筆記可涵蓋「簡單計畫」,也就是「本來打算如何做」。例如,在工作中發現你對某技術不了解,於是你就在筆記本中草草紀錄一行「學習某技術」。隨即在這行字下面,就可以做得簡單的計畫,例如:1. 10分鐘上網查詢。 2.問一下某某同事。 3.在本週末練習此技術。

當你有任何打算做的事情,拆解成為執行的行動,簡單紀錄,日後就很快可以檢查這些行動是否完成,或者計畫是否要改變。

要注意!工作筆記是幫助你「動起來」的最好方式!


(3) 每月摘要,自我檢討


工作筆記,最最最重要的功能就是,每個月找個20分鐘的時間,將過去一個月自己做的筆記認真看過。然而透過紀錄,回答自己以下問題:(a) 這個月我有做幫助公司組織哪些重要事情 (b) 這些事情做完了沒 (c)隨便換個人也能做這些事嗎? (d) 過去一個月我有沒有學到新事物(e) 有沒有遺漏重要的事情還沒進行。將這些問題,自我回答到筆記本中。
這種檢討方式,特別適合在坐捷運的時候進行。


筆記本加上一支筆,大概是最便宜,最容易改善工作的工具。如果你認為自己的職涯發展受到侷限,或者遇到困難,而你又沒有做筆記的習慣的話,那麼其實不妨一試,只要長期累積必有成效。





10/14/2018

企業巫醫:20分鐘搞定「工作做不完」的問題?



上班族常會遇到的老問題是:「工作做不完怎麼辦」

工作做不完是個老問題,解決問題的方法也很簡單,然而簡單事情不見得容易做。更重要的事情是:你需要正確的檢視現況,才能真正解決問題。因為每個人的「工作做不完」的實際情況都不同。舉例來說,假設你是在無良的黑心老闆血汗工廠,那麼你的工作做不完的解決方式應該是儘早辭職,而非增加效率。

以下步驟確保可以幫助你解決這個問題:


步驟一:暫停!休息5分鐘! 利用15分鐘進行計畫



1. 休息5分鐘


除非你的工作是急診室或者核電廠這類人命關天的地方,一般的上班族,一旦遇到工作做不完,慌慌亂亂急急忙忙的時候,其實第一件事情應該先放空自己。找個安靜的地方(萬一真找不到可以藉故離開辦公室幾分鐘),先盡量將自己的思緒清空,沒辦法放空冥想的話,打個手遊也可以。當你的思緒紊亂,壓力暴增,往往會使用直覺處理事情,使用直覺處理並沒有錯,但如果「只靠」直覺處理,就會失去成長和學習的機會,更糟的是,直覺處理事情通常和情緒結合在一起,關於這點請參考腦的結構杏仁核

所以讓自己休息五分鐘!


2. 計畫15分鐘


休息之後,拿出紙筆,先對現況做計畫。
列出事情的四個象限:重要/緊急矩陣(參考這裡) 。
如果你已經熟知這個事物分類方式,那就可以直接挑過這段,並思考自己為什麼不做這件事?

 2.1 重要且緊急:

 就是要專注處理的部份

 2.2 不重要但是緊急:

 要犧牲,或者交給別人,或者是忙碌狀況。但通常這種事情都是工作做不完的主要來源。最好的方式是縮小事情的影響。常見不重要但緊急的事情,不外乎老闆索取各種資料,感覺很急,

 2.3 不重要且不緊急:
  千萬不要去做它!普通上班族通常不小心會落入去做不重要且不緊急的事情,而且還不自知。最常遇到的事情是:對小事情花時間做無謂的討論。

 2.4 重要但是不緊急:

  千萬不要忽略他!忽略這裡,就無法徹底解決工作做不完的問題!



步驟二:按照計劃:逐一解決重要緊急的事


在計畫中,條列的重要與緊急的事情,要「逐一」處理。先不要想要同時處理,做個清單,搞定一個事情打個勾。

這聽起來簡單做起來很難。

有幾個簡單的執行要點可供參考:

(a) 自己找到專注工作的場地。很多工作其實不限定工作場合,只要你事先跟老闆講好,其實是可以嘗試找不會被打擾的地方好好專心把事情搞定。例如,在主管同意之下,中午三小時在公司附近某咖啡廳寫程式。在近年來開放式空間流行的狀況下,這點相對重要!

(b) 不要隨時檢查email與短訊。除非你的工作是急診室醫生或者某些人命關天的意外處理者,否則不應該時時檢查聯絡工具,你應該是控制工具的人,而非被工具控制的人

(c) 設定解決的定義。緊急而重要的事情的「回應」不代表解決。解決事情要像是恐怖片裡的殭屍,當你沒有徹底將它打爆頭,它很有可能會再爬起來咬你一口。


步驟三:重新檢討計畫,找到提高效率的方式,專注於重要但不緊急的事情規劃和執行


為什麼要專注於重要但不緊急的事?因為重要的事情如果都先處理好,可以大幅改善「未來還會有工作做不完的問題」 而且同時減少重要且緊急的事情發生。畢竟很多重要緊急的事情,就是當初重要但不緊急的事情一路拖延導致後來變緊急。

因此,這步驟用以確保可以有計劃地執行「重要但不緊急」

有幾個方式可以確保自己不遺漏「重要但不緊急」的事情

(a) 隨時檢查中期目標:組織通常有偉大的長期目標(例如登陸火星),但也由於通常太偉大,所以必須要逐步以中期目標達成。個人應該將中期(3~18個月)目標當作為重要的事情,而非最近短期目標。因為,短期事物常常會被迫打斷修改,就會容易淪落於被時間追趕而非控制時間。

(b) 每天排定固定時間處理「重要但不緊急」 即便是1小時,長期下來也會有效果。萬一不得已要加班,應該要加班處理的並非緊急的事,而是重要的事!

(c) 其他 (有空再說明此處)




步驟四:按照計劃,完成重要的事 ,並執行提高效率的方式


倘若已經執行到此。就可以考慮提高效率的方式。
其中最重要的方式就是「提高本身知識與能力」

提高工作效率有很多種方式,請參考這裡,或者這裡


步驟五:檢討成效,修改計畫


每個計畫都應該確實被檢討,自我檢討當然很好,不過,秘訣是請你認為做得比你更好的人幫你檢討計畫。

倘若這篇文章有某件100%保證有用的方式,那麼「請一個你認為比你厲害的人幫你檢討你的計畫和成效」是最最有用的一點。

1/04/2018

企業巫醫:市場領導者的鐵律 .(書摘)

Discipline of Market Leaders 市場領導者的鐵律。

不確定是否有中文翻譯書籍。

書中描述,要成為優良企業組織,必須將以下三件事,做到某種可接受的程度,並且必須要在其中一件事情變成市場的領導指。

(1) Operational Excellence 作業最佳化
(2) Product Leadership 優質產品
(3) Customer Intimacy 客戶關係


(1) Operational Excellence 作業最佳化

產出高效率,低價格,容易購買的流程與產品支援。盡其所能降低成本,盡量標準化,簡化各種控制,加上有精確的中央控制,與能做到整合性高速的管理系統,減低浪費。範例企業是Walmart和Dell。

(2) Product Leadership 優質產品領導

產出最好的產品或服務,專注於產品創新,產品開發,探索新市場的可能性。並盡可能追求未來的創新,領導未來的可能性。範例企業是Apple。

(3) Customer Intimacy 客戶關係

著重客戶關係管理,將執行面交由最靠近客戶的員工,縮短對客戶服務的距離,幾乎永遠以客為尊,願意在一般的產品或服務上,對個別客戶進行客製化最佳化,客戶滿意是最大的核心價值,影響所有流程。範例企業是Ritz Carlton(飯店集團),IBM。


其他參考:富比世

12/24/2017

沒有QA?如何確保軟體開發品質



任何軟體專案或產品,達到高品質是開發團隊必然的目標。不過高品質並非垂手可得,它需要團隊的共識和努力才能達成。

確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中,在程式設計師確定code complete之後,靠QA/QT/QC(註1)來執行測試,並且在測試週期中,驗證是否符合設計規格,並記錄追蹤問題(bug),有時候甚且扮演催促修復的角色。因而,特別是大型團隊,專門「處理」品質的QA角色十分重要。很多時候,團隊可能面臨沒有QA的狀態,此時要如何確保品質呢?

為什麼會沒有QA


有時候,環境造就沒有QA的局面。例如,新創公司可能也只有5個人,無法有專責QA。又例如,大型企業中因資源分配不均,導致某些專案無法有專責QA。

但更多時候,沒有QA指的是,沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上,在軟體開發團隊中,實際做的事情其實比職稱來的重要。就品質的角度而言,QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說,在kick-off時,QA應該花最多時間在定義DOD,決定產出的評斷標準,在sprint每天活動中,QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出,主動改善現有品質。換言之,QA應該比單純的程式設計師,更會程式,更知道系統的交互作用細節,並能透過直接或間接修改程式,直接影響開發過程中的品質。因為,開發前中期的品質修正,效果好,成本低,遠比開發「後期」再來幾個測試循環來的有效!

簡要的說,能真正做QA工作的人,必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。

如果團隊不巧沒有這樣的人,有三種方式可以在沒有QA的情況下確保軟體開發的品質:

方式一:Scrum

Scrum方法論中,概念上每個Scrum成員都是「同樣質量」。換言之,Scrum進行中重視的是產出,每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項,應該將品質涵蓋入內,而由自行取得該任務的人,完成其保證。

有許多作法和上面這段熬口的說明有關。首先,DOD (definition of done) 除了涵蓋unit-test之外,其實應該也涵蓋整合測試。如果不涵蓋整合測試,就應該另外有一個任務是專做測試。並且,每個story完成中,必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試,可以單獨成為一個工作,也可以作為DOD的一部分。

無論如何,基本概念是:「人人應該都可以生產程式碼,當然人人應該都可以測試」。實際執行時,或許有些人比較常「拿到」測試工作,但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作,但並不代表這些人不負責品質。

Scrum的團隊重視每個Sprint的共同結果,此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長,太長就會落入「團隊中自行區分QA和Engineer」的後果。


方式二:Pair Programming


Pair Programming是指兩個人一起用一台電腦,一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇,不過能有決心推動的團隊並不常見。

由於Pair Programming讓每段程式碼至少都會被兩個人看過,而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字),也可以避免懶人錯誤(程式風格,漏寫unit-test),然而,更重要的是它讓兩個程式設計師的真實想法,在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。

Pair Programming似乎有效率和產能上的疑慮,但無論如何,它確實是在沒有QA的情況下,確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。



注意!

前兩個方式雖然符合敏捷開發的精神,並且能從系統結構層面,解決問題。然而,這兩種方式都必須要有結構性的改變,除非是剛剛成立的新團隊,要造成結構性的改變很困難,而且,即便做的好,也得花上其他心血才能有「能見度」,有能見度,才有所謂的功勞。

有兩個古時候的例子:

(a) 鶡冠子扁鵲:扁鵲曰「長兄最善,中兄次之,扁鵲最為下。」魏文侯曰:「可得聞邪?」扁鵲曰:「長兄於病視神,未有形而除之,故名不出於家。中兄治病,其在毫毛,故名不出於閭。若扁鵲者,鑱血脈,投毒藥,副肌膚,閒而名出聞於諸侯。」

(b) 孫子兵法:故善戰者之勝也,無智名,無勇功,故其戰勝不忒。

然而,對於一個軟體專案的主管而言,這些結構性的改變才是自己真正的價值。即便價值很難被衡量,但價值會永遠存在自己的手上。

如果短時間難以改變環境,可以考慮以下的方法三:

方式三:Part-time & Automation


工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題,但就確保軟體開發品質而言,把他們當做「一件事情」來處理,會有驚人的效果。

簡單的說,就是雇用3至4個優秀的工讀生,每週上班2-3天,組成工讀生團隊,執行測試任務,並且在熟練測試任務之後,開始進行測試自動化撰寫,並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情,但執行起來,遠比方法一二簡單。



其步驟如下:

(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師,讓他作為工讀生團隊小組長

(b) 到各大學相關科系徵求大四以上的長期工讀生,一般來說,只要能妥善說明對他們未來就業的好處,通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。

(c) 組成團隊後,第一個月僅只需要熟悉目前軟體系統,第二個月才開始讓他們執行測試計畫,回報並記錄問題

(d) 在此過程中,由小組長指定測試內容和範圍,換言之,這段期間,其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而,程式的品質仍然是所有成員負責,工讀生不在Scrum的範圍內,因此不「負擔責任」。

(e) 當測試進行2個以上SPRINT,工讀生應該已經開始覺得測試是很煩人的事情,但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此,就可以開始由小組長領導工讀生進行測試自動化。

(f) 測試自動化並不期望把所有整合測試/回歸測試,100%統統自動化。只要把「簡單瑣碎」的測試自動化,通常就能節省一半以上的時間

(g) 通常六個月後,3-4人的工讀生團隊就能完成部分整合測試,和大部分的回歸測試。而下一輪的新工讀生,可以選擇從頭開始打造新的測試自動化,也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具,新的角度來測試既存系統,可以讓品質在一次提高。接手前期工讀生的自動化,可以讓自動化範圍更廣,空出時間來做其他的事情


工讀生進行自動化測試的開發,對組織,對小組長,對工讀生有三贏的效果。(參考:實習生的三贏)

組織:讓沒有QA的團隊,能確保高品質的產出。除了要花些微的工讀費用之外,讓團隊成員能把瑣碎的事情下放給優秀的工讀生,使團隊成員能集中心力,但又同時負責個人生產的品質。同時,由於利用工讀生來培養小組長,讓組織能了解這個資深工程師,適不適合作為領導者,萬一不適合,頂多也是犧牲工讀生而已。

小組長:沒有人生下來就會當主管,當主管必須要有經驗,而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊,練習各種管理技能。

工讀生:大部分優秀的大四以上學生,都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern,然而其實短短兩個月,通常會做比較獨立的專案,雖然都很有趣,但是和在學校有很大的不同。加入實際開發團隊,即便只是做測試,也能了解「現實和學校」的差距,並且體會到軟體專案開發時,品質的重要性。讓有此六個月經驗的工讀生,更容易在未來找到更好的工作。





註1:關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分,請參見wiki。然而,誠如前所述,工作角色名字不重要,做出事情才重要。

11/16/2017

軟體專案管理 - 版本控制系統內的程式碼基本分析


孫子兵法:夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!

任何軟體開發專案的基礎都是「程式碼」。即使,專案經理不需要親身撰寫程式碼,但是必然要能夠透過程式碼,取得專案關鍵資訊,作為專案領導管理的最佳參考。(關於專案進度,請參見這篇。)

版本控制系統(git, cvs, p4, svn等等),則是有效控制程式碼的基礎,開發過程大部分的事情會發生在這裡,也應該發生在這裡。

如果你的軟體開發專案,沒有使用版本控制系統!!??...呃....請參考註1。

版本控制系統「至少」可以提供以下這些重要而且基本的訊息給專案管理者:

(1) 截至目前為止,有多少人實質參與專案
(2) 截至目前為止,專案的實質規模(程式碼檔案數量 行數等等)
(3) 一段時間內,此專案程式碼品質的推測
(4) 一段時間內,例如過去48小時,軟體團隊的實質產出
(5) 一段時間內,例如過去7天,有沒有人在非上班時間內工作


專案管理者(或者Scrum Master)應該自己取得這些訊息。為什麼??



"Доверяй, но проверяй
 - 俄羅斯名言,意思是 Trust, but verify  

冷戰期間美國總統雷根特別愛用此名言,根據wiki說明,雷根是受到一個作家的影響






因為,過去專案管理者常見兩種極端:

(1) 極端放任自由:在Scrum的精神下,雖然每天站立會議和燃燼圖,都可以揭露專案最確切的進展,完全相信成員的口頭回報
(2) 極端間接的繁複審閱:在沒有技術背景的情況下,透過頻繁而起瑣碎的會議,加上各式各樣文件追蹤,試圖了解目前進展。

這兩者都有明顯的問題,Trust, but verify才是正確做法。以Scrum的精神取得每日進展,並且,專案管理者應該「自己」想辦法檢查。專案管理者,如果沒辦法自己檢查,表示對此專案的本職學能不足。(註2)


專案管理者能夠做的程式碼基本分析有很多。好的專案管理者,至少需要能自己「動手」,利用工具或者程式,透過事實,了解下面三件事情:

(a) 基本專案狀態分析:哪些人寫了哪些程式碼
(b) 哪些程式碼檔案很重要:某些程式碼就是常有問題
(c) 哪些人需要額外關注:某些人工作壓力大常加班

以下以git為例,其他版本控制系統也能做到類似的事情。


基本專案狀態分析


靜態程式碼分析工具有很多。例如,gitinspector可以揭露整個專案的大致情況。gitinspector的安裝使用請參考這裡
以github上的serverless.com為例,在github上clone這個專案,並且執行#gitinspector的結果如下:


首先會大致列出作者和過去的產出摘要,例如Aaron在這個專案一共commit了8次,包含170行程式碼跟刪除87行。這個表當然不能作為績效考核用途,但是可作為參與度的重要參考。很明顯的Austen鐵定比Chris的參與度高很多。




接下來隨即會列出還存在的程式碼行數。以Austen來說,他還有2713行的程式碼存在。和他的總新增行數與刪除行數有很大的差別。這很有可能是他參與了開發初期,而開發後期的版本沒參與。




哪些程式可能容易有問題?

程式設計師每天辛勤的工作,自然會知道哪些程式常出問題。而專案管理者必須要由技術面來獲取正確的資訊。版本控制系統會記錄每次程式修改的原因(如果commit的備註正確的話)。最簡單列出「要注意的哪些程式碼檔案」

git log指令,可以加上 --grep=<string> 來濾出字串,以下例子只用fix當作過濾條件,並且配合linux其他指令:sort, uniq 就做出簡單的報表:


~/serverless# git --no-pager log --name-only \
--grep=fix  --pretty="%s" | sort | uniq -c | sort -n
     19 lib/ServerlessState.js
     19 tests/tests/actions/ResourcesDeploy.js
     20 lib/ServerlessProject.js
     23 lib/actions/EndpointDeploy.js
     23 lib/actions/ProjectInit.js
     23 lib/actions/RegionCreate.js
     23 lib/SerializerFileSystem.js
     24 lib/Serverless.js
     25 lib/actions/ResourcesDeploy.js
     25 lib/actions/StageCreate.js
     25 tests/test_utils.js
     27 package.json
     27 README.md
     28 lib/actions/FunctionRun.js
     34 lib/actions/FunctionDeploy.js
     38 lib/actions/FunctionCreate.js
     55 lib/utils/index.js
    101 tests/all.js

當然,以上報表只是列出有fix字串的commit中,哪些檔案出現次數最多。 tests/all.js 明顯是最多的,但也很明顯這檔案本來就是會被一直修改。此外,README.md也是一樣,大概也不是真正有問題。不過其餘的檔案倒是可以額外關注一下。

程式有問題的的判斷方式有很多,除了在commit的紀錄中說明是[fix]或[bug fix]之類。但也可以考慮總行數,刪除的行數,增加的行數,並且配合QA/bug tracking系統,才較為完整。


哪些人需要額外關注?


「人的問題」,永遠是最難解決的問題。然而,卻也是要優先解決的問題。組織中必然有需要「被關心」的人。

專案組織中,最要被關心的人是「表現好且有潛在壓力大」,以及「表現不好且對團隊有負面影響」這兩種。其中,表現好的人更是要優先處理。

除了每天例行工作接觸之外,專案管理者應該要有確切的「數字」。假設,我們想知道在此專案中,哪些人常常「晚上」工作。最簡單的方式是分兩步驟,先用git列出作者時間,然在寫個簡單的統計程式,列出所有人的「晚上」工作時間和「平常」工作時間次數。

* 步驟一:先取得所有的branch, 然後, 以下git log指令可以列出作者和時間,並且輸出到檔案author_time_log

 

# for BRANCH in $(git branch -a | grep remotes | grep -v HEAD | grep -v master); do git checkout --track "${BRANCH}"; done
# git --no-pager log --all --pretty="%an,%ai" > author_time_log


檔案內容大概如下
....
Austen Collins,2015-08-05 18:28:18 -0700
Austen Collins,2015-08-05 17:26:26 -0700
ryanp,2015-08-05 17:04:37 -0500
Derek van Vliet,2015-08-05 09:31:56 -0400
Michael Friis,2015-08-04 18:54:03 -0700
Austen Collins,2015-08-04 15:04:46 -0700
Colin Ramsay,2015-08-04 22:03:48 +0100
Chas Warner,2015-08-04 14:53:59 -0600
Austen Collins,2015-08-04 11:19:31 -0700
Austen Collins,2015-08-04 11:15:44 -0700
Austen Collins,2015-08-04 11:11:06 -0700
Austen Collins,2015-08-04 11:09:24 -0700
....


* 步驟二:撰寫簡單的分析程式,設定正常時間是早上7點到晚上8點,其餘都算不正常時間。用人名為單位加總之後,就可以產出簡單的報表。簡單的統計程式原始碼請參考這裡

此表中,Eslam幾乎有一半的commit都是在晚上產生,而Kamil則是標準完全正常時間工作。

Joe Turgeon [1, 0]
Erik Erikson [15, 7]
Ian Serlin [1, 0]
David Hérault [1, 0]
Peyton Zhou [2, 0]
Kazato Sugimoto [2, 0]
Nick den Engelsman [1, 0]
Kiryl Yermakou [0, 1]
Austen Collins [575, 267]
Kamil Burzynski [101, 0]
Frank Schmid [9, 2]
Jacob Evans [13, 1]
Michael McManus [1, 0]
Eslam A. Hefnawy [158, 132]
Dave Newman [0, 1]
Ryan S. Brown [35, 6]
doapp-ryanp [129, 48]
Michael Friis [1, 0]
Matthew Chase Whittemore [2, 0]


當然這並不代表Eslam的表現好而且壓力大,這只是提供給管理者參考的事實。專案管理者,必須要事實層面,檢查軟體專案的狀況,因為很多時候「會吵的小孩有糖吃」,只單純被煩就會給糖的專案主管,其實對團隊是沒有價值的。


小心統計陷阱

統計數字都可能會有陷阱,程式碼的基本分析也是統計的一種,自然要小心陷阱的存在。專案管理者應該要善用統計數字,切勿被統計數字所左右。請參考統計與謠言


 


註1:軟體開發專案不使用版本控制系統,會讓專案本身暴露在極端的風險中。如果你是專案管理者,讓專案暴露在風險中就是你的責任。如果你只是個開發人員,儘早離開高風險的環境才是上策。

註2:某種情況是,專案規模過於龐大,例如參與開發者超過100人,某些技術確實不見得能完全掌握,但專案管理者,仍然要保有部分自行檢查的能力。




10/17/2017

工作中速度與效率的迷思




孫子兵法:兵聞拙速 未睹巧之久也

媒體大亨Rupert Murdoch:不是大的打敗小的,而是快的打敗慢的


效率以及速度,在職場上的重要性應該眾所皆知。然而,速度並不見得會產生「效率」,當然也就可能沒有「績效產出」。

工作中的速度與效率常見有幾種迷思如下:


速度的相對論


在職場上,速度時常是相對的。

有個笑話最適合描述這樣的相對論:兩個好朋友去非洲野營,在帳篷睡到半夜,聽到有獅子在附近低鳴,似乎打算把這兩人當作食物。其中一人開始穿衣服鞋子,另一人惶恐地問「我們有辦法跑得比獅子快嗎」,已經穿完鞋子正在做熱身操的那位仁兄回答:「我不需要跑得比獅子快,我只要跑得比你快就好」

然而,相對論的確有其迷思與限制。例如,在大型企業中,或許你已經是個主管,相對於其他同事,你也有創意,而且你辦事速度也很都快,看似一切穩當。但是有一天,你所屬的部門被公司老闆出售給外國企業,而該企業也表明只需要技術人才,不需要主管階級時,你才發現原來速度的比較對象,不應該僅僅是在自己的組織之中。(沒錯,這裡說的是HTC最近的賣部門給google的事情)


過程與結果的本末倒置


速度應該是「過程」,而效率和產出,才是「結果」。

把速度當作結果等於是本末倒置。

所以,讓網頁的使用者回應時間,從2.5秒,加速到0.25秒,看似一個有指標性質的結果。但已產出的觀點來看,其實可能是要達到「服務更多使用者」「增加效率」或甚至「減少電費」這些確切結果的「過程」。

工作中單以「速度」作為結果的績效指標,很快就會導致局部最佳化的組織問題。


沒有目標的ASAP


當詢問同事/主管說「請問這件事情應該何時完成」,如果時常聽到ASAP-as soon as possible 越快越好,而沒有具體的解釋,其實是危險的指標。

沒有具體衡量的速度,可能導致幾種錯誤想法:

(1) 這是不計一切代價要越快完成越好的事情,即便犧牲性命也在所不遲,因為一旦完成就會有很美好的事情發生。這樣的想法過於革命性的危險,事實上,僅有極端少的事情是不計一切代價,連生命都可以不要的。

(2) 每個人的時間感受不同。也許CEO的告訴中間主管的ASAP,在當時他的心中是指3個月,而中間主管告訴工程師的ASAP,在他當時的心中是指3個禮拜,可是,工程師的感受可能是5天。最糟的情況是,工程師會誤以為ASAP表示可以犧牲品質,如同上段所述,是可以不計一切代價達到速度。

(3) 有太多事項都是ASAP時,表示根本沒有設定正確的目標以及優先順序。




附註,關於速度突破職場困境,請參考這篇

8/19/2017

如何成為Scrum專家 - 極簡計畫書



Scrum是推進團隊進度,合作專案的敏捷方法論之一。在過去幾年來從資訊產業,金融業,甚至學校教育,都有不少人在倡導這個簡單而且踏實的方式。因為Scrum有很多優勢,例如減低壓力,具有務實的彈性,容易評估現況,易於控制品質。這些優勢,可以用在大部分的企業環境中。因此,成為Scrum專家對職業生涯很有幫助。

學習Scrum並不困難,在各企業巫醫的網路資料中,早就擁有看不完的資料。請參考這篇

對職業生涯有幫助的不僅是「學會什麼是Scrum」,更重要是成為Scrum專家。或者,至少成為在他人眼中的Scrum專家。專家的定義,請參考註1。

或許你在職場有2-4年的工作經驗,作為一個團隊成員,在專案領導人的帶領下,參與以Scrum為基礎的專案。然而,這不會讓你變成Scrum的專家,因為你只是「照著做」而已。

在此提供一個極簡計畫,可以在很短的時間內讓自己變成Scrum專家。

如果懶得看說明的長篇大論,可直接在此索取「如何成為Scrum專家 - 極簡計畫書


開始之前的條件


這份一頁極簡計畫書有使用上的條件:

(a) 必須要有還不錯的英文閱讀能力,TOEIC750以上。如果你的英文能力自認不夠,請參考這裡

(b) 必須要有2-3年以上的實務工作經驗。而且在工作環境中,至少聽過Agile/Scrum。

(c) 必須打從心裡認為有效使用Scrum是有好處的。換言之,不能是因為「有人叫我要學Scrum」而學Scrum。因為,此極簡計畫書本身執行的方式也是Scrum!


如何成為Scrum專家極簡計畫書的使用步驟如下:

(1) 確認目標的實質意義


此極簡計畫是要在2個月內,讓執行計畫的你變成「Scrum專家」。而何謂Scrum專家的實質意義就是在此極簡計畫中三個sprint的「實質產出」。

Sprint-1 知識:讀完2本Scrum書籍,以及2份網路資料

Sprint-2 證照:取得Scrum證照

Sprint-3 研討會:舉辦公司組織內Scrum研討會或分享會

這三個實質產出的組合意義,目的就會讓你成為Scrum專家。即便不是Scrum大師,至少也是被大部分人承認的專業人士。

這三個Sprint各有已經設定好的任務(Task),所有任務完成後,就表示該Sprint完成了。而每個任務本身的描述都是有簡單清晰的「完成條件」definition of done。

對這個產出有疑惑,非常歡迎與我們聯繫


(2) 分配每個Sprint的時間


計畫書中,每個Sprint各有數個任務,每個任務都有估計的時間。時間是以小時為單位。加總起來,會有要完成Sprint所需要的總時數。

一般軟體專案Scrum估計都可能會有錯,在Sprint過程中,要能實際反映團隊實際的「速率」,因此前1-3個Sprint的燃盡圖很重要,可以讓團隊知道實際的效率。所以每個Sprint都是固定時間,大約4-6週,sprint時間到就結束了,只會看做完哪些Story,在下一個Sprint才調整要完成的story數量。

然而,個人Scrum做法會略有不同。整體概念仍然一樣,但因為Product Owner也是「你自己」,因此Sprint時間可以變動。換言之,可能第一個Sprint是4週,第二個Sprint是5週。

請在極簡計畫書中,每個Sprint任務表格上方,填寫預計的Sprint開始的日期,和結束的日期。Scrum是要反應實際狀況,因此,也許整個sprint需要5小時,但因為你有本來的工作要做,因此可能要花2個月才能有5小時的空閒。

(3) 每日工作


當有超過30分鐘空閒的時候,就可以把那張極簡計畫書拿出來,在這個Sprint選一個任務(Task)開始「執行」,或者,繼續上次未完成的任務。這些Task都是大約設計成30-40分鐘完成,但是根據Scrum的精神,每個人的績效不同,因此也有可能會花的時間多或者少,但無論如何,在還沒完成已經做一半的任務之前,不要換任務!

當然,如果該日沒空,自然就不需要拿出極簡計劃書來執行。

每個任務,都有完成條件,確定滿足完成條件後就可以塗黑空格,並且在右邊簡單的紀錄所花費時間,和大約日期。時間不用太精確,以半小時為單位即可。有些任務很簡單短暫,也許10分鐘就完成,但也以半小時紀錄就好。

如果沒辦法在0.5小時內完成一個任務,那要請自己休息一下,再決定要繼續完成該任務,也可以決定今天就先到此為止。

不能有某任務做到一半,就「先拿了」下一個任務,也不能有這個Sprint還沒完成,就先開始做下個Sprint的某個任務。當然Sprint中的任務,有些是沒有前後關聯,因此Sprint中的任務不需要按順序。只是,一旦開始做,就一定要做完為止。

某些任務需要下載檔案,請參考註2的各個下載網址,可以一次下載完成。

在計畫書中的任務描述都很簡單清楚,但如果真有問題,也歡迎來信詢問:support@talent-service.com




(3) Sprint 結束自我檢討和下個Sprint的開始


完成Sprint中所有任務之後,表示這個Sprint完成。要花15分鐘時間,先自我檢討一下Sprint過程中有哪些阻礙,而自己應該怎麼改善阻礙。

接下來就要開始下一個Sprint。實際上,本來Sprint的開始是需要先討論Story和Task的選擇。然而,極簡計畫書希望你不要花時間在研究這些Task重不重要,而是先努力的花時間搞定它。畢竟這些任務所需要的時間都不多,實務上也對你有莫大的幫助。

不過,或許有些任務你早就已經完成,那就可以看一下完成的條件(DoD),已經達到就可以自動塗黑。


(4) 計畫書完成?專案結束了嗎?


三個Sprint完成之後,這個極簡計畫書就達到它的功能。但就個人專案的角度來說,專案不見得要結束。只是這時候你已經有足夠的能力和經驗,可以決定要不要繼續以Scrum的方式來學習Scrum。

(5) 3個Sprint結束後的彩蛋!


很簡單,當你完成這個極簡計畫書,實質上你自己完成了一個Personal Scrum。

彩蛋要靠自己完成。請在計畫書背面以三個Sprint的各任務所花的時間,「手工」繪製燃盡圖。

這件事的意義在於,你有確切證據證明你能有效運用Scrum在非工作事項上。也證明你有自我學習的能力。它可以用在未來履歷表,面試,或者說服同事Scrum不如想像中困難,只需要一點點毅力去執行。


在此索取「如何成為Scrum專家 - 極簡計畫書



常見問題:


Q1:這個極簡計畫書,很多地方跟我在工作上用的Scrum都不一樣啊?

Ans:當然不一樣,因為他屬於Personal Scrum。但是它的最基本精神是一樣的。請參考這裡,了解Scrum哪些最基本精神比較重要。

Q2:我不就是自己的Product Owner?為什麼我一定要用這三個產出來達到「變成Scrum專家」。

Ans:你當然可以自我決定產出和任務,也有機會變成Scrum專家。極簡計畫書,是在如果你還沒有好的定義時,可以透過過去人的經驗,減少時間浪費,讓你專注在精進自己。

Q3:為什麼要取得Scrum認證,這樣就會變成專家嗎?

Ans:有些人可能會以「取得相關證照」,作為專家的標準。這的確是個參考標準,但也只是參考而已,因為Scrum並沒有所謂官方證照,所以市面上各種證照到底哪一個比較適合?請參考這篇「Scrum認證!不要再浪費錢了」。在此採用的是Scrum-Institute的低成本證照




註1:即職場上的專門行業,指具備專業化知識技能職業人士。通常,專業技能須符合科學原理,經過長時間的學習訓練,並有經專業認證的考試獲得的合格證書執照,擁有自我約束行為的職業操守(或道德)及可量化的專業標準等。...定義細節請參考這裡


註2:各種需要下載的資料

(a) 任務 1.4 的2個pdf教材
https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

(b) 任務1.7的wiki頁
* https://zh.wikipedia.org/wiki/Scrum

(c) 任務2.1的pdf
* http://www.scrum-institute.org/Scrum_Books_International_Scrum_Institute.php

(d) 任務3.1與任務3.3的材料


* http://www.eduscrum.com/


https://www.crisp.se/gratis-material-och-guider/scrum-checklist


8/12/2017

急速發案 代工製作Line貼圖上架


在近幾年,在台灣各大網站部落格,有教製作LINE貼圖的文章可以說不計其數。

許多文章都宣稱,只要你會用小畫家隨便畫一下(註1),就可以做LINE貼圖。而且,也許你的創意,會比很多藝術家都還賺錢也說不定喔?

坦白說,如果不是有藝術創作背景的人,即便有好的構想,也很難從自己的手上實踐。

除非「找人幫忙實踐想法」。

花錢請人實作自己的想法,並非罕見的事情。大學時代訂製團體服,做自己品牌的餅乾,訂做自己品牌文具,訂做自己品牌面膜...甚至,如果錢夠多,可以OEM出自己品牌筆記型電腦。

LINE貼圖也是。而且,LINE貼圖是個最容易做到「利用跨國專案,取得最低成本但又是可接受的品質的產品」

以LINE基本8張貼圖而言。只要知道怎麼發案外包,應該可以在25美金之內(約750台幣)取得還不錯的品質。依循下列快速步驟,應該可以在3天之內讓送出LINE貼圖上架申請(註2)

快速步驟如下:

(1) 準備需求描述構想

所謂發案委外,當然是自己的構想,請他人實踐。

所以如果你需求描述是「I need 8 images which can make money for me on LINE Store」。那可以肯定的是,這案子鐵定失敗。

你的構想必須要簡簡單單,清清楚楚地表達。例子如下:

(a) 8 PNG images, all in the same size: 320x320 100dpi, transparent background, RGB
(b) the same character: a cat, full body, very cute, always sleepy and lazy, female cat, American shorthair cat.
(c) 8 images means 8 different emotion of the cat: happy, sleeping, feel great, angry, boring, exciting, play cute, hungry 
(d) should be easily accepted by children between 8-12 years old
(e) must fit standard: https://creator.line.me/en/guideline/sticker/

其中LINE貼圖規格必須簡單的說明在第一項。
而最後一項必須放LINE規格書

(2) 瞭解LINE 貼圖規格

作為業主,必須至少要了解LINE貼圖規格:https://creator.line.me/en/guideline/sticker/
雖然LINE規格也放在需求描述中,但是自己至少也要看一下吧。


(3) 將構想發佈在跨國委外網站

跨國委外網站有很多fiverr, upwork, freelancers, guru都是好選擇。

不建議使用 台灣委外。因為所有委外OEM首要應該考慮「比較利益法則」,因此,藝術類型的工作,恐怕是找國民所得較低的地方(例如南亞)比較適合。這也是為什麼,跨國委外網站,在簡單的專案上,多半都是印度人居多。

在此以Fiverr為例。


在註冊fiverr之後,右上角的Buying功能中,按選Post a Request。

這就表示想公開一個案子,讓所有fiverr上的承包商自由工作者都可以看到。

在Describe the service...文字框中,貼上在(1)準備好的需求描述構想。

並且在Choose a category選單中,選擇Graphic & Design。並且在Subcategory中,選擇Cartoons & Caricatures。

在選擇完成的天數,建議選3天或7天。

最後,也是最重要的「錢」。

預計花多少經費?在大部分的外包網站中,這裡的錢是參考金額。接下來想要參與專案的人,可能會提出「稍低」或者「稍高」的價錢。不過,不可能會有人提出比你要求的金額高很多或者低很多的價錢。

以LINE的貼圖來說,8張圖如果是同一個角色的不同變化,那麼在fiverr上30美金是很合理的價格 - 如果你沒有特別的想法,那麼就填30美金。(註3:關於一分錢一分貨)


(4) 決定發包給誰


發包之後,通常過幾個小時,就會起碼7個人以上來投標。如果願意等一天,隨便都會超過12組人馬。大概超過10組投標者,就已經足夠讓你煩惱到底要給誰。

29個投標願意製作8張LINE貼圖的其中兩名


選擇投標者,有很多方式。最基本的方式,是利用平台上的傳訊息功能,和投標者詢問一下是否了解規格,可否先簡單畫一下草稿讓自己參考一下。(註4:語言能力)

但就30美金的這種小案子,其實也不用想太多。畢竟你最多也是損失30美金(900台幣)而已。不過,透過選擇投標者,增加自己判斷國外專業人士的能力,其實是更有收穫的事情。

判斷的方式可以參考這篇文章-> 選擇跨國委外廠商的務實流程


(5) 等候結果

當你按下「Order」按鈕,決定給誰做了之後,接下來似乎也只能等了。

不過,倘若你的專案是7天完成,最好是在第3天以及第5天,先問一下是否有完成了幾張圖可以讓你確認一下「樣式風格」是不是符合期待。這樣做有些原因:

(a) 確定這個人不是在第六天才開始工作。因為許多能力好的南亞工作者,會身兼數職,當他得標之後,就會「安心的去做別的事情」,直到最後關頭在來趕製這個30美金小案子。但其實只要事先提醒,大部分的自由工作者,都願意早點有進度與業主溝通。

(b) 確定做的品質不會差太遠。預計要做8張圖,每張也僅只320x320大小,所以第一張如果符合預期,大概後面幾張也沒問題。然而,如果第一張和你心裡的差距很大,早點溝通也比較好。

(c) 讓得標者知道有人在等。當他知道作品是被期待的時候,通常會比不被期待來的好。



(6) LINE上架申請


做好貼圖要上架也非常簡單


(a) 事先申請paypal和玉山銀行整合的美金與日圓帳戶。


先申請paypal帳戶。然後再到玉山銀行申請與paypal整合的玉山全球通,完成之後,再到paypal的網頁設定和玉山銀行的整合。

這三步驟,在網路上有很多詳細步驟教學文,但是太多教學文都已經「資訊過期」。最好的詳細步驟,當然是看該網頁的說明,逐一按照說明完成即可。

請參考玉山銀行此網頁。某些台灣製作LINE貼圖的廠商宣稱這很麻煩。其實一點都不麻煩,準備好個人身分證件,本人必須要到玉山銀行,很快就搞定了。


(b) 註冊creator帳號


到這裡https://creator.line.me/zh-hant/ 逐一填完所需要資料即可註冊。


(c) 在creator中上傳圖片,送出申請


到creator個人網頁:https://creator.line.me/的右上角,按選My Page/個人頁面。
進入個人頁之後,左上角有個新增項目,按選之後,按照說明,填寫需要資料上傳圖片即可。


(7) 等候審核結果

現在LINE審核貼圖的速度越來越快,大概等候2周就有結果,如果因為各種原因被拒絕也不用太傷心,再花一點錢,請原本的承包者按照line的指示修改即可。


參考


關於跨國委外專案,可參考其他文章:
* 選擇跨國委外廠商的務實流程
* 創業者善用虛擬助理
* 如何組成團隊
* 發展手機APP事業三步驟




註1:Microsoft已經要移除小畫家了:~,請參考這裡

註2:LINE貼圖送出申請後,到上架還需要一段不短時間。去年的網路資訊都認為需要3個月以上,但今年(2017)已經縮短到只需要2週。

註3:一分錢一分貨的道理自古不變。不過CP值的道理也是,而CP值在網路造成資訊快速全球化的情況下,對於數位產品而言有很大的「空間」。講的更值白的是,同樣30美金,在台灣日本韓國,可能只能要求一個剛畢業的藝術科系學生,勉勉強強花2小時做一些差強人意的圖示。而30美金,卻可以讓一個有5年工作經驗的印度視覺工程師,花8個小時認真做完。因為,一個能力好而且高薪的印度數位視覺設計工程師,年所得約6千美金,已經屬於印度高收入群, 但其實也等於台灣月薪15K而已。就CP值而言,是非常划算。

註4:這時候,你需要有比較好的英文溝通能力。


7/31/2017

快速且極低成本之AWS臉孔比對 - 利用AWS Lambda




AWS在2016年底釋出的圖片辨識服務(Rekognition)其實是非常非常昂貴。除了前5000次影像辨識不收費之外,接下來每一千次影像處理會收1美金。

乍看之下不多,但實務上,公開使用的影像辨識,通常無意中就暴增。


以之前LINE聊天機器人影像辨識為例,由於會當辨識到女性的照片時,會特別額外辨識內建的臉孔比對(40個亞洲女星照片)。等於是每收到一個女性照片,會進行42次臉孔辨識:40次照片比對+1次特徵比對+一次名人資料庫比對。就LINE聊天機器人數百的好友而言,該功能開放不到7天,就已經超過四萬次比對,換算價格約35美金。

35美金其實足以開啟維持t2.medium (EC2 VM)一整個月。這個VM甚至還有4G的記憶體。這樣的VM絕對能支撐每秒2-5次的臉孔比對,換言之,一整個月可以比對超過7百萬次。而這7百萬次也才略高於35美金。

然而,不應該因為成本的增加,就直接使用EC2 VM。而是應該考慮在符合serverless的架構下,如何解決這個問題。畢竟,當使用了VM,未來在擴增(scale-out)上也會有些麻煩。其實,我們目的很簡單清楚:只是要比對兩張臉孔的相似度。因此,應該使用輕量化Lambda即可。


原本做法

當使用者透過LINE上傳照片給聊天機器人之後,後端系統會執行下列事情:

(1) 先利用AWS Rekognition (detect)查詢基本臉孔資料,例如性別,年紀等等。

(2) 假如判斷是女性,就到AWS S3上選取所有要比對的臉孔,進行比對分析。在這裡,如果有40張臉孔,表示每一次上傳圖片,都要在這個階段額外送出40次分析。即便AWS允許先行儲存圖片特徵,但在比對階段仍然是看次數。

參考程式節錄如下:

    
    rclient = boto3.client('rekognition')
    s3 = boto3.resource('s3')
    bucket = s3.Bucket('sandyifamousface')

    for o in bucket.objects.all():

        #print(o.key)
        response = rclient.compare_faces(
            SourceImage={
                'Bytes': byteArray
        },
            TargetImage={
        
                'S3Object': {
                'Bucket': 'sandyifamousface',
                'Name': o.key,
            }
        },
            SimilarityThreshold = 60
        )
        if len(response['FaceMatches'] ) > 0:
            # DO things if match..



(3) 最後把判斷之後的結果,送回給LINE


改良做法

先將40張圖做臉孔分析,並且把特徵值Landmarks挑出來,儲存在檔案中。未來數量大的話當然可以存在dynamodb。

在這個範例是儲存於json文字檔中。

(1) 與上一段相同

(2) 在Lambda被載入 時,就先讀取文字檔,成為python的dictionary。原本要利用Rekognition做比對,改為使用自己寫的比對函數。在範例中,這個函數是利用landmark的相對距離變化,來判對臉孔相似與否。當然這樣的比對其實很粗糙,而且也沒有考慮臉孔的前側傾角度。不過,和aws本身所附帶的臉孔比對的結果其實已經很接近。

參考程式節錄如下:
def compareLandMark(landmarkList1, landmarkList2):
    distList = []
    compareList = [
                   ('eyeRight','nose') ,
                   ('eyeLeft','nose'),
                   ('mouthLeft','nose'),
                   ('mouthRight','nose'),
                   ('mouthUp','mouthDown'),
                   ('mouthLeft','mouthDown'),
                   ('mouthRight','mouthDown'),
                   ('noseRight','eyeRight'),
                   ('leftPupil','rightPupil'),
                   ('nose','rightPupil'),
                   ('leftPupil','nose'),
                   ('noseRight','noseLeft'),
                   ('eyeRight','eyeLeft') ,
                   ('mouthRight','mouthLeft') ,
                   ('mouthRight','eyeRight') ,
                   ('mouthLeft','eyeRight') ,
                   ('mouthRight','eyeLeft') ,
                  ]

    for (m1,m2) in compareList:
        d1 = getDistanceFromType(landmarkList1, m1, m2)
        d2 = getDistanceFromType(landmarkList2, m1, m2)
        distance = (abs(d1-d2)/d1)
        distList.append(distance)


    lenD = len(distList)
    mD = statistics.mean(distList)
    # stdev and variance could be used in the future.
    mStd = statistics.stdev(distList)
    mV = statistics.variance(distList)
    conf = (1-mD)**2
    return conf*100




(3) 最後把判斷之後的結果,送回給LINE

結果:

在Lambda自行撰寫比對程式,但是其實是利用AWS Rekognition 所給出的landmark (特徵),會讓比對變得簡單而且成本很低。

缺點是,這樣的比對準確度和如何計算特徵有很大的關係。



* 關於LINE聊天機器人,請參考這篇
* 專案程式碼放在這裡
* google的vision api其實價格更貴,請參考這裡




7/26/2017

聊天機器人 - 快速製作在LINE上的人臉辨識應用

名人以及圖片分析 在和LINE聊天機器人之對話中


 聊天機器人(chatbot)作為人機介面,提供人類各種整合性服務是最容易產生的應用。而人臉辨識,一直都是人工智慧與數據分析的整合課題。因此,把LINE聊天機器人加上照片或人臉辨識的功能,似乎也很有趣。
用LINE QR 加小姍為好友 可以測試人臉辨識

以前,在做關於影像的實驗性質的程式時,通常會先考慮opencv。雖然opencv確實是個好工具,但是如果你的目標不是改善演算法,或甚至做出更先進的人臉辨識方式,那麼opencv會過於複雜。

在2016年底,AWS發表另一個雲端服務:Rekognition。這個服務提供了API用以辨識影像,並順便提供了幾個在應用上的api:「比較人臉」「辨別名人」「識別限制級圖案」。(文件請參考這裡)

這些api要運用的最簡單方式之一,就是使用AWS Lambda來驅動AWS內自己的API,再透過API Gateway跟外界 - 也就是chatbot整合。換言之,這仍然符合公有雲廠商(無論是AWS, google還是azure)的所謂serverless的未來方向。雖然這些公有雲廠商,其實只是為了讓客戶更難離開公有雲環境,但不可否認的是,這些api的確有用而且在初期成本也不高。

快速製作在LINE上的人臉辨識,需要幾個步驟:


(1) 對serverless的設計概念有些瞭解


請參考這裡這裡


(2) 對Line聊天機器人申請和製作,以及對AWS Lambda先有基本的瞭解。


可參考這裡這裡


(3) 在LINE webhook的event中處理image id。


在webhook的lambda程式中,特別挑出image的id。LINE的訊息傳遞給chatbot時,有分不同的type,要處理的是image type。LINE並不會真的傳圖片檔案到webhook中,他傳遞的是圖片id,透過這個id,可以用一個URL拿到圖片:


https://api.line.me/v2/bot/message/<id>/content

要取得這個圖片,當然要有Line token


(4) 讀取圖片URL並且以取得bytes


以python為例,首先以requests讀取URL,記得stream必須設為True,因為接下來需要將資料(影像的byte)直接讀取成bytearray。參考程式如下


    imageUrl = 'https://api.line.me/v2/bot/message/{}/content'.format(imageId)
    r = requests.get(imageUrl, headers=headers, stream=True)
    bArray = None
    with r.raw as data:
        f = data.read()

        bArray = bytearray(f)


(5) 使用各種AWS的Rekognition服務。

取得bytearray之後,剩下的事情就很簡單了。
以python為例,可以使用boto3 (最好是1.4.4版本)。先取得rekognition的client物件,直接使用裡面的方法(例如以下範例)。將Image參數都設定成{ 'Bytes': your_byte_array} 就可以取得分析的結果。


    rclient = boto3.client('rekognition')
    response = rclient.recognize_celebrities(
        Image = { 'Bytes':bArray }
    )

要注意的是,分析結果response是一個含有各種標籤與技術數值(例如信心程度)的dictionary物件,所有的標籤都還是英文,必須得自己轉換成中文才行。

範例中的「名人辨識」(celebrities)所查到的名字都是英文。可以利用wiki 英文api搜尋這個英文字,找到對應的中文網頁,在取得中文字。

wiki的英文api可參考這裡

(6) 存取S3之考量


如果看過AWS document應該會發現,使用recognize都可以設定image來源是S3。那麼範例為何不存取S3? 

事實上,的確可以將LINE的影像,先存在S3,然後再進行分析。然而,這樣會多了「存入」S3和取出S3的時間。並且,S3也是要收費的!影像如果只「分析一次」,那麼存在S3其實很不划算,存在Rekognition裡面更是貴。如果會反覆利用,那麼恐怕還是得存在S3中。



目前結果分享


用LINE將小姍加入好友,就可以試用一下目前LINE與AWS人臉辨識整合。


加小姍為好友 ID-> @opn2514f

加小姍為好友 Add Friend


下圖是辨識川普不同的表情,會被辨識出不同的年紀,和不同的心情。




4/20/2017

數據分析 - 獵人頭如何從Github尋找人才?


前陣子遇到某特殊的獵人頭hunter公司(參考:這裡),竟然是透過分析統計在github, gitbucket的程式庫,來找到軟體人才。

目前,github使用者數量仍屬商業機密,但估計約在2千萬左右(參考:這裡)。當然,使用者大部分從事軟體相關的行業。

資訊科技,特別是軟體的實際成果,容易在網路上展示。因此,如果要找到「軟體開發人才」,github是一個很好切入的地方。一般獵人頭可能會人工搜尋,但身為工程師,當然是寫程式找到大量資料。

從github找人,這做法有一些顯而意見的好處:

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點:

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力,非技術能力仍然需要其他佐證
4. 資料範圍過大,很難逐一肉眼看完

雖然我不是獵人頭,但基於工程師的精神,就嘗試一下解決「資料範圍過大,很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料,找到潛在挖角對象清單。

實際上做的步驟如下:

1. 了解gitbub資料如何取得:


github提供api可供程式使用。和許多Web Service一樣,也有完整的文件,請參考這裡


2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說,如果你已經登入github,用以下這個URL request就可以找到,以javascript與nodejs為關鍵字的所有程式庫:

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然,他的回應是json格式,需要簡單地用程式轉換。例如下圖,乃是搜尋和javascript相關,並且其位置在台灣的使用者:



測試資料回傳乃是json,調整格式成為csv,以便於日後在excel做簡單分析。


3. 了解測試資料內容


如果已經有在使用github,那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github,就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例:「搜尋和javascript相關,並且其位置在台灣的使用者」來說,程式會刻意收集following(有多少人在跟隨這個人的更新),follower(這個人跟隨了多少其他人)。此外,程式會額外計算push和javascript相關的程式庫的次數,取名為work,表示和javascript的相關工作在過去一段時間的次數。


4. 撰寫簡單統計程式,大量取得資料


當然,這個程式就放在github上。請參考這裡

程式本身是python撰寫,需要有github帳號密碼才能使用。


5. 結果


以上述範例:「搜尋和javascript相關,並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆,給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。