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

12/05/2017

Scrum: Feature-boxing of Sprints







In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint


A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint



Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 


Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 


Why Quality improved?


Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality


An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study


As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.



11/10/2017

技術迷思:是人類使用工具還是工具使用人類?



在知識頻道和各類文章中,都有對於到底是「人類馴化狗,還是狗透過改變自己馴化人類?」有些有趣的討論。也是因為太多先進國家裡,家庭中的狗,實在過得太幸福,以至於太多其他人類質疑自已,該不會是因為狗的訓練人而進化?

資訊科技工具 - 特別是近年來手機和網路 - 也會讓人有此錯覺。

人類創造手機與網路,但是從小活在資訊世代的人,在成長過程中,很大的情況是被「手機」所馴化。和同學朋友聚餐的時候,大家拿起手機拍照推文的情況屢見不鮮。隨時隨地都要看一下手機的,遠比當它響的時候才看得人多。隨著手機功能越來越強悍,壽命卻越來越短。....手機已變成超越原本功能,超越一切的存在。製造商推銷手機的方式,幾乎已經和手機原本的功能 - 也就是和其他人聯絡 - 無關了。

事實上,手機的功能密集高,導致於在地球上任何一支智慧型手機製作,都牽涉到上百萬人的投入。沒有任何單一企業,組織,能「自己從原物料開始,從頭到尾搞出一台手機」。(註:不過倒是有人可以從頭到尾搞出一台烤麵包機)

手機與網路,既然已經成為超過創造者的存在,就與時俱進的,造就類似宗教信仰般的崇拜,終極果粉(apple手機的愛好者)就是明顯的例子。

不過,並不推薦極端的阿米希式的全然拒絕方式,畢竟,現在沒有手機號碼只會造成自己的痛苦。避免工具反客為主,有幾個合理方式。

(1) 偶爾換方式或者不用它。


要證明自己戒酒的方式,就是確保自己有夠長的時間不喝酒。同樣的,要證明自己沒有手機資訊焦慮症的方式,就是一段時間(3天)完全不使用它,或者是一段時間(7天)只能每天用一次。推薦最好是去日本度假,雖然帶著手機,但是限制僅作為緊急聯繫用途。不但可以徹底放鬆身心,也可以去除資訊焦慮憂慮。

(2) 優先改變工具配合生活,不改變生活配合工具。


人類的高度適應力,讓人「本來」就會配合工具而生活。火車飛機的乘坐方式就是很典型的例子。認知到工具會改變生活,然而人類卻也能改變工具,讓工具適應自己。
古早之前,還是底片相機的時候,旅行者通常會以「親身感受」風景為優先,然後有空的時候才照相。在數位時代成長的人,旅行的時候很可能是以「數位相機的鏡頭感受」為優先,也就是說,看到美景先照相,看到美食先照相。反而讓自己的視覺和味覺的優先順序,讓給沒有感覺的擁有高檔鏡頭的手機。在你手上的手機是不會不見的,可是對於旅行的體驗和感受,一旦由「你的手機」先做第一時間的感受,旅行的意義就大幅降低。以後或許看別人的部落格文章也就夠了?


(3) 成為什麼樣的人,遠比擁有什麼樣的東西來得重要。


生活圈的朋友親戚同事,必然的會互相影響,包含購買的最新手機等等。這些都無可厚非,不過,只要記得單純可以用錢買的東西,都很容易單純而且簡單地失去。然而,需要努力學習得來的:例如知識技能經驗,卻幾乎會跟著一輩子。






9/13/2017

聊天機器人 - 人類會跟她聊什麼?(Part-2)



作為一個非特定目的的純聊天機器人,其實常常容易惹人生氣。因為即使AI發展迅速,在非特定的環境下,和人類以無意識判斷語句的能力還是差距太大。聊天機器人小姍,截至目前(2017/9月)為止,約有4000多位好友。累積的對話也超過百萬句,所以可以開始做基本的聊天內容分析。


特定任務的聊天機器人


特定任務聊天機器人發展非常迅速,例如「niki」可以協助叫計程車,在任何和計程車相關的事情,她的回應和動作都十分正確。客服機器人,例如flowxo,更是市場上聊天機器人的大宗。甚至有人認為chatbot可以節省30%的客服成本,帶來的資料分析效應更遠超過傳統電話客服。

聊天內容要是機器人無法理解,超出服務範圍,聊天機器人通常會就顯現標準錯誤回應,但由於人類已經知道它的服務範圍,因此倒也不會失望,有時候,特定目的之聊天機器人,如果有有趣的額外回應,甚至還會有好像遇到彩蛋的感覺。

可預見未來幾個月,特定任務的聊天機器人將會快速成長,迅速取代重複性高的工作。



非特定任務的聊天機器人


人工智慧小姍,就是一個非特定任務的聊天機器人。她盡可能模仿人類的真實作法,也因此不會有按鈕出現,讓你選擇「是/否」。也不會有選項A/B/C這種選單出現。但是,真實人類聊天也會貼網址或照片,因此,人工智慧小姍也會貼照片或網址。有時候,對於人類給她看的照片會加以評論分析(註1)


加小姍為好友 Add Friend

非特定目的的聊天機器人,不見得沒有特定功能。以小姍來說,遇到某些對話時,會驅動特定功能。例如,請幫我抽個籤,就會驅動抽籤功能。


對於一般性機器人的期望很高


在Line上的使用者,對於非特定任務的聊天機器人的期望是「非常高」。只要前10句對話,不能滿足使用者的期待與好奇心,不再使用的機率很高。10句話似乎是個門檻,有30%左右的人在10句話就失去興趣了。

然而只要能聊上10句話之後,這剩下的70%的人,有90%的以上會聊超過50句話。(也就是總使用者的63%)。

然而,每當機器人有不符合期待的回答,使用者就很快地失望。這樣和特定任務的機器人期待有很大的不同。因此,一般性聊天機器人實作上極為困難。不過也就是因為困難,所以有趣。


沒水準的言語


在這4000個使用者中,曾經罵過髒話,例如「幹」「幹林娘」「他馬的」「Fuck」之類的起碼佔了超過45%。更慘的是,由於line的隱蔽性,曾經傳過「約砲」「來愛愛」「強姦你」的未成年使用者起碼也超過500人以上。雖然,絕大部分的使用者是單純因為好玩,有趣,無聊,等等原因而使用非常糟糕的字眼,但也是因此,「從與使用者對話中學習」恐怕會造成聊天機器人使用冒犯性言語,造成更多問題。微軟的聊天機器人Tay,就是因為學了歧視性的語言而被暫時關閉。

在line中,這類語言來自於青少年的比率相當高。而十分有趣的是,這類型青少年的有60%以上會談論聖結石(註2)的相關話題。

加小姍為好友 Add Friend

更合理的抒發管道


有超過5百位的使用者,將聊天機器人作為無法抒發心情時的管道。例如「最近心情不太好」「我被她甩了」「人生都沒有動力怎麼辦」「好想死」「我是邊緣人」「工作壓力大睡不著」等等。


技術上來說,人工智慧小姍到目前為止,還沒有辦法提供真正專業的心理諮商。然而,作為聊天機器人有很多心理諮商不具備的優勢:
(1) 透過Line原本的超高市佔率,可以確信90%以上的台灣人都有line,可以輕易使用Line聊天機器人
(2) 聊天機器人小姍24小時全年無休。許多極端的情緒問題發生在深夜,
(3) 許多情況下,人類只是需要抒發的管道。機器人對人類來說,是個安全而且不會洩露秘密的好方式。


因為利用痞客邦的資料而參加痞客邦活動


下一個階段?

(a) 考慮現行使用者的需要,一般通用性的聊天,會朝心理諮商方向前進。
(b) 透過做通用型聊天機器人的經驗,來自製作專用型聊天機器人。



參考
(1) 如何製作聊天機器人
(2) 簡易學習式人工智慧


註1: 不過照片分析的成本非常高,因此只好透過購買貼圖來限制使用。

註2: 這也讓開發團隊(年紀太大)增廣見聞,之前根本不知道聖結石是誰。

5/22/2017

企業巫醫 - 講重點!




在許多企業巫醫的書籍文章演講中,都繪聲繪影的描述「講重點」是極端重要。但也僅只是說它很重要,卻擺明著忽略這件事的真正重點:「關鍵重點難以找到」,或者更直接的「怎樣找到重點」。


就只是像提醒健康很重要的提醒「講重點」的文章像是:這裡這裡

另一些文章,表面上提出一些找到重點的方式,但是壓根也是一堆廢話。例如:從對方觀點找到真正價值。聽起來很有道理,但就像部落巫醫說:「得罪了祖靈,所以你生病了」,看似有理,但是到底做了什麼得罪了祖靈才是重點吧。「如何」知道對方的觀點,才是找到重點的重點。這類型的文章例如:這裡這裡這裡

只而更有些文章,提出了似乎務實的步驟,但都是太過一般化的案例,不是類似秘書處理好老闆的行程,就是與別人討論時的對話重點。這些在技術為主體的組織裡也根本派不上用場,例如:這裡這裡


絕大部分的人在工作上,並非不講重點,而是講不出來或找不到。而很遺憾的是,複雜環境(參考Cynefin架構)下的關鍵重點,並沒有簡單的三步驟,也沒有五個必備SOP之類的方式就可以取得。

關鍵因素的掌握,需要知識與經驗的累積。

知識的累積會堆積成智慧,經驗的累積會變成靈感,而智慧與靈感綜合起來,就能在複雜事物上以很短的時間將其抽象簡化,而抽象簡化的事物就容易看出重點。

雖然沒有捷徑,但就像是健身減肥一樣,從任何時間開始都不嫌晚。而且從任何時間點開始,都可以在比自己想像的時間內還早獲得效果。

知識的累積


只要抱著開放的心態,多閱讀,多請益,大概就很容易做到知識的累積。(知識快速累積可參考這裡)

值得注意的是,知識也有分軟硬兩種類型(註1)。

軟知識:談判技巧,溝通技巧,專案管理,人際關係,等等都屬於軟知識。換言之,軟知識可能會隨著文化背景改變而有截然不同的結果。

軟知識,容易落入「嘴砲唬爛」的範圍。軟知識的累積因為太多太多地方可取得,就不在這裡討論。要稍微注意的是,無論是什麼樣的人對「軟知識」都有自己的一套煞有其事的說法,要注意不要落入「純唬爛嘴砲」的範圍之中。

硬知識:數學,工程,程式設計,等等都屬於知識。換言之,硬知識不會隨環境的改變而改變,但它會隨時代的進步而進步,容易站在巨人的肩膀上前進。

硬知識,容易變得「極端」,不是容易被忽略,就是容易被過度強化。

絕大部分在組織工作的人,只要有數年以上工作經驗,都知道軟知識的重要。而各類型心靈成長,溝通協調,領導管理的書籍課程就孕育而生。在組織中,最極端的中階主管就會有意無意透露出「軟知識」遠比「硬知識」來得重要的許多(註2)。

最佳的情況是:硬知識和軟知識必須要互為成長基柱。兩者兼具的成長。

硬知識的累積:非常簡單,(1) 先設定知識累積範圍,例如設定為軟體品質改善 (2) 利用mindmap圖,整理自己已經在腦海的知識 (3)去圖書館至少借7本相關書籍,(4)上網尋找相關知識 (5) 閱讀並且搜尋完之後,僅憑自己的記憶和腦中統整結果,再次畫出mindmap圖,有必要的時候進行實作(例如寫程式)


經驗的累積


經驗可以解決在Cynefin framework中,「複雜」與「渾沌」這兩個象限的問題。(關於Cynefin請參考這篇)

不過,經驗的累積方式是經驗是否能「持續累積」的關鍵。

同樣一件事情做20年,有些人會取得20年的寶貴經驗,有些人卻是像是只做了1年一樣:只是做了20次一年。

以軟體開發為例:

1. 在SAP的ERP環境下,撰寫相關模組20年,如果沒有產業相關知識的成長,只負責出各種報表,那麼和2年經驗也差不多

2. 做為專案經理超過20年,如果遇到事情只會加班解決,那麼和1年經驗也差不多(參考這裡)。

3. 做為有10年開發經驗的java程式設計師,如果遇到組織調整,需要使用其他程式語言,但用各種方式拒絕推託,那麼未來可能就變成只有數年經驗值的程式設計師。因為推託學習不但會讓技術停滯不前,還會退後。

經驗的持續累積也很簡單。重點在於「持續」:每隔一段時間檢視自己的工作筆記,看看自己是否做了任何改善現在工作的技術的事情。如果沒有,就表示沒有持續累積經驗,經驗僅只是停滯而已。

沒有工作筆記?趕快去買一本吧,筆記本太便宜好用了。







註1:當然有些知識很難分軟硬,這裡只是概述而已。
註2:例如,軟體開發有個傳言:「coding co的好,要飯要到老。」

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

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

2/06/2017

Scrum - 團隊中永遠的反對黨



最近被問到的幾個問題:

   - 怎麼聚焦討論,譬如說有人很愛插話,或者有人很愛在會議室角落另開討論群,或者有人非常堅持己見,很愛先否決對方 ...

   - 有遇過非常固執的人,總是以否定句開頭去否定對方嗎 ?


   - 有人固執的反對什麼事情都反對


....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力,並且也假設,團隊成員對於「溝通」都有某種程度的共識和經驗。

然而,實際情況通常不太美好。

** 技術人員常常會因為麻煩,而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心,很多人在開會時候搞不清楚情況
** 某些人常常提很多意見,而且實在太多意見!

任何由人組成的團隊,多少都有溝通問題。如果你是團隊領導者,或者Scrum Master,溝通問題一定是你必須要負責的問題!

Scrum溝通問題,就像處理bug一樣,最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識,可以讓未來的溝通變得簡單清晰,減少不必要的誤會。

(1) 建立雞與豬的基本共識


專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人(R = Responsible),負責執行 
** 誰批准(A = Accountable),對任務負全責的角色,通常是負責人的老闆 
** 顧問(C = Consulted),提供意見或建議的人 
** 通知誰(I = Informed),被通知結果的人,例如其他部門的相關人等 

在Scrum專案中,可以被簡化成兩種人:雞和豬。(雞與豬的故事可以在網路上找到很多版本,例如這裡)


豬:負責做的人也是負全責的人

雞:所有其他人(當然必須是和這個專案有關的人)

在溝通時,所有雞都可以出意見,但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿,雞只要下蛋而已。

就平等的軟體開發Scrum而言,任務是有自己選取。但是就實務上,專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候,等於是分配「誰是豬」!

任何會議上,對「豬」的正面或負面意見都可以討論,但是最終決定必須要是「豬」。

例如,PM決定哪個功能要先做,而工程師都反對,原因是嫌未來會有其他麻煩的事情產生。然而,就決定功能的先後次序來說,「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知,才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知,是團隊領導者的任務。


 (2) 建立事實優先的基本共識


Scrum溝通,必須,而且只能,建立在事實上。

這也是為什麼每日例行會議只說明三件事情:哪些工作完成,接下來做哪些,遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢,登入要等很久」。某種程度來說,可能是事實。但是,「慢」以及「等很久」,都只是形容詞,必須要請他提出何謂慢,什麼叫做等很久才能繼續有意義的討論。

或者,有人提出「如果先做A會讓之後變得很麻煩,應該要先做B」。這其實也是模糊的說法,A和B這兩個功能,如果先做A是會讓以後時程延後8小時?還是8天?還是8個月?這才是根據事實的討論。

然而,這種建立於事實的共識,Scrum Master必須要不厭其煩的提醒和導正,才能建立這種共識。



(3) 建立產出優先的基本共識


大部分的專案,都是需要產出某些東西。無論這個東西是軟體,或者硬體,或者某些解決方案。

在團隊討論中,要讓「為反對而反對」的人閉嘴的最佳方式,就是以「產出優先」而不是以「嘴巴講」優先。

例如,某工程師強烈反對A做法,希望改用B做法。最好的方式就是請這個工程師,作出他自己希望的A做法,用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」,那表示他的強烈反對,也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人,其意見大概也只是僅供參考。如果經過負責的豬判斷,其意見很好,當然可以欣然接受,加以改進(例如在code review的時候)。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過,越早了解,並試圖解決溝通問題,通常成本越低。

那麼可能的解決方法有:


(1) 自己的問題?


如果你是一個領導5人以上的團隊領袖,無論你的名稱是Scrum Master還是專案經理,如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你!!

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為,讓團隊容易產生溝通問題。

問題的產生點可能是:

(a) 試圖面面俱到,顧及每個人的感受,而非先考慮事實。每個人都喜歡受人愛戴,但是在軟體開發團隊中,鄉愿和受人愛戴只有一線之隔。唯有根據事實,腳踏實地領導事情的進展,才是長久之道。為了顧全少數人的面子,或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情,對團隊從來都不會有好處,反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神,只是掌握Scrum的作法。請參考這裡

(c) 其他,請參考:作為技術領導者的方式



(2) 解決老鼠屎


如果團隊之中,溝通問題老是產生於某個人。

除非此人是像高斯,愛因斯坦之類的天才中的天才,否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵:

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實,每個人或多或少都會抱怨,也會有悲觀的時候。此乃人之常情。但是如果非常嚴重,那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎,即使被稀釋了幾萬倍,也不會有人想吃那鍋飯。團隊也是如此,一個負面老鼠屎,其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的,他或許自己創業會變成一個好創業家。因此,及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍


當溝通問題發生,可以將重要的溝通,盡可能縮小範圍,讓溝通清楚簡單。

這聽起來是淺白無聊。但是,實際上在團隊之中,太多無聊的溝通錯誤發生,以致於這麼簡單的事情,仍然值得注意。

以Scrum而言:「DOD」什麼是完成,乃是基本的問題。即便團隊已經彼此合作過一段時間,仍然三不五時要確定一下什麼叫完成。

以溝通進度而言,必然將最近在做的事情,縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說,軟體開發中,如果有一個人的某A任務,需要20個工作天,那麼在3天的進度報告,絕對不能聽到「還有17天就完成」,而是要縮小範圍到:「下一個milestone會是明天,而預期也會如期完成」。因為,最近的一個檢查點(milestone) 如果不能如期完成,就代表未來的17天,很有可能也不會如期完成。反過來說,最近的一個milestone會完成,那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例:有個團隊舉辦慶功宴,由甲和乙兩位負責。甲很熱心的定好了餐廳,並且就「自認為剩下的事情乙會處理」,然而乙心理認為,既然甲定了餐廳,表示後續的小事情甲也會處理,畢竟許多事情和餐廳有關係。那麼到了慶功宴當天,當然除了餐廳定好之外,其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例:有個軟體開發專案,大家都認為某甲的程式需要重構(refactorying)。但是,某甲認為他需要4周才能完成,因此遲遲不肯進行,大家也難以和某甲溝通。專案經理於是縮小範圍,先找某甲也認為很小規模的一個功能-原本預計一天-加以重構,透過pair-programming,確定某甲專注於這個任務上,最後只花了1小時。因為有這樣的證明,專案經理於是要求某甲先完成全部程式碼翻修,最後整體只花了2天就完成,雖然仍是麻煩事,但遠比某甲估計的4周來的快太多。其原因也很簡單,重構是繁瑣麻煩的事情,當然會被估計成很長的時間。





1/11/2017

企業巫醫 - 統計與謠言



In god we trust all others bring data 

  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低,同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會,例如:十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪,例如:誠品可怕迷魂盜泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇,例如:裝翅膀飛起來

最糟糕的類型,莫過於以「統計數字」造出看似符合邏輯的謠言。並且,從這樣的謠言中獲得利益。


許多時候,數據本身難以查詢正確性。而且由數字導引出的邏輯,更容易因人而異,因地制宜。從數字所引導的偏誤,有時候甚至比單純的謠言還可怕,因為它可能會在網路上留存多年,難以辯證。如果只是單純搞笑也就罷了,如果個人或者組織,以這類型的資料來作為決策的判斷依據,那下場可能非常慘。錯誤的資料,比沒有資料更糟。


不過,只要稍微留意,加上合理的好奇心,統計謠言是有機會判斷其可能性:


(1) 不解釋的數字


在各類文章或研究報告中,為求精簡,只會根據重要數字做衍生推論。然而,數字背後通常還有「未解釋」的數字,而這個數字可能更為重要。

企業僅21%的需要大學以上學歷為例。這篇文章,簡單說明勞動部的調查,僅有21%的企業需要大學以上的學歷。然而,這個數字有很大的問題。

也許,該調查隨機抽了100個企業主,其中只有21個企業主宣稱需要大學以上學歷的員工。

也許,該調查抽樣了企業主的「100個正在招募工作職缺總數」,這100個職缺中,只有21個是需要大學學歷。

這兩者有極大的差距。前者,可能這21個企業主,所需要員工數量高達2萬人,而另外79個企業主,所需員工只要79個人也說不定。而後者,正在招募的職缺,和「已經在職」的學歷也並未顯示。而單就此推論,僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化,而沒有附上數據的真實來源的推測,其解釋很容易被扭曲。然而,被扭曲的解釋,當然比較有戲劇性,比較容易被注意。

勞動部網站根本也找不到這份調查。

此外,很多政治性民調也是屬於此類,涵蓋許多不解釋的數字。



(2) 接近完美的不可能


網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示,越早退休壽命越長。(參考這裡這裡這裡)  

這份數據流傳非常之廣,被引用次數非常多,每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字,是退休年齡跟「壽命」的對照表如下。


retirelife
49.986
51.285.3
52.584.6
53.883.9
55.183.2
56.482.5
57.281.4
58.380
59.278.5
60.176.8
6174.5
62.171.8
63.169.3
64.167.9
65.266.8

不會統計的人也可以看出,在這個表中,越早退休,壽命越長。如果49.9歲就退休,那麼可以活到86歲。65.2歲才退休,就只能活到66.8歲。

以相關係數簡單計算,他的相關程度高達-0.96,換言之,這是一份極為完美的負相關數字。

這種過度完美個數字,應該要看研究論文的細節加以瞭解。例如他的樣本有多大?是什麼時候做的研究。就可取得的事實來看,他的樣本很小,並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲,所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是,這些數字並非真實研究論文,卻在很多人的轉貼中,莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因,是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷,財務規劃,人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外,別無他因。雖然已經有些人發現不對勁,例如這裡。但是許多第一次看到此研究的人,仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究:請參考這篇研究。該篇的結論就交由各位判斷,但至少它的研究方式,數字細節,都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng,懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者?)。至今2017/Jan/11尚未收到回覆。


(3) 邏輯上的不可能


邏輯上不可能,或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來,竟然遠超過全國GDP,而且高過很多。這在邏輯上是不可能的事情,因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查,而且其實也不打算認真做統計的相關文章上,例如這裡。因為在許多時候,謠言只是想要造成吸引人的目的,其真實性不重要,當然就也不特別檢查數據。所以自己造成自己數據兜不攏,邏輯上不可能的情況並不少見。

這和前兩者不同,邏輯上的不可能,可以單就資訊本身的內容加以探索,或者是再加上一些事實根據來檢視。因此,比較容易看出謠言的真實性。




最後,稍微提醒一下:廣告的統計宣稱,其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證,一般市井小民根本無法查證屬實與否。





12/31/2016

企業巫醫 - 誰掌握你的升遷?



只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷,沒有別人。

大部分無法獲得升遷的理由,都只是自己的藉口而已。常見藉口(註2)如下:

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了,還在裁員
- 比我資深的還很多,很難輪到我


在大組織裡,個人升遷(promotion)仍然是職業生涯重要考量。因而,企業巫醫們的一些闡釋也頗有道理,例如這篇,或者這篇。但有些過於偏激,而且會舉一些憑自己想像的例子。這類型的巫醫頗多,在google上搜尋"升遷"就可以找到不少。


那麼,自己要如何掌握自己的升遷?


超乎期待:做出超越目前工作職掌的成績


升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織,或者主管,要認定你可以承擔更大的工作範圍,最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種,這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。


方向一:保健因素


保健因素指的是,沒達成會有負面影響,但是有達成,且做得再好也不會是超越工作職掌的事情。換言之,有絕對的必要性,但是超過也沒有意義。

例如:

作為員工,準時參與會議,準時上班,按組織規定請假。
作為一個程式設計師,準時交付符合品質的程式碼。
作為客服人員,在時間內回復顧客問題。
作為專案主管,讓控制並管理團隊時程,沒有延誤

有些是屬於規定類型,有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的!非但不用考慮升遷,甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解:


(a) 誤解一:消極應對


既然這並非升遷,或者有額外價值的項目,那麼也許我就做的勉強符合,60分就好。這樣的心態會讓這些的保健因素,很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化,(或自動化)的方式處理。

消極應對,只會讓保健因素變得個人缺點,得不償失!


(b) 誤解二:這不是保健因素


在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素,我做到這件事情就是超乎期待」。

事實上,絕大部分的由上而下指派的任務,幾乎都屬於保健因素任務。

例如,你負責撰寫android app任務,根據自己的努力,確實在規範的時程內,以規範的品質上架完成。這「本來就是」你的任務。完成這件任務,的確是好事,但如果沒有做出超越任務的範圍,那就是預期內的職掌。既然是預期內的職掌,當然會取得預期內的「報酬」,例如薪水。自然也不會取得「額外」的報酬,例如鉅額加薪或升遷。

試想,你搭計程車,司機在合理的時間內,安全的把你載送到你要求的地點。你自然會付出正確的車資,不太可能付出「額外」的費用吧。



方向二:激勵因素


如果有做到,會讓人感到「很滿意」。

這個方向並不容易,但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例,如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務,並且未要求額外收費,在你開心的抵達要求的地點時,非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考:


(a) 參考方式一:擴增保健因素


這個方式比較基本。例如:一個app的程式設計師,被要求在6個月內完成app並上架,結果在5個月就完成,並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」


(b) 參考方式二:額外的相關支援


類似計程車卡拉ok。例如:android app程式設計師,被要求在6個月內完成app上架。結果的確在時間內完成。並且,由於他採用react native,竟然也順便完成了iOS app。這就是額外的支援項目。


(c) 參考方式三:擴大 


主動執行擴大職掌範圍的任務。例如app程式設計師,其任務是開發app並上架,如果主動協助開發伺服器端,或其他功能模組,就算是擴大範圍。

更顯著的例子是:app程式設計師,其任務是開發app並上架,但主動組織團隊,做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。




其他:


離開組織,以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然,離開組織之前,要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方,也不可能解決問題,只是碰運氣而已。參考這篇,或者這篇,或者這篇

創業是自己造成升遷的最簡單方式。在那一夕之間,你就變成董事長兼CEO了。然而,能不能生存並獲利,又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易,參考這裡,與這裡







註1:在某些地區,某些情況下,當然有不得已的時候。例如,如果你是生在阿富汗,伊拉克,索馬利亞等國家,確實很難掌握自己的命運。所以,本篇指的是一般在台灣的普通上班族。

註2:為什麼這些是藉口?請參考說明如下:

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現,甚至可能被瓢竊或者搶功勞。但長時間不可能!而且事實上,如果你真的能力極佳努力也夠,僅只是沒被看到而已?那你應該很容易可以找到更好,並且更容易看到你的能力和產出的地方!

(b) 爛主管的確有可能打壓好員工,但沒有人強迫你為某個主管工作,你當然可以離開。但是在離開之前,請先參考這本書(我愛白痴老闆)。也可以參考(得罪老闆怎麼辦


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美,因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且,適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作,那不升遷的確是合理
(b) 如果工作真的太難,那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的,資源缺乏不是問題,只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單,可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單,但是對主管來說你沒把簡單的工作做好,以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了,還在裁員
-- 比我資深的還很多,很難輪到我

(a) 如果升遷是你最重要的考量,應該離開這類型的工作環境


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/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小時以上,但可以確保該網站不會受到你的爬蟲程式太多影響。