11/18/2016

簡易學習式人工智慧 - line聊天機器人


自2022年有chatgpt之後,原本的ilne聊天機器人已經停止使用。新的聊天機器人使用chatgpt, 想要試用的,可以email聯絡:consultant.3rd@gmail.com

製作Line聊天機器人並不困難,困難的地方在於讓它有些許智慧。三個月之前,透過AWS上的lambda以及其他AWS相關服務,製作具有某種「泛用型」智慧的聊天機器人,並透過line或者facebook來作為其介面。(參考此篇)。


近年來人工智慧的發展迅速,然而在特定領域(例如下棋)的發展速度,遠比「通用型」機器來的快。然而,通用型聊天機器人卻是在未來能夠真正取代人類(統治人類?)的關鍵。


額外的小功能(2017/8註記):

在2017上半年,人工智慧已經多加一些功能,這些功能,都是根據對話內容來啟動的。人類會跟機器人聊什麼?參考這裡。

舉例來說:

* 對小姍說「請幫我到廟裡抽籤」就會幫你抽籤解簽。

* 對小姍說「請幫我算命 生日是19981102」 就會幫你排1998年11月2日出生的命盤

* 對小姍說「幫我算今天星座運勢 雙子座」就幫你查今天的雙子座的運藝

* 對小姍說「請推薦豐原美食」或者「請推薦基隆美食」小姍就會幫你上網查最新的地區美食文。


* 上傳照片給小姍,小姍會特別到名人資料庫裡搜尋,並且比對美女資料。(由於使用人數超過預期,小姍反應時間過慢,只好暫時停用相片分析功能)

除了智慧之外,一般應用也可以透過聊天機器人介面完成。例如,上傳圖片影像之後的分析。(參考這篇)

當時,她的智慧實在不怎麼高。因為泛用型的語意分析十分困難,「專用型」相較之下會簡單很多。
雖然她會紀錄過去的對話,並在透過其他的知識庫來學習對話,但就使用者來說比較慢察覺她的進步。又由於line在最近停止了trail bot,使用line bot就必須要透過line@ (channel)以及已經變成v2的message api。因此,順便將「立刻學習」機制加入這個聊天機器人中。

簡易學習機制,讓聊天幫手變得容易製作: 
(1)聊天機器人的整體設計概念 
(2) 聊天機器人製作過程

如何教導「人工智慧小姍」一些知識?


(2017/8註記:由於太多人教小姍奇怪的知識,不得不先取消教導小姍知識的功能)

首先,當然你需要加小姍成為你的line好友。 Add Friend

接下來,可以隨意跟她聊天。如果想要她馬上學會某些對話。可以在句子的開頭用關鍵語  590590 加上 「聽到的話」 和「應該回應的話」 然後送出訊息小姍就會學習。
舉例來說:

590590  如何學習  首先學無止盡 不能有休息的時候

小姍看到590590就知道是要學習的東西。而她會把第一個詞「如何學習」當作關鍵字,第二個詞到最後,當作可以回答的範圍。當然 590590 和第一個詞中間要有個空白,而第一個詞跟之後所有的詞中間也要有空白。

也可以參考下圖:




加小姍為好友 ID-> @opn2514f

加小姍為好友 Add Friend


11/16/2016

Scrum - 務實的彈性,千萬不要削足適履 (下)



夫所以養而害所養,譬猶削足而適履,殺頭而便冠 ......除小害而致大賊,欲小快而害大利

--- 淮南子說林訓



誠如上篇,雖然說Scrum的方式與工具十分簡單,能務實並且彈性運用比照著字面嚴守方式來的重要。 

「形式主義者」嚴格遵守字面的意義,而非真實的意義,已經是很嚴重的錯誤。

但更糟糕的是「極端基本教義派」將學習到的Scrum技巧,視為不可侵犯的條款,凡是侵犯了條款視為大逆不道,非除之不可。 

Scrum是專案任務執行的技術與方法,它符合agile的精神 (註1),並且延伸出一套可供參考的作法。這套執行的技術概念中,定義了角色,專案進行的基本流程,進度控制方式。

 而最最最重要的Scrum重點(註2)應該是: 

1. 一段時間之後(sprint)會交付可被驗證,可使用的產品 。

2. 每段時間的產出,都是市場在當時最最最需要的 。

3. 這段時間之後,整個流程會被檢討改進。

無法掌握到以上最基本的三點,任何字面上的意義都沒有用。而Scrum基本流程都是為了掌控以上三點。 做的到這三點,就可以進一步掌握更重要的要素。有個清單可供參考。

極端基本教義的錯誤有很多種。

然而有錯誤並不可怕,可怕的地方在於極端基本教義派難以自省問題,因為他們的存在目的在於「迫使」其他人跟隨絕對不會錯的自己。 

Scrum終究仍是管理類型的技術,因此不會工程或科學一樣有細節標準可循。光是Scrum證照在市面上就有N種,更何況是各種細微技巧。 

極端基本教義派常會其中的技巧視為必須,反而遺忘真正的重點。 

更慘的是,極端基本教義會將補習班的奇淫巧技,是為基本重點,舉例如下: 


例一:堅持每天舉行「站立會議」,而且會議中唯一堅持的事情就是大家要「站著」。 


會議內容倒是五花八門,從討論問題,到穿插最近公司要大家額外參加的同樂活動都有。Scrum的每日會議僅只講三件事:「上次會議到現在做完了哪些task」「到下次會議之前打算做完哪些task」「目前遇到什麼重大問題」! 


例二:估計時程的撲克牌,堅持使用點數來估計task。但從來也不檢討時程為何不準確。 


不可否認Scrum撲克牌是有用也有趣的觀念。但是,它並不是唯一最好的估算時程方式。

事實上,只要是軟體團隊,經歷過2-3個sprint的團隊,在第3到4個sprint開始之後,直接以時間來估計時程更容易更確實!

因為絕大部分軟體的困難度是時間與執行問題,在撲克牌估計點數中都有個假設是:難度可能和時間無關,但就軟體開發而言,幾乎不可能! 

再者,Scrum撲克牌根本也不是Scrum獨有的,大約在2005年之前就已經有人提出類似的方式(註3)。當時需要以點數(point)而非確切的時間來估計時程,一部分的原因是:估計時程的人根本不是「做事情的那個人」! 

由於搞出以點數估計task難度,在以團隊速度推算時間這種以繁馭簡的人,在當時,他是為了是搞出另一套可以拿PMP的PDU/SDU課程讓大家來學習,並不是因為他有專案實例在此!因此,就目的而言,其實也不太能讓人苟同。 

撲克牌工具仍然是好工具,非線性的點數分配仍然是好觀念。

但如何操作還是要看團隊在每個sprint結束檢討而定。 


例三:因為各種原因,沒有先執行最重要的事情 


所謂最重要的事情,就是最重要的事情。如果他是最重要的功能就應該先行完成。如果他不是,就不要現在去做。 

基本教義派最常以「這個sprint是4週,如果先做P2,下個sprint做P1就會比較快,不然先做P1可能sprint沒辦法是4週」作為技術上,區別功能先後完成的依據。 

 如果Product owner也認為是如此的話,那麼只有兩種可能:(1) P2其實是最重要,P1相較之下不重要,或者差不多重要。(2) product owner無法代表市場,了解事情的重要性。或者很難了解。 這兩者其實都會發生,也都無可厚非。因為agile的精神本來就在於適應變化。

但scrum團隊絕對的基本觀念就是:如果已經很確定這件事情真的是最重要,就絕對應該先做! 

而Scrum Master除了處理團隊問題,每日站立會議之後,要問自己的就是團隊是不是正在做「最重要的事情」,這遠比趕快更新燃盡圖(burndown chart)來的重要。確保團隊隨時都在做「當時最重要的事情」是Scrum Master「隨時最重要」的任務。




註1:agile基本精神如下:

(1) Individuals and interactions over processes and tools
(2) Working software over comprehensive documentation
(3) Customer collaboration over contract negotiation
(4) Responding to change over following a plan


註2:但是這三個重點,也是補習班沒辦法直接教的


註3:http://www.informit.com/store/agile-estimating-and-planning-9780131479418

11/14/2016

因為沒挑戰想換跑道:先檢討自己吧!




新的一年,總是容易遇到討論換工作的事情。目前,台灣資訊科技領域整體仍然缺乏人才,因此要換新的工作是非常容易的事情。

真正的問題在於:什麼原因想要換工作?如何換?新工作或事業會不會比較好?自己到底想要什麼?

這些問題根深蒂固地存在每個人的身上。不會有一體通用的方式為所有人解答。

不過,如果單純只是因為現在的工作沒挑戰性,無趣而想要換跑道,還請以下三點簡單的自我審思一下。



檢討一:「沒有挑戰很無趣」的真正源頭


牌桌上的至理名言:「30分鐘後如果你還沒發現誰是冤大頭,那麼你就是冤大頭」。在企業中,如果你沒發現有任何值得挑戰的地方,那或許你自己就是沒有挑戰的真正原因。

當你的工作變得沒有挑戰,而且無趣的時候,請先確定問題的真正源頭。

是不是因為你的能力或者表現,讓你無法得到有挑戰有趣的任務?還是你的視野讓你看不出挑戰性?

還是這工作或事業的本身,真的沒挑戰性?你已經是有如NBA過去的Jordan或者現在的Curry已經快觸到這個事業和工作的極限?還是你抵達的是自我的極限?



檢討二:選項



選項,永遠是考慮決策的要件。

換工作或事業是一個好選項。但是,在既有的領域中,擴展自己的視野和能力也是一個選項。

換工作是個選項。在大企業中,換部門也是一個選項。換工作這選項中,嘗試新的技術領域是個選項,但是嘗試截然不同的工作類型(例如業務相關部門)更是更大的不同選項。

在現有工作內容中,改變自己的做法以求突破,也是一個解決的選項。

選項可能很簡單,也可能很複雜,而且還會參雜很多人的因素。去除自我偏誤,取得個人最想要的結果,比想像中的簡單。不過,要預設自己以及相關人等有完全的邏輯推理是很難的。(參考:沈思)



檢討三:「沒有挑戰很無趣」有時候是真正的挑戰


在資訊科技的領域裡,多的是把原本看起來無聊的東西,重新找到價值並且延伸的例子。

如果你可以將無聊沒挑戰性的事情,轉成有價值,並且有挑戰的事情,等於是你證實自己絕佳的創意以及實踐創意的能力。

這樣的例子在不管在哪個領域很多,從很久很久以前的gmail,到近幾年的類似snapchat的app,許多都是一開始是沒很有趣,但是找到額外的創意之後,將舊有的東西突破。

隨著組織越來越大,表面上無趣的事情會越來越多,光是默默的忍耐並不會讓事情變得更好,只有把無趣轉換成價值,才能展現自己的創意能力。要怎麼做?可以參考這篇



參考文章:換工作的面試-軟體工程師如何展現價值




沈思:
一個海盜集團中的5個海盜找到了100顆金幣,每一枚都一樣的大小和價值。 

由於海賊王想要這五個部下傷透腦筋,自相殘殺,規定他們分配金幣的方式如下: 

1。抽簽決定自己的號碼(1,2,3,4,5) 
2。首先,由1號提出分配方案,然後大家5人進行表決,當且僅當超過半數的人同意時,按照他的提案進行分配,否則將被扔入大海餵鯊魚。 
3。如果1號死後,再由2號提出分配方案,然後大家4人進行表決,當且僅當超過半數的人同意時,按照他的提案進行分配,否則將被扔入大海餵鯊魚。
 4。以此類推

 如果你是號碼1的海賊,應該怎麼分配金幣?

台灣博士生與大數據分析:如何評估對大數據分析的本職學能?



最近有個真實故事:



(為保護當事人,內容與細節均有所改變) 

台灣人F,目前就讀於某知名國立大學,已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘,用以評估他的能力。試教主題不限。

然而,F其實對大數據除了看過一些商管叢書之外,其實根本一竅不通。因此,他找了以前大學時候已經在業界工作的好友J,問了一些「技術問題」如下:

F:我聽說過spark,是不是大數據分析都用它啊?spark是不是個作業系統?

J:如果這是你的問題,那你壓根離spark太遠。後面就不要再談了。

F:哎喔,我覺得教學只是個演出啦,看表面而已。以你在業界打滾多年,就幫我個忙。couchbase是什麼?有什麼如果講出來會讓大家知道我很厲害的地方?

J:如果這真的是你的問題,你真的什麼都不懂啊,就算你去E校當教授,也是害了別人。

F:....



這個真實故事乍看之下太過駭人!但或許反映了學術與實務之間的鴻溝。

其實,台灣有許多學術界的人才,不但學術淵博,技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是,許多教授幫業界「產出」能產生價值的知識性員工,並且也讓業界的知識持續推進。

然而,M型社會反映的層面,不指是一般在職場工作的人,在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮,穿梭在三流研討會,大企業策略部門,顧問性質演講,以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情,大概也不會真正傷害到誰,只是,也不會對任何人有好處。只要不是在「自己家裡」,一般人在路上看到蟑螂只會視而不見,也不太會去追打。

但是,如果是在自己家裡呢?

評估對大數據的本職學能,才能判斷來者是學術淵博的長者,還是費力在夾縫生存的蟑螂。如果是像E校一樣,原本的教授群並沒有這方面的背景,要如何在沒有足夠的知識情況下,判斷對方有沒有知識?這雖然有點難,但是,透過一些方式還是可以把誤判機會降低。



(1) 實際經歷探詢(情境實例面試法)


情境實例面試法很基本,但是事先有所準備。做法很簡單,只詢問「過去實際上」發生的事情,用以判斷被面試者現在的情況。而且絕對不詢問開放性問題!!

對於couchbase而言,就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題,會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論,大打模糊仗來損耗面試者的判斷精力。


簡單問題像是:


* 請用1分鐘定義何謂nosql

* nosql的實作有很多,請舉一個你最熟悉的nosql平台工具,一個你實際最常用,最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了?  (用判斷他最熟悉的工具有可能有多熟,如果少於6個月大概也等於是不太熟)

* 你利用couchbase為平台,撰寫並發表過哪篇論文?(學術界而言,沒有發表相關論文等於是沒有相關方面的研究)


稍微麻煩的問題像是:


* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係,但表示其實只是單純的使用者,不會有太多深入的了解)

* 你利用couchbase為平台,撰寫並發表過哪篇論文中,所使用的研究資料量有多大?100G?10T?(資料量極小的nosql,並不代表不正確,只是代表不是大數據而已)

* 你用過哪些版本的couchbase(起碼要記得大版本編號吧)

* 你最近讀了哪一篇論文是以couchbase實作其研究?是大概什麼時候讀的,內容是什麼?


總之,事先準備好不能模稜兩可的問題,並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多,只要7-10提及可。這樣,比較不容易被蟑螂溜進來。並且,在準備的過程中,其實也會讓團隊(無論是學術還是技術團隊)對這方面的知識有基本的增長。


(2) 真實展示


簡單的說,就是請他拿一台電腦,展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼,還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是,如果事先已經提醒會有真實展示,可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘,其實是真實展示的好方法。然而,盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手,但是蟑螂恐怕也是。


(3) 自我反省

當在一個地方看到蟑螂的時候,通常表示附近還有另外10隻蟑螂(也有人說是數百隻),只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是,自己是不是其中一部分。

自我反省是極端困難的工作,對生活優越的自己,在心理上也不見得好過。但是,在陰暗狹小的地方求生存,總是比不上光明正大的貢獻自己的能力。

請謹記,「自信心」和「自我感覺良好」只有一線之隔。或許,透過實際經驗探詢,先自我檢查自己,才是去評估別人之前,真正自己應該做的事。












11/12/2016

Scrum - 專案壓力來自於無法掌握的命運



一個壓力實驗:

有兩個籠子(A,B),都連結同一個電極器,各有一隻老鼠。A籠子中,有一個燈號和按鈕,當燈號亮起時,如果在數秒內,A老鼠沒有按下按鈕,則就會產生高壓電極,讓A,B兩籠的老鼠都被電的很不舒服。不過,如果燈光亮了,在時間內A老鼠按下按鈕,則A,B兩籠就都沒事。B籠的老鼠則是全然被動的,只要A老鼠能做好他的工作,B老鼠就沒事。當然,經過幾次電極之後,A老鼠很快就學會了一旦看到燈亮,就應該儘速去按按鈕。

過一段時間之後,哪一隻老鼠的壓力大?

經過健康檢查,A老鼠幾乎看不到壓力大的特徵。而B老鼠,則出現各種癥狀:高血壓,胃潰瘍,成長障礙等等不一而足。

(以上內容取自:數位痴呆症:作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難,而是在於自己「全然」隨著命運擺佈,無法控制。以A老鼠的情況來說,他仍然是被關著,而還得三不五時瞄一下燈是不是有亮,一旦亮了就得趕快反應。

然而,「至少有一件事情」A老鼠可以控制:他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實,固定的時間,以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內,每一個角色都有「至少可以全然控制」的事情,不但可以正確減低無法掌握命運的壓力,更能組合出正確的團隊合作方式。


Product Owner(產品擁有者或產品經理)


在傳統的「瀑布開發模式」,或者,系統整合商SI的「隨意無止盡需求模式」中,產品經理會就所有應該要做的事情列一個驚人的功能清單,交由專案經理負責領導開發。接下來的18個月,產品經理就在B老鼠的壓力下度過,即便有檢查,也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理,更有可能在每一段時間,修改需求,讓開發團隊變成B老鼠,不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任,這個責任用非常簡單而清晰的方式減低他的壓力:「撰寫並排序需要完成的使用者情境」。

專案開始時,產品經理會撰寫數個使用者情境(user story)並且排定優先順序,而每個sprint開始時,團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後,檢查這些當初答應的story是否有如預期完成,並且在下個sprint開始時,或確定,或重新排列,或增加,或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成,並且確定每sprint開頭都能選他最想要的事情先做完。因此,產品經理確實能掌握這個產品每一段時間的「樣貌」,而不是在最後關頭才求神拜佛,或者要求加班。甚至,在sprint的中間階段,若有必要,產品經理可以要求sprint停止,重新開始新sprint,用來調整後來才發現不正確的優先順序(priority)


Scrum Master (開發領導者)


過去一個團隊的技術領導者,帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理(或客戶)以及開發成員中的角色。

在傳統模式下,他若非變成一個技術獨裁者,用以壓迫成員前進並反抗大幅需求改變,就是變成試圖面面俱到的好好先生,用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description),但事實上,困難的專案,不會因為一個很能講話的專案經理,就變得簡單。最後最常出現的結果是:專案經理總是能有效呈現「自己的貢獻和功能」,但無法反應在專案成功。換言之,常常看到自己從來不失敗的專案經理,曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理,其責任和角色也有很大的不同。而他能有效掌握的事情,也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」:完成了哪些事情,接下來要做什麼,有遇到什麼困難。確保每個sprint開始的會議,領導團隊能完成哪些使用者情境(user story),並且確定這幾個要完成的事情,產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情,但是透過掌握每一個sprint,腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖,Scrum Master掌握過去真實進度。因而可以有效推測未來進度,並有足夠的證據顯示給產品擁有者。因此,才能有足夠的「動作權力」成為A老鼠:仍然在籠中,但掌握部分真實權力,以減少壓力。


Member (團隊成員)


傳統模式下,團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是:「某功能我們在要X月X日之前出來!」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是,在Scrum中團隊成員,決定使用者情境:「真正完成的所需要的時間」。而這個權力,僅代表一個事實:由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做,只要決定現在在做的事情,什麼時候可以完成,以及「真的去做他」。換言之,Scrum團隊真正的A老鼠,其實只有團隊成員,只有他才會真正的按下按鈕。然而,如果Scrum團隊不能掌握分工負責的精神,團隊成員很快就變成B老鼠:不是被無謂的壓力掌握自己的命運,就是試圖跳脫牢籠。






10/20/2016

Scrum - 務實的彈性,千萬不要削足適履




夫所以養而害所養,譬猶削足而適履,殺頭而便冠 ......除小害而致大賊,欲小快而害大利

--- 淮南子說林訓


雖然說Scrum的方式與工具十分簡單,能務實並且彈性運用比照著字面嚴守方式來的重要。不過「務實彈性」和「削足適履」有時候只有一線之隔。


形式主義的削足適履


某些形式主義分子在執行Scrum上,會嚴守大部份framework的要求:每日站立會議,燃盡圖更新,user story和PM確認...等等。達成基本要素,似乎就是必要的事。

但是實際檢視其內容,偶爾會有怪異之處,而這些怪異之處,總是自然生出個理由:「因為我們team比較不一樣,所以有不同作法」。但其實以軟體開發來說,每個team統統都不一樣,而是否能有不同的做法,乃是看有沒有掌握agile的精神而定,而非把不一樣當作理由。

常見的怪異之處有:

* 每日會議除了堅持站著開之外,其他完全不堅持,會議中仍然會試著討論專案問題與技術解答。

* 在幾個sprint之後,仍然無法得知專案團隊的速度,因此仍然常有在sprint快結束時強迫加班的情況

* Scrum Master或者team leader會指定工作項目的完成時間

* 出現一些時間長達3天以上的工作項目,但卻又無法更細分階段或者細項。

* 在sprint結束的檢討會議(Retrospective Meeting)似乎都是在檢討別的單位的合作問題。


這些怪異的狀況都是削足適履的表徵。Scrum的精神在於實況並務實,因為「要Scrum」而做出怪異的行為,還不如乾脆不要使用Scrum作為開發方法論。



務實彈性的例子:以功能為sprint


sprint的基本精神在於每個sprint之後,都會產生可「交付」的結果。一般情況而言,專案的每個sprint時間長度是固定的,以符合Scrum的time-boxed精神。

但如果一個軟體產品已經是5.0版,功能趨於穩定,未來的挑戰,其實在於更快速正確的回應市場變化,則其實可以將time-boxed改為feature-boxed。




上圖取自:http://comsysto.files.wordpress.com/2010/06/scrum_cycle.png

簡單的說,每個sprint的開始,由產品擁有者(PO或PM)選定一個「最最最高優先」的user story。只能有一個,不多也不少。接下來的流程,和一般的Scrum相同,break down開發細項之後,由專案成員評估時間。

略有不同的地方在於,評估確切完成時間之後,就是這個sprint需要的時間。因此,可能是2週,也可能是4週8週。完成的定義當然是變成「可以交付的產品」。因此可能是5.0.1版。

假設sprint plan會議完成,決定是5週,之後就和一般Scrum一樣,在5週之後準時交付產品給產品擁有者。而產品擁有者應該會「立刻」將產品放到市場,看看這個「最最最高優先」項目有沒有達到預期的市場反應。下一個Sprint當然也是選擇一個「最最最高優先項目」,可能會花2週,也可能會耗時8週。

對於已經成熟軟體產品,這樣調整的最大好處是,快速取得市場反應,而非等9-12個月之後產生一個6.0的大改版。

產品擁有者(或者PM)自然會對自已的判斷有完整的責任歸屬,畢竟,如果幾個sprint都交付了產品經理認定的最最最高優先項目,而是市場反應卻不怎麼好,那麼產品擁有者當然要負起責任,花更多的精神來瞭解市場,並且將市場需求轉化為適當的user story。


每一種務實的調整,都有其優點和缺點。

「以功能為sprint」的例子中,最大的缺點在於,稍微控制不當,就會變成傳統瀑布開發模型。而時間估算稍有不當,就會容易延長專案難以收拾。因此每一次務實的彈性調整,都應該在sprint之後的檢討會議上,確實檢討改善。


參考:Scrum的缺點




10/10/2016

軟體專案的現實:解決人的問題




無論是否採用agile的開發方式,所有軟體專案,最大問題的來源都是人。

人的問題,通常會極現實的影響專案的進行。然而,妥善運用agile的精神和Scrum的方法,有機會讓人的問題降到某個程度。

某個朋友,姑且稱為K,在專案扮演專案經理的角色,遇到以下狀況:

我最近有遇到一個問題,不知道怎麼辦,下面的人一直做不到我的要求,或者動作很慢,即便壓日期給他,他還是沒辦法達到,但實際上它任務並不多,只是開test case,我不太知道怎樣push他,我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說,解決方式似乎也很簡單。首先專注於優先項目,接下來根據事實檢視工作,最後才考慮能力問題。


一:專注於優先項目


每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保,在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說,要確保團隊成員專注於目前任務上的方式很簡單:就是腳踏實地的「問」。在該成員一來辦公室的時候,就坐到他座位旁,親切的詢問他昨天早上在做哪些事情,昨天下午在做哪些,並實際上「看」到做的結果。就可以確定他是否專注,而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實,而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」,一起坐著看實際上的狀況。


二:工作檢視

以Scrum而言,每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成,沒有完成即便是已經達到99%也一樣是沒有完成。當然,前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum,則應該盡可能在團隊開始時,就先定義何謂「完成」。

以開test case為例,完成是指把要做的功能的test case詳述在某個測試文件管理系統上?還是只要先用excel或者wiki列出來即可?test case完成後是否要先讓團隊成員審閱,看看有沒有問題?要不要先估計每個test case執行會花的時間?test case的前置作業 - 例如建立測試資料等等,是不是也要涵蓋在其中?

當有完整的工作完成定義之後,要讓負責進行工作的人「決定時間」,而非「被決定時間」。

以軟體專案而言,任何超過2天的工作項目(task),都應該分階段完成。畢竟,就事實而言,一個人不可能「連續工作2天」,每天一定會停住工作,下班回家。而這些階段應該要有階段產出。以test case而言,假設有10個新的user story需要建立test case,則今天完成了4個,表示還有60%尚未完成。


三:能力分配

如果團隊成員的確很專注於工作,而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩,牽涉範圍廣。以軟體專案而言,能力並非只是撰寫程式,測試程式,理解規格等等。能否和其他人合作,也是能力的一環。

一個規模中等的軟體開發團隊(4-7人),如果有一個人的能力「極端」的差,確實會造成專案很大的問題。

在Scrum的情況下,這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多,但未來的sprint的進度,是以團隊能力來考量,因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下,可以先找到該成員的相對優勢。排定一些學習項目,來提昇該成員在這個專案中的相對優勢,並且在未來安排相對優勢的工作。值得一提的是,根據經濟學的「比較利益法則」,每個人一定會有所謂相對優勢:請參考這裡,和這裡。

關於軟體開發團隊的個別能力,還需要注意以下幾點:


1. 每個人都會成長,但是....


每個人都會成長學習新知識和能力。但是!在中短期專案裡,必須先考慮個別能力與優勢。

換言之,團隊領導要像下象棋一樣,找到每個人的「專長」,能妥善組合專案,就是個好的領導者。

而差強人意的領導者,則是常常試圖規避個別成員的「缺點」,這樣比較不會出大問題,但也容易產生差強人意的結果。而最糟糕的領導者,則會把人當做圍棋,看到人非黑即白,見到專案漏洞時,看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質),但在軟體開發專案鐵定行不通。


2. 能力是綜合考量...


能力必須綜合考量「全方面」:例如是否好溝通,是否能處理複雜的設計問題,能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外,如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者,應該先思考自己是不是「問題的來源」,甚至要思考自己是不是根本不適合作為團隊領導。


3. 讓不適任的成員離開...


讓不適任的成員離開,某些時候是個可行的解決方案。特別是某些企業管理派別認為,投入時間在不適任的人身上,他有可能變得適任,也有可能不會改變,然而投入時間太多,會造成專案延誤。

以Scrum的角度來說,這個情況不太會發生,因為2-3個sprint之後團隊速度已經確立,無論適不適任,專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言,讓破壞性的不適任者離開,當然是解決方式,但不見得要「找另一個人進來」。






相關文章:人才管理,心智圖,為自己工作...



9/30/2016

企業巫醫 - 實習生的三贏




巫醫通常會告訴病人事情的「權衡」:是想要錢還是健康?是想要貢獻祭品還是得罪惡靈?當需要獲得健康,當然就要犧牲其他東西。

許多事情的確是如此...總不能要馬兒跑,又要馬兒不吃草。

不過,對於需要創造性思維的現代企業,權衡在於真正的目標,和創意的達成方式。把馬車換成內燃機驅動的汽車,就是革命性的方式讓移動的東西大幅加速而且不用吃草。

企業實習生也是如此。

高明的策略,就可以達到三贏。普通的策略,就會犧牲某些地方。愚蠢的策略就是三輸。

以資訊科技產業來說,三贏的情況是:


對企業組織來說:有低成本的方式,獲得高潛力的「人力」。讓工讀生能先處理簡單,可學習,重複,但是可改進的工作,使團隊成員專注在複雜的開發活動上(註1)。藉此了解這些工讀生未來的潛力,同時也能透過有效分工,提升績效和產出。還能順便展現企業的社會責任決心。甚至,透過實習生循環來訓練組織內部未來的領導人才。

對社會來說:降低新鮮人「嘗試錯誤」的成本,增加投入的生產力。

對新鮮人來說:提早知道自己的興趣和能力。在還沒踏入職場之前,至少對工作有所體認,瞭解軟體工作真實的一面。無論未來是不是要從事同一行業,踏實並且正確的工作經驗,都能引導未來的發展。

普通的情況是:


對企業組織來說:在暑假期間,統一由HR辦理招募活動,發配到各個部門,和夏令營一樣在兩個月期間和團隊一起合作,可能有產出也可能沒有。

對社會來說:讓大學生研究生在暑假能有除了閒晃打電動之外的選擇。

對新鮮人來說:可能像參加夏令營一樣,但只要有認知,還是能學到很多。


有三輸的情況嗎?


會有三輸的狀況,通常是乩童式策略規劃,和不正確的預期:

乩童式策略就像是有件困難的事情,是在我們的智慧能力尚且不能了解,所以我們就去問乩童,而乩童也不懂,但是他可以「起乩」,透過起乩,從其他地方得到智慧,來回答問題。在各個部落的巫醫也都有類似「起乩」的行為。即便只是實習生策略也會有淪落到乩童式規劃的可能。而這樣的策略結果等於是靠運氣,運氣好的時候甚且可會收到好的效果,但不可能永遠都是好運氣。

對企業組織來說:只是因為「聽」企業巫醫起乩之後,覺得弄幾個工讀生來好像很不錯。因此,就隨便找幾個進來。但由於沒有組織,沒有計劃,就只能做沒有意義的工作。更有可能還會故意製造的沒有意義的工作給工讀生。參考這裡。

對社會來說:浪費了人力

對新鮮人來說:對企業造成不必要的負面印象。也沒有真正學習到工作的意涵。



如何達到實習生的三贏策略



達到三贏的方式,當然是以事實為基礎,避免乩童式目的,達到漸進式目標。

以資訊科技,或者,軟體開發相關企業來說,掌握以下事實,就容易達到三贏。

(1) 培訓是必要的:

的確有很多自動自發學習,又很聰明的學生。但是稍稍有計劃的訓練,可以大幅降低走錯路的時間。而培訓不只是「教」而已,找一些主題讓實習生自行學習也可以。

(2) 長期:

對資訊科技相關的工讀生來說,

A: 一個禮拜來兩天,連續6個月。

B: 全天候,但只有2個月。

這兩個方案看起來實際工作時間似乎一樣,但是,最後能達到的學習效果和產出,永遠是A比較好。因為,資訊科技並非勞力型的工作,而是思考智慧型的工作。當實習工讀生對技術產生興趣時,自然而然會再額外的時間,補足在技術和知識上的不足。而且,考慮到前期的培訓時間,超過6個月以上的實習才能可能達到三贏。

(3) 務實:

讓工讀生參與真正任務,但由基本開始。讓實習生去撰寫核心模組,是本末倒置的行為(註 2)。但只讓工讀生去打掃辦公室也沒太大意義 - 除非這是一間專業清潔公司。以軟體開發而言。以下幾件事情都是比較適合的切入點。

A: 簡單的執行測試計劃(test case):是最容易入手,並且也比較能直接產出貢獻的事情。

B: 驗證文件:例如將api文件中的範例依照手冊執行看看會不會有意外,也是產出貢獻的一種。

C: 專案助理,協助收集進度,現況,簡單統計目前在版本控制系統(例如git/cvs/p4)裡的程式碼增減狀況...。這些看似助理類型的工作,可以讓工讀生對軟體專案的進展有很完整的概觀。

(4) 實習生的週期循環:

工讀生從開始招募,訓練,到離開,最好是6-18月之間。必須要簡單完成的循環規劃。實際的例子如:

A:  招募大三四研一二的資工資管資科相關學生。
B:  為期最短6的月 每週來兩天 時薪固定為XXX元。
C:  到期根據實際表現可能會續約一次。大部分會續約。
D:  座位和電腦設定已經事先準備好 (已經有check-list)。
E:  主要先進行測試相關工作,但偶爾做點瑣事(例如訂下午茶)。
F:  每年的都是由某資深工程師負責,今年負責人為某甲。
G: 合約到期離開的check-list。




(5)利用實習生培育未來的領導人才:

成熟的企業組織通常趨於緩慢成長。也就是說,除非有人離開,不然從升遷為基層主管的機會將會越來越少。然而,在團隊培育領導人才,卻是必然進行。讓有潛力的團隊成員,負責整個工讀生的循環週期。藉此,歷練作為領導主管會經歷的所有關於「人」的大小事情。畢竟,並非所有技術專精的人都適合當領導者,而透過執行實習生的策略,不只培育了實習生,也可以培育團隊的未來領導人才。即便最後發現某些技術專精的人不適合作為領導者,風險也比較低,畢竟他僅只負責工讀生,不是突然之間負責領導整個開發團隊。

很多時候,即便實習生不能達到原本規劃的要求,光是能夠陪為組織內部未來的領導人才就已經十分划算!






註1:「簡單,可學習,重複,但是可改進的工作」和之後提到的「無意義的工作」截然不同。以軟體開發中的測試工作而言,雖然某些情況需要大量人力測試,但是,更多狀況是當工讀生了解測試的意涵之後,大多數都能改進測試的方式,在某種程度達到自動化測試。而「做出」自動化測試程式,對工讀生來說就變成可學習到很多的工作。

註2:但也不能排除剛好招攬到一個天才中的天才的可能性。因此如果真有這樣能力的人,應該直接讓他轉成正職。




9/25/2016

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


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

那結論呢?


就人類來說,時間是中性的。它不是朋友,也不是敵人。它不是惡靈,也非天使。

在有限的職業生涯,如果你找得到自己的方法駕馭它,那非常恭喜!這可是上天給予的重大天賦之一。

如果始終在瞎忙中度過,或許試著混合數種前面的巫醫建議方式,可能會有些幫助。

但有幾個重點...


1. 考慮事實


企業組織為求營利的天賦,自然趨向去做幾乎任何可能產生商品競爭力的方式。以時間為衡量標準,恐怕是在天然資源和資本取得已經趨近最佳化的情況下,最合理的方式。

如果你覺得在企業組織工作時,自已的時間被無聊的瑣事白白浪費,氣的想要出來創業....那麼,你一定要先考慮是大部分的人,是自己無法控制時間,而非被別人浪費。這種情況下出來創業,會讓你本來每天花8小時幫某公司做事,變成每天花16小時,幫自己的公司做事。

時間既然是中性,增加效率當然是可行。加速?聽起來跟前述的巫醫有什麼不同(註4)?

重點在於:無論是個人還是組織。找到真正的目的,比產出效率重要。

而真正的目的在於考慮真正的事實。企業巫醫有許多手段和方式,都可以協助你找到「真正的事實」。

以個人生涯規劃而言,最終,這個事實也有你自己才能夠斷定。

然而,以在企業組織內部工作,真正的事實,或者是真正的目的,必須要來自「團隊目標」和「組織目標」。



2. 兵貴神速 v.s. 後發先至


重點在於:長期累積比短暫績效重要。

當企業組織可以在某個產品推出時領先,當然要持續領先推出其他產品,或者領先產品的其他服務。在這世界上有太多的先行者,無法保持領先而被後來者居上。兵法也有云:「後人發,先人至,此知迂直之計者也」,後發先至,其實是兵貴神速的對應。


個人工作上也是如此。快速完成的工作,如果不能累積優勢,就浪費了速度。以軟體工作而言,快速完成功能固然重要,但是功能上的完整以及品質,卻是快速的「基礎」。因而,採用敏捷開發的任何方法論,都不能以快速作為藉口,直接放棄功能上完整或者品質。

後發先至的基礎其實也在於「快速」。但是,個人快速的反應,其實是長久實力的累積。例如,對營運Linux平台十分熟悉,有很多年踏實經驗的工程師,自然在對應新的Linux雲端營運(例如AWS,Azure的Linux虛擬機)就比較容易適應。而過去僅在windows平台上有營運經驗的IT人員,如果整個系統要搬移到Linux為基礎的平台上,就算他可以很「快速」完成一部分,也不見得做的完整或者達到好的品質。


3. 時間乃最終之敵人 ...除非...


時間從很多角度來說確實是最終的敵人。它雖然是中性,但是它永遠都會流失。它的離開是必然而且無情。無論這禮拜天你做了什麼,禮拜天一定會過去。

因此,現實的說,時間乃最終之敵人...除非......讓它變成「敵人的敵人」。

以近年來的新興網路企業而言:

無論有沒有特別認知,事實上都試圖以「時間」來建立其他對手的進入障礙。若非以極高的成本獲得市場佔有率,讓其他競爭對手花更多時間才能開發產品,就是以需要時間累積的功能作為競爭主軸。

以個人的生涯規劃而言:

剛踏入社會的新鮮人,勢必缺乏實務經驗,無論是在爭取好的工作機會,或者是已經在企業裡面爭取好的表現,都不能是以「經驗值」來作為依靠。

以經驗值產出「工作表現」,大部分情況下新鮮人是無法和老鳥相提並論。但是相對於工作N年的老鳥比較起來,在「時間」上新鮮人擁有更多彈性。所謂時間,切記並非加班時間,而是「第一次就做對事情」的時間,透過學習和利用比較新的知識範疇,新鮮人可以比較快跳過錯誤的嘗試,在某些未來有發展潛力的範圍,有更驚人的表現。這時候,時間就會是朋友而非敵人。

相對的,已經工作了7年以上的老鳥。如果老是只能靠吹噓過去已經結束的專案經歷,無法產出對應的經驗值,那麼這七年時間就變成是最大的敵人。只是看到最新的技術,就隨意一頭栽進去學習,則時間就會是資深工程師的敵人,因為通常資深工程師的彈性時間實際上比較少。

資深工程師,在工作上必須要找到能夠善用這七年的成功或失敗經驗的地方,並試圖累積更多。即便是想要打掉重練,也應該透過經驗的累積,重練的更快,更好,甚至自動化。找到可以累積的地方,這時候,時間就是朋友而非敵人。

以作為組織內部的部門主管,專案團隊領導者更是如此:

當領導者使用以下手段時,是把時間當做敵人,(然而,要打敗時間實在太難)

* 加班
* 在軟體專案延遲時利用人月計算方式增加人力
* 以未來的產能估計時間,而非以過去的事時估計
* 以各種理由拖延專案,包含把責任推到別的團隊身上
* 專案過程並未檢視真實進度
* 假裝使用agile敏捷開發,實際上還是waterfall
* 不正視事實
* ....(還有很多)...

那麼不採用以上手段還有什麼可以做的呢?當然很多!如果你是領導者,但是想不出來其他方式,那麼你可能不適合擔任困難任務的領導者,因為「時間」永遠是你的敵人,而幾乎沒有人可以打敗時間。




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

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

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

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


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



在每年不可計數的企業管理勵志書籍中,有越來越多把「時間」視為判斷事務的重要標準。想當然,個人「時間管理」變成一種必要的技能。然而,更近一步是在越短的時間,達到越驚人的效果,從早期的「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:增加工作效率?聽起來和前述的巫醫有什麼不同?就想要達到的效果來說,有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理,經過有效驗證,而且可以在未來檢討改善。



9/18/2016

數據分析從零開始 - (3)外部取得資料

...續<上篇>...

外部取得資料

最常見的就屬於在網站上資料取得。最近由於透明化政府政策越受到重視,可供老百姓取得的資料就越多,當然可供作為資料分析的運用就多得不得了。


直接取得可程式化資料


資料本來就提供給外部取得用以計算,例如:政府開放資料。資料好不好用,是另外一回事,但起碼大部分的情況下,這類型的資料只要能下載就足夠應用。

有些資料可以api的方式取得,通常需要申請權限,典型的像是facebook graphic api,musicbrainz api,wiki api等等。

假設需要的資料都可直接程式化取得,那真要感謝上帝。資料數據分析就少了一大堆痛苦的事情要處理。

有個重要的技巧:利用Shell以及試算表對資料做基本驗證。這和前篇雷同。不過在此以試算表為例。

外部資料取得如果已經是整理過的,必然可以用很簡單的方式驗證。即便你沒有Excel,也可以先利用google的googledrive產生樞紐分析表。

作法很簡單。以前陣子最有名的資料:不動產時價登錄為例,

(1) 首先,到內政部網站下載公開資料

http://plvr.land.moi.gov.tw/DownloadOpenData。
它提供了很多資料格式,不過請下載csv格式。

內政部雖然是一番好意,提供各種格式資料。但坦白說,只csv格式是真正正確容易處理。其他格式根本是多餘而且難以直接利用,它的xml並沒有定義namespace,會讓需要合併處理xml時,要重新定義所有的node。

(2) 選擇其中一個csv上傳到googledrive,上傳之後是預覽狀況,請參見下圖:



(3) 按下右上角的:使用『google試算表』開啟

這時候會把csv格式自動轉換成google試算表內部格式。請注意這個格式,並非excel。

(4) 在試算表上選擇「資料」,並選取出現的「資料透視表」。要注意的是,這裡雖然是資料透視表,但是其實下一個畫面名稱就變成樞紐分析表了。





(5) 樞紐分析表出現後,是空的。在右邊選擇想要的欄列。之後就可以自動展示簡單分析的結果。

下圖的例子是以桃園的區作為列,建物型態作為欄。並且在「值」的位選擇平方公尺的單價的平均值(Average)。這個基本的分析可以很快的看出來資料的特性。舉例來說,在這段期間,屬於廠辦的交易就只有龍潭區。






間接取得資料


許多有用的資料,都要自己寫程式來取得。特別是,這類型的資料雖然公開,但不期望也不希望被程式大量取得,例如統一編號查詢。這種資料通常會用captcha來阻擋,不過現在破解captcha的工具和機率越來越高,現在比較重要的網站都改成以「請點選以下哪幾張照片裡面有老虎」這種方式處理。


在1996年之前,間接取得資料的通訊協定有很多種。但是,現在http幾乎已經統一可公開間接程式化取得「資料」的所有方式。而也因此,所有間接的,可程式化的取得資料大概都只需要專注在http。

簡單的說,只要 

(a)熟知http crawler (爬蟲)技巧 

(b)程式化處理html 或其他格式文字

就大概可以解決75%以上的問題。

建議的步驟為:

步驟一:找到正確而適當的目標。


不是所有外部資料都是好資料。倘若你想要蒐集在台灣關於醫療方面的問答資訊。或許你會先透過google隨意查詢一下,接下來,你可能會看到 verywed.com 有很多有趣的訊息和網友經驗。如果你就真的覺得上面的資料有用,那麼你等同是蒐集了眾多無法證實的資訊,造成資料嚴重的可信度問題。

雖然google也並未對所有資料的可信度加以查證,但它的演算法可以利用交互連結,以巨大的資料排比最可能的結果,而巨量資料在很多時候,可以彌補質的問題。

個人的爬蟲和資料蒐集,當然不可能做的和google一樣。至少從零開始的時候是不可能。因此,有意義,可信的資料來源變得很重要。

以前述的醫療資訊而言,台灣衛服部的台灣e院網站所提供的問答資料更具可信度。因為,回答問題必然是「具名」的醫生,當然其專業和可信度比「不具名的網友」高很多。

台灣e院看似複雜,但簡單來說所有的Q&A檔案歷史,都可以由一個ShowDetail.php加上簡單的參數以GET方法取得細節。每個網站的作法都不一樣,仔細觀察每個查詢按鈕,加上一些經驗與知識,絕大部分的網站都可以找到某種規則。比較複雜的網站,請善用瀏覽器的「開發人員工具」。

步驟二:以curl或其他工具,先行測試


在mac或linux上都有的curl指令,是在撰寫爬蟲程式之前,最方便先測試的小工具。

在很多時候,甚至可以利用curl配合wget,可以連程式都不用寫就抓取一整個靜態網站的資料。

例如,以下指令可以取得q_no=111521的網頁資料。(參見下圖)


#curl http://sp1.hso.mohw.gov.tw/doctor/All/ShowDetail.php?q_no=111521 -o onepage.html






步驟三:以script撰寫能處理與轉換儲存資料的程式


以台灣e院為例,要取得所有Q&A的歷史檔,只要知道「大概」最後的q_no編號,再寫個簡單的python程式即可。

要特別處理的地方只有:

(a) 不存在的編號:每個網站處理不存在的resource方式各有不同,以台灣醫院為例,仍然會在http reponse中回應200,但是內容改變

(b) 編碼:這個網站使用big5,但為了未來處理方便,最好先轉換成UTF-8。範例中使用requests取得網頁之後,理解編碼並且轉碼。注意!大部分的big5會被誤以為是ISO-8859-1因此要先強行指定為big5之後再轉換

(c) 轉換格式:當然不會想要整個網頁存檔,只想要問答內容。範例中使用lxml的xpath的方式直接取得所需要的element內容。


程式碼參考如下:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import requests
import time
import sys
from io import StringIO
from lxml import etree
from datetime import datetime

for i in range(34500,34520):
        time.sleep(3)
        print('working on'+str(i))
        url='http://sp1.hso.mohw.gov.tw/doctor/All/ShowDetail.php?q_no='
        r = requests.get(url+str(i))
        r.encoding = 'big5'
        htmlstr = r.text
        if htmlstr.count(u'不存在</h1>') > 0:
            print('ignore '+str(i))
            continue

        parser = etree.HTMLParser()
        sio = StringIO(htmlstr)
        tree = etree.parse(StringIO(htmlstr), parser)
        question = tree.find(".//li[@class='ask']")
        allq =""
        for t in question.itertext():
            allq = allq + t
        dr = tree.find(".//li[@class='doctor']").text
        ans = tree.find(".//li[@class='ans']")
        alla = ""
        for t in ans.itertext():
            t.replace("\n","")
            alla = alla+t

        oneResult = {'a':alla,'q':allq,'dr':dr}
        print(oneResult)



步驟四:考慮儲存地點



網頁可以儲存為靜態檔案,也可以分析欄位後,儲存在傳統資料庫,但近年來更流行存在nosql中。

可選用的nosql非常多,mongodb, AWS的dynamodb, elasticsearch, couchbase...都可以。

前述的範例,倒數第二行:

oneResult = {'a':alla,'q':allq,'dr':dr}

其目的就是在於轉換為python dict之後,很容易處理為json或者直接利用各nosql的sdk,存入到儲存地點。


步驟五:慢速進行


大部分的網站其資料當然是公開讓廣大網友使用。然而,程式化使用,例如利用爬蟲大量下載,通常是網站管理員不會特別注意到,然而爬蟲程式的確有可能讓網站變慢。

作為一個自治網路世界的好公民,首先應該先了解該網站是否有robots.txt,也就是定義爬蟲程式的規範。如果有,那就應當遵循。如果沒有,應該要在爬蟲程式中,適度的停一段時間。

例如,以前述範例來說,在for迴圈中使用time.sleep(3),讓每一個http request都等3秒鐘之後才進行。這樣雖然有可能讓爬蟲程式本來需要1小時就完成,變成足足3小時以上,但可以確保該網站不會受到你的爬蟲程式太多影響。








9/14/2016

企業巫醫 - 人才管理...人才根本無法被管理


任何能在企業講幾個小時的顧問,都一定會說「在組織中,人的問題最重要」

雖然這句話說的似乎很有道理,但是等同於廢話。這和「颱風明天會來,所以會刮風下雨」一樣,人盡皆知,說了等於沒說。

但是只要是軟性的課程,例如:成功主管的教練技巧之類。都會開宗明義的,告訴虛心向學的主管們,「人的問題很重要」,並且在接下來的8小時,展示一些似乎有用,但很難執行;或者幾乎沒用,但容易執行的技巧,來讓經理們主管們理解:「人的問題很重要 - 但是也實在太難  - 請自己好好體會,好好努力吧」。比較好的顧問,會拿自己豐富的失敗經驗(註1),用作為警惕 - 這樣還算有價值。但只靠講話的顧問,就只能如同電視名嘴一樣,以幽默的方式打發大家的時間。

既然知道困難,也應該認知困難的地方,透過承認困難,踏實的因應困難,才能在人才培育與經營上找到對組織有用的創造性作法。

對於眾多企業巫醫來說,讓事情變得越複雜,越困難,越不能解決,自然就容易強化巫醫的效果,並且萬一巫醫的作法不靈驗的時候,也容易找到推卸的方式。畢竟,是惡靈不願意配合你的祈求,不是巫醫的錯。

如果你恰巧是資訊科技的主管:無論是軟體開發團隊經理,或者資訊部門主管,只要你負責「管理」團隊,則團隊的人才經營策略,應該會是你最先要考慮的。

無論組織有多大,無論你的職位有多小,無論人資部門的策略是什麼,無論工作壓力有多大,無論專案團隊所使用技術多神奇......無論任何理由,團隊的人才經營策略,應該是團隊主管首要考量的事情!

每個困難,作為負責管理人才的主管,都應該試圖做出合邏輯的,可執行,有創造力的解決方式:

困難一:區別人力與人才


人才之所以難管理,是因為「人才」根本無法被管理。「人力」才能被有效管理。

所有大型組織,很難真實區分人力跟人才。即便是做機械性動作的生產線員工,在效率和品質上仍然有極大的差別。從早期豐田Toyoto的全面品質管理(TQM)開始,到1999年許多人的智慧統整出精實製造(Lean Manufacturing):揭示了一件明顯的事實:

「實際做事情的人,才是真正知道怎麼做的人」

但是,這個事實卻也隱含著另一件事情:

「在實際做事情的人之中,有些人才,才是真正知道怎麼做才好的人」


但人力跟人才很難區分。以資訊科技為例,任何可衡量的指標,都只能短暫有限的區分人力和人才的差別:無論是寫程式的速度品質,完成任務的完整度時間,程式維護的難易度,對新技術學習的速度等等。這些可衡量的指標,可以很快挑出老鼠屎,可以有效的找到連人力都不算的冗員,但卻很難在短時間裡認出千里馬。

把所有可找到的指標,綜合起來,確實比較可以找到潛在性的人才。但是所花的時間成本太高,而且利用指標的做法,很可能會無意間讓組織朝向「指標」前進,而非「目的」前進。

例如,以軟體專案為例,如果指標是「完成code行數」,配合「每千行code發現的bug比率」,則有可能會產生一個大而無用的系統,程式碼很長,而且根本不會被用 - 當然也不會有bug。

任何在人才策略上,所使用參考的指標,最好都是「隱性」指標,而且必須是簡單有用,常常可以反覆檢驗。例如,這個員工,過去12個月,曾經「主動」提出並且「實作」過哪些軟體專案重要的模組。或者,這個員工,在過去12個月,曾經「主動」做過哪些和軟體品質相關的事情。


此外,以過去的貢獻和產出為區分的標準:這在軟體產品開發上是一個稍微可行的做法。但是,所謂的過去貢獻,不應該是過去35年的貢獻和產出,頂多是過去3年的貢獻和產出。而也必須要確保,這些產出,能有效被歸屬。

舉例來說,一個軟體團隊有10個工程師,共同完成一個很了不起的產品,然而因為市場的關係,產品銷售不好,最後也停止銷售。這10個工程師,仍然擁有產出的貢獻歸屬。但是!這個軟體專案的專案經理,就應該承擔產品錯誤的責任歸屬。然而,由於大部分的產品經理都能言善道,因此,最常看到的是產品經理拿著過去失敗的經驗,拿來宣稱他「從錯誤中學習」,「得到寶貴的開發經驗」,更糟的是宣稱「產品的方向沒問題是公司策略改變」。

從錯誤中學習當然是寶貴的經驗,但是「必須真有學到,然後在爾後,因這些錯誤經驗而成功」。單只有「失敗的經驗」對未來毫無意義。請參考飛鼠裝跳傘(註2)。


在科技軟體產業,最踏實地的區分出人才的方式是:

(1) 面試時以情境實例面試法,了解他過去「做過的事情」,而不是未來「想要怎麼做事」

(2) 衡量工作情況是以「做出來的結果」,而不是以「講出來的結果」,當然也不是以待在公司時間長短,請假的多寡,發表的意見等等...

(3) 盡量試圖找出人才,而不是找天才。換言之,每個人都有某些能力和特性是組織所需要的,只要這個人可以把能力和特性「貢獻並且產生」出來,那麼他就是人才。反過來說,如果他會10種程式語言,還專精6種作業系統,並且還可以解決NP compete問題的難度。但是,卻因某些因素,沒辦法貢獻他的能力到組織或專案中,那麼他依然「不是人才」



困難二:培育或取得人才


資訊科技產業大部分都會宣稱自己很願意培養人才。少數倒是很誠實地說,他們想要直接用挖角取得人才 - 特別是最近幾年的中資企業。

由於培育人才表面上會遇到「培育後被人挖角」的風險。並且,取得人才,表面上通常能在比較短的時間,開始貢獻到企業。因此,許多在成本上沒有限制太多的企業,對於中階人才使用直接取得,也就是挖角,的機會越來越大。

這兩者都有很大的困難,但就資訊科技的角度而言,無論打算培育,或者直接到人才市場找到最適當的人,都不可能避免要「人才培育」。

資訊科技人才無法由人力資源部門統籌培育,必須要由技術性的部門執行,但是技術性的部門卻不見得有空,也不見得會知道重要性。

因此,常見情況是:「我們是on job training,有問題盡量問」。

代表事實就是:「我們不會,也沒有時間訓練你,將工作交給你之後,你就要自己想辦法學習,並且搞定它,當然有問題資深的人如果有空就會回答你。過一段時間你能生存下來就是好員工」

這表示,這個組織對人才培育的策略是......沒有策略,完全看個人造化和運氣。當然,最後的組織在人才運用的結果也是看造化和運氣。

對於規模夠大的組織,其實是可以用所謂沒有策略的方式,因為人數夠多的情況下,某些人才常常能夠單靠自己的能力,脫穎而出。但是在這種情況下脫穎而出的人才,很容易就會被其他組織「取得」。

雖然人才培育很困難,但是比較腳踏實地的做法是:

(1) 對剛加入的人,無論資深還是資遣,根據組織的現況,給予1-3個月的足夠學習期間,訂立學習計畫,在還沒有正式給予任務之前,有對整個團隊,先有全盤性的了解。

(2) 對於已經在組織很久的人,盡可能就現有的專案,進行延伸學習,這個延伸學習不見得是要去上課,可以提供他們「考證照」的經費,讓他們透過「考證照」來主動學習。請謹記:考證照不見得要考很貴的,因為重點不是在於證照本身,而是在於學習。


困難三:薪資獎勵


對於白領技術人才而言,薪資獎勵難以取得真正效果。

首先,傳統的增強理論,對人才:完全沒用!完全沒用!完全沒用!

但是對人力或冗員倒是有些效果。但企業組織為了表面上的公平,通常會試圖制定一體適用的政策,因此,大部分的傳統企業,或多或少都會運用蘿蔔跟棍子。

薪資獎勵,無論有多驚人,都屬於保健因素。換言之,如果不滿意,就很難留住人才,但如果滿意了,也只是「錢有到位」如此而已,一旦不能滿足激勵因素,換言之就是「心委屈了」,仍然無法用薪資獎勵來留住人才。

但反過來說,用夢想,希望,成就,甚至改變人類的命運等等「自我實現」的理念來作為取代薪資獎勵,恐怕也絕對行不通,因為激勵因素和保健因素,兩者無法互相取代。參考:雙因子理論。

大型組織中的某部門,或者某團隊負責人,通常也無法對薪資有大幅改變的權力,頂多是在年度考核的時候,決定某個人加薪的多寡,或者紅利的多寡。薪資獎勵,對有足夠規模的公司而言,整體結構早就是固定的,第一線主管僅有調整的空間。因此即便可以透過薪資獎勵來激勵員工,也不可能巨幅調整。即便可以巨幅調整,也不可能長期滿足。

因此,資訊科技根本不可能用薪資獎勵的方式激勵人才,留下人才,讓人才持續對組織貢獻。

既然不可能,就要換別的方式:



不大幅使用薪資,也能激勵好人才的方式:


(1) 選擇


提供選擇,或者讓團隊了解選擇。

早在2008年,Zappos就已經設立了離職獎金。讓想要離開的員工,更容易選擇離開。因為,一個勉強留下工作的人才,肯定不會認真付出,他就會成一個人力,更慘的是會變成冗員。而組織要花更多的時間成本。

在台灣作為第一線主管,大概很難說服人力資源部門執行這麼激進的作法。但是,在職權範圍之內,可以清楚的告訴成員,離開組織是一個選擇,當然很歡迎你做出「貢獻」組織的選擇。大部分的人才,在被鼓勵自由選擇的情況下,一旦做出留下的選擇,其貢獻一定會是「人才」的貢獻。

這也不是什麼新鮮事。

從1945-1962年間,不斷重複進行蠟燭實驗。到最近一本很紅的書:如何讓馬飛起來,之中提到的Amabile所做的獎勵 vs 選擇研究。都不斷指出,有創造性的工作,在事先已經知道有獎勵的情況下,其實績效比較差。

以下摘錄自「如何讓馬飛起來」一書:


60名大學生,他們將參加一項人格測驗才能拿到學分,測驗過程中,研究人員假裝錄影機壞了,無法繼續進行。然後她告訴其中一組,稱為「無選擇─無獎賞」組,他們必須完成拼貼畫來代替測驗。另一組「無選擇─有獎賞」,必須完成拼貼畫,但是可以得到2美元。詢問第三組「有選擇─無獎賞」,是否可以做一幅拼貼畫,但沒有任何獎金。再問第四組「有選擇─有獎賞」,是否願意做一幅拼貼畫,拿2美元獎金。為了加強獎金效果,她在獎賞組創作時,把兩張紙鈔放在他們面前。最後全部的作品由一組專家進行評審。這次實驗裡,獎賞果真激發出最有創意的作品──來自「有選擇─有獎賞」組;但最沒有創意的作品,也與獎賞有關──來自「無選擇─有獎賞」組。沒有獎賞的兩組,得分在兩者之間。就創作而言,選擇改變了獎賞所扮演的角色。創意表現最差的那一組,問題顯而易見:他們感受到的壓力最多。
而「無選擇─有獎賞」,正是大部分上班族工作時的實際處境


但是,如果這個獎勵,是事先有選擇性的,也就是可以選擇,那麼績效會更好。文中所提到上班族工作的情況是,無選擇-有獎賞。

其實第一線主管,是有機會加以改變:只要坦然的羅列選擇,不斷的提醒團隊成員:「這是個全然自由的世界」,「你可以去你想要去的任何地方」,「我絕對不會阻止任何人離職,甚至會幫忙寫推薦信」,當然也要提醒:「我不想要任何人離開,在這個團隊我們會讓每個人有機會成長為人才」,「雖然我不能保證薪水,但我能保證你必有成長」


(2) 人才合作 vs 人力合作 


團隊如何合作,是主管最能影響團隊的事情之一。簡單的說,資訊科技團隊必須要能先考慮彼此優勢,透過發揮彼此長才合作;而不是考慮彼此的劣勢,透過避免發生問題的方式合作。

只要參考經濟學上的比較利益法則,找到團隊成員彼此間比較利益的優劣,就有機會讓大部分的人「變成」人才。

但如果在工作分派是以「剛好誰有空」這種區分方式,就會讓大部分的人變成「人力」。


(3) 成長優先 vs 產出優先

人才的成長培育優先,或者產出也就是績效優先?乍看之下是二選一的問題,其實是必須要獲得雙贏的問題。


作為第一線主管,必須要透過培訓以及帶領的方式,有效讓人才成長,透過人才成長,讓產出更有效率。

如果面臨二選一的情況,在短時間當然選最適合的。但是中期長的規劃,必須一定要能滿足兩者。






註1: 通常不太會有成功經驗的分享,因為在人才管理有真正成功經驗的人,很難有機會變成企管顧問。

註2: Franz Reichelt, 飛鼠裝的先驅,然而他過去的飛鼠裝實驗都沒成功過,就嘗試從艾菲爾鐵塔跳下,結果當然是...