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

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專家。

如果懶得看說明的長篇大論,可直接到這個網頁下載計畫書


開始之前的條件


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

(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的各個下載網址,可以一次下載完成。

在計畫書中的任務描述都很簡單清楚,但如果真有問題,也歡迎來信詢問




(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不如想像中困難,只需要一點點毅力去執行。


在此下載計畫書



常見問題:


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


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 (獵人頭) 鑑定看看是否有效果。

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

9/25/2016

企業巫醫 - 時間乃最終之敵人? (上)




在每年不可計數的企業管理勵志書籍中,有越來越多把「時間」視為判斷事務的重要標準。想當然,個人「時間管理」變成一種必要的技能。然而,更近一步是在越短的時間,達到越驚人的效果,從早期的「24小時學會某東西」系列,到「7分鐘運動燃脂72小時」,都是試圖在短的時間內達到CP(註1)值最好的結果。


時間似乎是最終的敵人?


也許,在某些時候,「搶先一步」是競爭的最佳方式。不是大的打敗小的,而是快的打敗慢的(註2):就變成企業主事者認定的最好成功方式。畢竟,如果可以用很少的投資(小),只要用比較少的時間(快),好像就可以打敗大但是慢的競爭對手?聽起來永遠不吃虧阿!再者,兵法有云:故兵聞拙速,未賭巧之久也。似乎,只要速度夠快,總比慢來的好?

更近一步的說,許多人逐漸視時間為最終測量維度。例如Compete Against Time,就將時間視為在商業上,衡量事務的最重要方式(註3)。甚至有人認為應該是唯一的度量方式

就經濟學始祖亞當斯密1776年的說法,企業組織價值的來源主要由三種事情組成:資本,土地,勞力。土地:泛指一切自然資源,勞力:泛指人類的智慧和努力。任何商品的價值,都是由這三者的其中一種,兩種,或者三種組合起來。

時間快轉到2016,隨著全球化經濟發展,資本以及自然資源,對於企業的影響已經遠遠不如「勞力」,更確切的說,是人的努力強化資本和自然資源的運用。即便現在存在著比1776工業革命初期更自動化的設備,更能節省人付出肌肉的努力,但面對更趨複雜的環境,人類的「智慧腦力」似乎需要付出的更多,某些人需要付出更多的腦力,讓其他人少動點腦?而最終,變成某些人在相較短的時間,付出較多的腦力,產生較好的結果,可以大幅讓商品的價值領先市場的其他人。


總之,各種訊息「似乎」都顯示,即便時間不是最終的敵人,也是先要處理的「衡量指標」


以廣大勞工而言,衡量生存的指標,就從古時候的「每天能耕多少田」,轉為「每天能在工廠做多久」,而再變成「每天在電腦前面完成多少工作」。只要能在越短的時間完成越高品質的工作,就會越有機會加薪升遷。


然而,事實上只有極端少數的人,能夠妥善駕馭自己的時間,也因此,「時間」變成企業巫醫用來恐嚇部落子民的惡靈之一。


巫醫有三種方式來處理「時間惡靈」

一:加速 - 跑的比它快


各種企業巫醫的,也在強化此信念,教導讀者「加速」用來增加巫醫的崇拜。

例如,最有生產力的一年超強時間術早上三小時完成一天的工作時間整理術... 請隨意搜尋類似標題,一定可以找到超過100種以上的方式,書籍,甚至mobile app。

這些加速的書籍,有些的確是有用的個人經驗,就像南美巫醫累積了數世代的經驗,分辨有效的草藥一樣的有些用途。然而,通常僅能適用於巫醫自己。關於「加速時間」,就像投籃命中率一樣,可以學習,可以練習,但是因為環境的因素,每個人終究有其極限。

事實上,「加速」全然是靠自己的經驗和能力,就像大部分的感冒是靠自己的抵抗力痊癒一樣。採用巫醫的建議手法,確實有幫助,只要自己意識到這樣樣的手法是在幫助自己的經驗與能力即可。過度崇拜「方式與手法」,會容易走火入魔。(參考:2013年的9個todo app)。



二:有效利用 - 80/20法則的極端利用


光是加速,能取得的效果總是有限。頂多取得20%-30%的進步就很了不起。唯有改變方式,甚至改變目的,才有可能取得3倍或者10倍的改變。

從「加速」改為「有效利用」,就成為在2008金融危機之後的顯學。

例如:為什麼菁英都是清單控Scrum一半的時間做兩倍的事少但是更好其實工作不必這麼累 ... 一樣有成千上百的書都屬於此累。

這類型的「找重要的事情做就好」的書,其實真只有這個重點,那就是掌握80/20法則,先做重要的事情,你的職業生涯就是彩色的。

但是,企業巫醫沒辦法告訴你,在你身上哪個20%是最重要要做的事情。誠實的巫醫永遠只能說「施主,這要問你自己阿」。而拐彎抹角的巫醫會用「斷捨離」,「時間矩陣四象限」,「人生優先清單」等等技術性的手法,告訴你,你還是得自己找到那重要的20%。


三:心靈層面 - 永遠都有的一招


幾乎所有的企業巫醫都會的一招:將所有的事情,推移給心靈與精神層面。

例如:心靈慢活療癒慢活從容的力量慢一點成功又何妨被討厭的勇氣...

就心靈層面觀點而言,這些巫醫也許可以帶來平靜,而平靜讓人的思慮或許可以更周延,並降低更多的壓力。但是,這些巫醫雖然好意的想要讓世界變得更美好,但是絕大部分的人類是社會性動物,試圖全然擺脫外在的影響,等於是要人類放棄天性。當企業組織內變得越來越快速,光是一個人在裡面「慢活」是難上加難。




那結論呢?


請參考下篇:企業巫醫 - 時間乃最終之敵人? (下) 。




註1:CP值,或者性價比,請參考這裡

註2:這句話很多人都講過,包含郭台銘和柯文哲。不過,這個名言最早應該媒體大亨:梅鐸所說。另外,這句話在2002年也是某本書的名字。

註3:將時間視為第四個空間維度來描述,請參考狹義相對論

註4:增加工作效率?聽起來和前述的巫醫有什麼不同?就想要達到的效果來說,有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理,經過有效驗證,而且可以在未來檢討改善。