2014年2月18日星期二

心得:Taipei.py 2014 1 月聚會

難得北上,趕緊搶頭香待命!




將近半年沒參加 Taipei.py
趁著北上觀看 2014 四大洲溜冰錦標賽的機會
再到 CLBC 參與聚會
這次讓我感到比較驚豔的是
看到一位大哥帶了三個小朋友(國中生)前來參加聚會
太強大了,想不到在臺北小朋友都這麼好學 ... orz



此次演講的第一個主題是:「SaltStack: 我如何學會停止憂慮並愛上 deploy」
講者為 Street Voice 的型男 Vinta
此講題國內較少見,對於需要管理伺服器的朋友,我覺得演講內容極有參考價值
儘管我不知道為什麼我遇不到 scalibility 的問題(不過就 n 台 16 核 8G 的伺服器)
不過幫 SaltStack 建立索引,並且存在我的航海資料庫內
總有一天會用到的(吧?)








第二場主題為「在世界的中心呼喊 Flask」,講者是被 Leader 勸敗/推坑 的 Tomas Lin
其實 Tomas 使用 Flask 的方式跟我的方式不太一樣 XD
我個人比較偏好採用 Flask 原生的方式直接呼叫各個 function
(當然,還是有透過 blueprints 組織這些 function) 而 Tomas 的用法與使用的技術堆疊,使得展示出的 Flask App 頗為 Djangolized
對於熟悉寫 Django 的朋友(例如:Tim)而言,可能會難以感受到 Flask 的特色
當然,還是比 Django 瘦很多啦 XD,反之,功能也缺很多





其實我認為 Flask 是一個適合用在「微」、「小」、「中」型專案的框架
而且依照需求能夠支援非常多的撰寫跟架構方式
看看這個讓人不會感到挫折的 doc 看看這些便捷的 extensions
看看熱血的教學 website
如果是 Web 新手入門要我推薦框架,大概就是 Flask 吧!
(如果只想玩一下,那就是 Bottle 啦~)






最後的閃電秀是由 Tim 投稿的「Remove the Callback Hell」





這次北上能夠在會前會後與講者、朋友們交流
並且聽到兩場讓人受益的演講,非常開心 : )


補充一下,第一位講者 Vinta 最近的專案「為什麼你們就是不能加個空格呢?」
實在非常有趣,有潔癖的朋友值得一試。
(好在我大多數情況會加上空格 XD)



2014年2月7日星期五

心得:Tainan.py x MOSUT 12 月聚會

感謝 iCoding.co 幫忙分享聚會訊息 XD



糟糕,已過完年!本文成為拖稿一年的文章 Orz
更糟的是,有參加此次活動的朋友
早已寫出精美又熱血的心得文
所以本文存在的價值大概只剩下引用這兩篇文章了:






此次活動第一位講者為 hychen
我在初學 Python 時曾有寫過一篇 Meta Class 的筆記
其實就是引用 hychen 的文章 XD
而本次聚會 hychen 給的主題為「Python type and object」
這是一個相對比較深入 Python 的題目
聽講前除了要對 Python 有一定熟識度之外,過程還得聚精會神多多思考



有趣的是,演講過程中 Isrlab 的 kuku 有根據 CPython 底層的實作來補充 Object 的命名
看來 ... 要透徹 Python 遲早都得向下「鑽」呢 :)



第二場講者為 Victor
主題為「KINECT 簡介」(與申請政府計劃的坎坷之路 <- 這是我加的副標題)



沒有聽到這場演講的朋友真的是虧大了
現場的精彩度極高:有八卦又有 live demo
想必大家聽完之後都會想收一台 KINECT 來玩 XDDD




第三場的講者是強者我學弟 Chun-Wen Hsiao (xlet),主題是「Git 狀況劇」





這是一場非常實用的演講(還搭配 live demo -> 帥氣!)
話說我之前有在網路上找到一篇整理得很不錯的 git 文章
Git 情境劇 - 好麻煩部落格 不過應該不是學弟寫的文章 XD




由於時間關係,原本的第四場演講延後至下一次聚會
對不起專程要來聽 kuku 演講的果凍 ... Orz ...

會後,我趕場參加了 創業抬槓台南場 的活動
及與 hychen 吃了宵夜,並向他請教一些問題(但是都不是 Python 的 XD)

最後的最後 ...
儘管與此次聚會無關,再來補充一份 hychen 介紹 g0v 的投影片吧(熱血啊~)



Welcome to Tainan !!


2013年12月20日星期五

閒聊:那些人年,我們一起跳的軟體開發坑

如果您已熟悉 Agile 方法或軟體工程且有開發經驗

那麼這篇菜鳥文可直接跳過啦! ... Orz

我跳「坑」了!


出來創業以來,體會到了一件「大家都知道」的事情:
「學界、業界、創業界之間是有資訊落差的,且越差越大!」
主要是因為真實環境變化大而學界動作太慢 ...

這將會使得學生總是用已逐漸成為歷史的「學習方法」學習可能已經成為歷史的「課程」
最終的影響是:「缺乏與外界接觸的學生,畢業後相對沒有實戰力,甚至完全不能用!」
進到大公司表面上還好,因為有新人訓練的規劃,以讓人變成該公司專用的人才
(顯而易見地,訓練內容是不會教該公司不需要的東西的)
若進到小公司或自行創業,則必然會有一段陣痛期,或者說是「鴻溝」必須跨越 ...

身為在大學研究所點了六年學生技能,後來才從軍人轉職成創業者
我在此分享這兩年來寫 Web, App 以來的心得:

1. 要培養「能」寫程式的能力不至於太難 ...

只要「一直」動頭腦想,有空補上一些學校沒教的書
(請謹慎閱讀/使用/或先不讀 Design Patterns)
寫出來的程式大概都會動 ...
(而且因為寫得很爛所以每次重寫都有進步空間)

2. 要培養「能」架構系統的能力也不致於太難 ...

看多就知道自己該用些什麼
試過就知道好不好用
(但是就算跟專家用一樣的架構,效能跟穩定性並不代表就跟人家一樣)

3. 要「能」順利開發專案很難 ...

真的很難!
客戶的「需求變更」等等外界因素固然會影響專案開發
但是更根本的原因是因為開發團隊:「無軟體開發的基礎知識與實作經驗」

這件事情有點恐怖,因為一次的專案開發,往往要花費好幾個人月甚至人年才能完成
缺乏規劃跟執行的專案,最終導致的成果就是:「一延再延」、「做不出來」、「提前終止」...
因此一個糟糕的專案,可以浪費掉一個人數月至年的人生 ...

有人問為何會無基礎知識與實作經驗?
因為學界內寫的大都是功能性程式,測完數據或是能夠 Demo 就功成身退了 ...
分組作業寫的專案,大都一人(或一神人)就可以直接 KO 掉 ...
至於課程所學的軟體工程 != 真實軟體開發
課程內容除了較廣以外,也往往位於過高抽象化的層級
對於根本沒有實際開發經驗的學生而言,修習軟工的課程是難以感同身受而觸發興趣的 ...
所以說,要一群剛畢業的菜鳥們,要從無到有的開發專案,會遇到很多困難

4. 要「能」順利創業登天難 ...

這不是坑,是大峽谷 -> BJ4。


要把程式寫好、架構出良好的系統是一件很難而必須一直學習的事情

然而,開發稍微大一點點的專案的時候
軟體開發的流程問題就會先被突顯出來,且牽涉其中的人員已經不是個人的事情
一個好的流程能夠讓開發者開心而有效率的製造「垃圾」(只要客戶願意付錢)
但是一個不好的流程,就算是在製造「寶物」,開發者也會覺得很痛苦


「坑」在哪裡?


以下條列一些常見的錯誤:
(這裡以中小型專案為例,不考慮短時間、少許人力可以完成的微專案)

搞不清楚客戶的需求

交付能夠讓客戶滿意的程式,並且依照其功能要求開發出產品是軟體開發的第一要務
所有人也都會同意,要經過與客戶密切溝通、互動,才能夠真正理解客戶的需求
更甚者,初步了解客戶的需求以後,團隊成員們該動起腦袋們,想想如何實作時
一定還會想到一些問題要釐清,或是需要客戶下決定的地方
因此,盡可能定期與客戶溝通,以追逐可能會有所變動的需求會是個好主意

問題來了?要怎麼知道自己已經了解客戶的需求?
不用懷疑!寫下來並且與客戶再次確認吧!
所謂的你「以為」已經了解客戶需求,跟客戶的「以為」你已經了解他的需求
都只是「以為」,且只存在於當下,無法有效傳達給不在該時空的人
用客戶看得懂的 User Story 與客戶驗證需求,才是保險且必要的作法

何以必要?因為舉凡專案開發,客戶一定會詢問開發時間要多久?
倘若沒有記下 User Story,那麼便不可能將其進一步擴展成 Use Case,抑或拆解成細部的任務
更不可能根據任務、以及團隊過往的開發效率「眾人一起」來推估出準確的開發時間
如此一來,要向客戶回答時間就只能「靠感覺」、「靠經驗」了
很容易承諾出一個根本做不完的時間 ...
更危險的是,因為沒有僅抓住客戶需求,產品還有可能不是客戶想要的 ...

這裡另一個常見的情況是,客戶找上門時已帶著所謂「寫好」的文件
文件可能是一張手寫的便條紙、兩三頁 A4 的規格書、UI 的畫面 ... 從殘缺到極度詳盡都有可能
此時要做的事情仍然一樣,協助客戶描繪出 User Story 並驗證需求
有可能只要改幾個錯字即可,或須將畫面轉換成描述更加精確的文字及規則 ...

客戶不會想要開發沒有使用情境的軟體
所以委託給你開發的軟體一定是給 User 在某些情境下使用的
(這裡的 User 未必是人,也有可能是動物或是另一個軟體)
藉由描繪並寫下 User Story 才能夠協助團隊捕捉客戶當前的需求
進而確認潛在的需求、知道「不要的需求」以及確定團隊每個人認知的客戶需求一致

缺乏計畫

當確定要開發客戶的專案,就到了為團隊排定行程以進行開發的時候
以下行程的排法都頗恐怖:
  • 「上線前一週,client 會和 server 串接以進行測試」(也太晚了吧!)
  • 「精密的排定每日行程至半年後」(過度計畫,根本不會準)
  • 「直接讓負責各區塊的工程師動工,他們會知道怎麼做」(確定?)
若以上述最末者為例,若 User Story (Use Case) 及任務等等已備齊
雖可確保當時開發的方向不會偏移掉
但,實作的人員是沒有「優先權」的概念,且預設不會對將來的「需求變更」有所準備的

倘若客戶在開發兩個月後,臨時想看 Demo 了解進度(結果程式架構要到第三個月才能串起來 ...)
或是臨時決定拿掉一部分比較不重要的功能(因為他比較好做,所以就先寫了 ...)
這都很可能會造成悲劇
所以說若只是訂出一個最終的 deadline 而不是分階段驗收
搞到後來產品拖延或失敗的機率是會升高的

因此,規劃階段式的開發週期,並且定期與客戶核對需求會比較保險
從更本質上來看,要排定週期內的行程,及預測自己是否做不做得到一定是比較準確的
這樣的作法額外的好處是,週期若固定,那麼過了一個週期後
透過比較「預測」情況與實際情況,是有助於了解團隊開發效率的
也能進一步改善「預測」能力,以便在下一個週期排定恰當量的工作

階段式的開發->展示->與客戶溝通,除了能跟客戶核對原本的需求以外
也能夠因應客戶的要求排入新功能,並且讓客戶決定優先權
有點像是:「您要增加 C 功能,可以喔!但必須延後 A 或 B 的開發,請您決定?」
在各階段開發的過程中,由於功能一項一項的完成,且可以被展示
所以客戶會安心、而開發人員也可以將壓力分散

埋頭苦幹

執行專案時,最忌諱的就是眾人都同時進入長時間的埋頭苦幹期而忘記專案的初衷與規劃
因此,請記得將專案開發的目標與進度透明化

專案開發的目標,對客戶而言自然就是滿足那些 User Story
對開發團隊而言,就是完成那些 User Story 所拆解出的細項任務
且這些細項任務是該被「估計」要多久才能完成的(不然怎知道此階段團隊能完成多少任務)

當這些必要的前置作業都完成後
開發團隊在短期埋頭苦幹以取得最佳工作效率時
才能夠隨時在休息抬頭時,看見工作目標
並透過比較實際花費的時間與估計值,了解工作效率
除了尋求改善,也能以此為經驗重新預估接下來的任務所需要花費的時間

糟糕的執行力與缺乏測試

糟糕的執行力有分許多層次,在此列舉部分:
  • 寫不出來
  • 寫很久才出來
  • 寫出來,但是錯誤百出
造成上述狀況的原因不外乎是「缺乏程式能力」與「缺乏測試」

工程師要有基本的程式能力才能完成需求的功能
要有一定水準的程式能力才能在時間內完成需求的功能
要有一定水準的程式能力與測試概念,才能在時間內完成需求的功能,且正常運作

補足程式能力,是所有程式設計師都知道要做的事情
資料結構、演算法、物件導向 ... 熟悉與否都會影響到開發出來的軟體品質
然而,「測試」的重要性是容易被忽略的
甚至,我個人認為對於使用 OO 語言的新手工程師而言
若有時間進修,學測試的實用性還遠大於 Design Patterns

理由很簡單:「程式碼總得被執行」

就算不套用書上特定情境的 Best Practices 來解問題
你也能用當前已掌握的知識來解決問題(雖然未必是漂亮的解法)
但是無論如何:
  • 每當寫完一個小 function,總得知道輸出的結果符合不符合預期
  • 每當寫完一個小功能,總得知道運作起來正不正確
  • 每當寫完許多小功能,總得知道相互運作使用時正不正確
  • 每當新增/修改部分程式碼時,總得知道會不會影響到既有的功能
  • 每當完成了一個版本以後,總得驗證在客戶的需求情境之下,系統運作是否正常
在「程式碼總得被執行」才能驗證對錯的情況下
研讀各種技巧、思維來最佳化「測試」這一件事情,是能夠對軟體品質大幅提升的

過度設計

「過度設計」在軟體開發的過程中無處不在,並不是只有在設計初期才會出現
巨觀而言,設計的軟體可能會擁有客戶不需要的功能、或是建構出不合理規模大小的系統 ...
微觀而言,撰寫了很多用不到的 function、為了大量地預留延展性而讓人不易理解抽象架構 ...

可想而知,「過度設計」會帶來的缺點就是「費時」
設計本身要花時間,因為設計而「Block」到其他人進度也會耽擱他人的時間
實作設計會花時間,因為設計太複雜,而得費更多力氣來實作,就得花費更多時間
最後軟體因為複雜度的提高,導致更多的臭蟲,得花額外的時間解決

要克服過度設計非常困難
總結來講,擁有「足夠的開發經驗」就能較妥善的面對「過度設計」的議題
然而,在累積足夠的經驗之前該如何對設計做取捨?

巨觀而言,時時刻刻謹記客戶的需求
微觀而言,隨時記得「程式碼總得跑」這件事情,讓程式碼的目的符合該粒度下的使用情境
甚至,透過優先考量「怎麼跑、怎麼用」這件事,先行實作測試並且同時設計出必要的系統



最後回到創業坑


之所以會有本文,是因為前一陣子看到了一篇文章:
對 Spotify 的組織感到震撼、佩服之餘,我也不禁脫口而出:

「這要怎麼打啊?」
「他們可是組織成了一支軍隊來跟別人打群架 ...」
「我們連願意一起打群架的人都還不多 ...」

我只能說 ... 創業要考慮的面向非常多
然而無論如何,資訊人最終還是得進行「軟體開發」才能做出產品
培養其能力與正向生態系的重要性自不可言喻!


備註:
本文非常簡略而不全面地探討軟體開發時常見的坑
(基本上,我都跳進去過了 ...有的還跳不出來 ox@#.) 
我也盡可能避開專業名詞,盡量換句話說,以練一下表達能力 (結果還不太行)
事實上,本文也是我讀完新手村內的「深入淺出軟體開發」後的心得 (有猜到嗎)
推薦給資訊相關科系大二以上的學弟妹讀讀(附上網友整理的筆記
或許你會因為沒有實際開發過軟體的經驗,因此不能完全理解書中講解的內容
但是留點印象是好的,若能激發你的興趣去了解軟體開發相關的技術就太好了!

2013年12月18日星期三

心得:AppWorks Demo Day #7

AppWorks Demo Day #7 已在 11/18 於台大醫院國際會議中心順利舉辦結束
詳情可觀看 Jamie 的 一句話介紹版本 與 之初創投部落格的介紹




這是我第五次參加 Demo Day 的活動
從局外人、局內人、記憶猶新到事過境遷(搬到台南)
每次參與都有不同的感觸

若要我快速的摘要這次的 Demo Day
我會說「演講表現是歷屆以來平均水準最好的一次」
儘管團隊數較少,聽起來不夠過癮
但是演說表現得更加沈穩且帶有誠懇
我不太喜歡所謂「套公式」「拍廣告般」的演講
前幾屆太過了點,這屆又好了點

本文不談各個團隊表現該得幾分或是是否有前景
沒意外,一年後至少有半數的團隊會 pivot 成別的方向甚至陣亡 ... Orz
我更在意的是總體的組成、走向、氛圍如何
這些資訊不僅能反應出創業的動向,也能夠知道之初創投挑選及培育創業者的情況如何

舉例而言,最近兩次活動都出現了軟硬整合(及穿戴式)的產品
可見創業者對於創業方向的思考能夠更加開放(本來就不是只有做 Facebook, Google ... 才是創業)
以往非常多人想挑戰的旅遊資訊整合服務,這次沒有人跳坑 ...

說穿了舉辦 Demo Day 就是強制讓各屆的創業者們
進行「DDD」(Demo-day Driven Development) 的創業之旅

對於菜鳥,因為期限已經定出來了,所以無論如何得在這段時間內生出東西
對於老鳥,則是一個規劃好的機會,得好好把握讓大家看見自己
在這段期間,則進行各種培育:「聽演講、參訪、演練、媒合、研討、諮詢、共享資訊 ... 」
要評斷這樣的培育有沒有效?是不是最好的?是難以回答的
同樣的機會成本,創業者如果更專注於做產品會不會更好?也是沒人能夠斷言
難怪乎記得 Jamie 有提到要五年十年後再來看看這一群人組成的生態系是否對大環境帶來影響 ...


但是若以軟體開發的觀點來看創業,這樣子的培育蠻科學的
培育過程就等於定下計畫及每個階段的檢核點以執行一個「創業」的專案

原因是:「新手寫程式容易過度設計,創業者也是如此!

定下絕對的 Deadline 就等於決定一個開發週期,以聚焦去完成這段時間內可以完成的事情
進而,各小階段完成的作品,都會有現成的測試者可以幫忙檢視、測試
當創業者有了「同學」,則共享的概念使得創業的過程能夠取用到他人願意分享的資源
(有點像取用開放原始碼資源的意味 ...)
在這種環境下,除了有機會修正創業方向(「做對的事情」)
也能夠在過程中一點一滴累積創業能力(「把事情做對」)
整體來講,應該會是一件好事


2013年12月10日星期二

心得:Tainan.py x MOSUT 11 月聚會

餐會休息時間,朋友們熱烈地互動!


這次聚會的場地回到 Isrlab!
多虧其大力相助,我這次有空去吃鹹酥雞 XD



睽違了兩個月的聚會順利舉辦完成!



這是 Tainan.py 舉辦以來最「南」的一次(無論是講題還是講者組成)
議題涵蓋 Python 的 GC, 部分底層實作, 數學x演算法x安全工程, PyPy, Git ...
紮實而接近 4 個小時的演講,讓聽眾滿載而歸
以下為懶人包的整理:


我負責暖場,重點其實是宣傳花蓮.py 已成立與 *.py 系列的工商服務




第一位講者為果凍(常在 Python 社群分享底層實作相關講題)
兩個講題為 Garbage collection 與 += vs. join 比較
前者搭配投影片,讓人很快地對 Python 的 GC 有初步的認識
後者 += vs. join 則相當解惑
我個人認為這兩個探討的主題都很有趣、實用而值得一聽




第二位講者為 kuku(Isrlab 員工 + hacker)
講題為「數學女孩之機率的崩壞」(數學、演算法與安全工程相遇 - 第一講)
事實上是資安入門及探討亂數產生這一件事情
這是我回台南以後第一次聽到資安相關的講題(真是太棒了!)




餐會交流時間,我們吃了友愛鹽酥雞 + 阿卿杏仁湯/紅豆湯(休息了半小時)



第三位講者為 jserv (神人 ... BJ4)
講題是 PyPy ,這個演講非常珍貴而難得!
怎麼說?一般人用 Python 一段時間以後,總是會想要了解其底層的實作(感謝果凍)
而當想要讓 Python 程式加速時,PyPy 總是會被拿出來討論
究竟 PyPy 是怎麼做到的,他到底是什麼?
由研究編譯器及 ... 多年的 jserv 來向我們介紹是再恰當不過了!(強烈推薦一看!)




第四位講者是 Descent,表面上投閃電秀,事實上錄影有 45 分鐘 XDDD
講題仍然為 git,介紹各式各樣修改 commit 的方式
如往常般,Descent 的演講都會讓大家打開話夾子
(究竟為什麼會從 git 探討到 3.5 磁碟片到用紙帶幫 CNC 機器開機,請看影片!)




演講結束後,留到最後的幾位朋友就一起去吃府城牛肉湯,圓滿地結束本月的聚會 :p


後記閒聊

會後有學弟(都比我早)寫了 筆記文心得文
文章提到聚會有上課的 feel,是的,這正是目前 Tainan.py x MOSUT 聚會的特色!

有別於 Taipei.py 20~30 分鐘的短演講
Tainan.py 的演講長度更像上課,常常一場 40 分鐘以上
但是不同的地方在於,聚會時間是週末,大家是抱著放鬆的心情與求知的熱血來參與
我發現,不去限制講者的演講長度與方式以後
講者不但可以分享更多,聽眾受益於輕鬆活潑的氣氛,也更敢問更多問題
雙方互相交流之後,自然而然就學得更多了!

(這或許也是一個理想教學 / 學習環境的雛形)

退伍後出來創業亂衝亂撞兩年以來 ...
多虧了沒有直接拿不知道堪不堪用的成大碩士文憑去大公司要一顆便當
而是彎下腰來種稻自給自足(結果發現自己不太會種,常常肚子餓)
看到自己的不足之時,也藉機不斷地去思考自己所接受過的教育、環境、心態哪裡出了問題
相信隨著麥穗越來越高,我也能用更加宏觀的視野看清楚答案 ...

總結目前的心得,我只能說:「學弟妹們,出來走走吧!」
沒事多關心、參與 open source 的 project
有社群活動、研討會也空去參加一下
最後,就算沒打算創業也稍微留意相關資訊(有個概念也好)

當學校某些課程落後太多,已經變成在教歷史課(ref: jserv)時
其實上課了解一下並無不可,歷史中總是有「教訓」跟當時的核心概念可供學習
但是當學校只教歷史課的時候
要不要到外面修「其他的課」就值得好好思考了。

工商服務: 就在 12/10 19:30 @ Isrlab
kuku 將加開一場數學及演算法與安全工程相遇的演講
歡迎各位朋友踴躍參與!聚會資訊

2013年12月4日星期三

好便宜書分享:網路強人會


書本實物大概長這樣
(螢幕背後露出來的網頁是 恰好 是敝公司開發的「手滑背單字」App)

先來猜猜這本書多少錢?

299? 還是 199? 難道只要 99?
事實上,不用錢!讀者只需要自行負擔運費 80 元即可取得

這是一本「自寫、自編、自行出版、自備通路」的書
詳情可以到氣勢磅礡的 pre-order page 瞧瞧!

這本書值不值得看?

我認為 Jamie 寫的 推薦文 非常中肯:
「我會把它推薦給想要進入網路及電子商務產業的人,以及在這個領域工作不久的朋友們。」
我拿到書以後,當天就花了 2.5~3 小時把書給掃完了(我看書頗慢 ...)
感想是:有所收益,可觀,且 80 塊很超值

出來創業一兩年內的新手們,其實還蠻推薦看看這本書的
尤其技術出身的創業者,總想著「我要怎麼做出一個偉大如 Facebook, Dropbox, Evernote ...」諸如此類的服務
卻往往特別不會對內容網站、購物網站、個人網站有所思考
本書作者光是能夠概略的點出這些網站分類,考量到台灣環境的情況下分享見解,就算是功德圓滿了

本人平常是少看網路行銷相關的東西,因為很多文章內容都極空泛
至於本書,我認為對我有參考價值
會不會再看一次不確定,但是要查資料時會記得這本書就是了!

備註:
1. 推薦給創業新手、部落客、對電子商務有興趣的朋友
2. 技術人,除非想要看一下專家如何分析各類型網站及經營指南,不然可以不用看
3. 要取得本書必須填寫會員資料進行註冊、作者的網站 滿滿的行銷個人媒體的資訊,完全符合書中見解 XD
(看完書後,我因此知道作者且相信他有料;作者品牌得到宣傳。這樣應該算是雙贏吧!)


2013年11月24日星期日

好書分享:Remote - Office Not Required

Remote 是世界知名軟體公司 37Signals 的創辦人發表的新書
他們的前一本暢銷書 Rework (工作大解放) 可以說是每位創業者必讀的好書


前言

儘管我積欠了數篇部落格文沒寫(尤其是上個月底的 MOPCON 2013 心得文)
我還是用個人閒暇有頭腦的時間「優先」把這一本書給看完,亦「優先」撰寫本文
之所以這麼做的原因是要驗證我自己的想法、以及找到一些疑惑的解答


中文版還沒出,如何取得此書?

我是在 iBooks 上面購買的!
為此我申請了美國 iTunes 的帳號,並且購買 GiftCard 以支付費用


為什麼想要讀此書?

我在 Startup 工作兩年,工作環境經歷了以下階段:
  • 「住辦不分,只有睡覺的地方跟工作區」- 極度燃燒(退伍後,短期這樣回魂最快)
  • 「住辦不分,但是是在自己的房間工作」- 效率極佳(但是要跟懶散奮鬥)
  • 「住辦略分,有自己房間,一樓是工作區」- 效率略低(意識到「干擾」這一件事)
  • 「住辦分離,辦公室在商業大樓內」- 效率極低(驚覺這樣下去不行)

其實隔離在自己房間工作的期間,就有 Remote 的樣子了
自己要調配工作與休閒
在這段期間,我一直嚮往的就是完全的住辦分離
但是很遺憾的,公司租用了辦公室以後,並沒有為我帶來更好的工作效率

我有很多的疑問(且大都心中有底了)
所以我非常急迫的想要閱讀此書


誰適合閱讀此書?

廣義而言,只要您對思考「工作效率」這一件事情有興趣,就很適合閱讀此書
此書或許不若上一本書 Rework 般一直讓人感到「當頭棒喝」
但是它提供了對於 Remote 的全面思考:
  • 對於已使用 Remote 的朋友:可供核對自身經驗
  • 對於想要 Remote 的朋友:當作 Guidelines 來閱讀
  • 對於從沒想過使用 Remote 的朋友:這本書的許多觀點將能解放你的思考
  • 對於完全認為 Remote 不可行的朋友:可閱讀後仔細想想「是否真的完全不可行?」

事實上,「老闆」會比員工更加需要閱讀此書 :)


此書內容在說些什麼?

有興趣的朋友可以前往官方網站 REMOTE: The new book from 37signals
內有宣傳影片、搞笑訪問影片以及部分章節試讀的連結
國外也有人整理出五分鐘懶人包:A Book in 5 Minutes: “Remote: Office Not Required”

本書的主要章節有:
  • The time is right for remote work
  • Dealing with excuses
  • How to collaborate remotely
  • Beware the dragons
  • Hiring and keeping the best
  • Managing remote workers
  • Life as a remote worker
  • Conclusion

書中理性客觀地分析 Remote 工作的優缺點
且透過全面性的思考,告知讀者如何實行 Remote 及解決衍生的問題


部分摘要與筆記

  • You can settle into your own productive zone. #Remote 的最大好處之一
  • It’s the technology, stupid #能夠 Remote 的最大原因之一
  • People go to the office all the time and act as though they’re working remotely: emailing, instant messaging, secluding themselves to get work done. #其實人們只是在辦公室做可以在遠端做的事情...
  • Embracing remote work doesn’t mean you can’t have an office, just that it’s not required. #37Signals 總部也是有辦公室的,只是員工可以自己選擇上班的時間地點。另外該公司大多數員工皆分散在世界各地
  • The bottom line is that you shouldn’t hire people you don’t trust, or work for bosses who don’t trust you #雇傭關係建立在互信之上
  • Why not let people work the way they prefer, and judge everyone on what—not where—work is completed? #工時 != 產能
  • If you’re in a room with five people for an hour, it’s a five-hour meeting. #常識
  • When you’re used to interrupting anyone any time you want, there’ll be severe withdrawal symptoms when you can’t. #Interrupt 對產能的影響大家應該都感同身受
  • You need solid writers to make remote work work, and a solid command of your home language is key. #雇用 Remote 員工時,要特別注重他的書寫能力
  • If people can manage to build world-class operating systems, databases, programming languages, web frameworks, and many other forms of software while working remotely, you’d probably be wise to look more closely at how it’s done. #世界一流的開放原始碼專案,不幾乎都是 Remote 開發的嗎?
  • Be on the lookout for overwork, not underwork #員工 Remote 時要擔心的真正問題
  • But when they become the norm—when they’re abundant—you’ve got a problem. #人類對於易取得的資源總是傾向不珍惜,Remote 可以讓面對面這一件事變得更加被重視,進而好好利用這樣的資源


37Signals 的人是如何工作的?

其實我猜,這是已在 Remote 的朋友最想要知道的事情
這些經驗大都打散在書中的各個部分
看過之後,可以一窺少許面貌:
  • Remote 的人要有基本的 Security 防範措施(書中列舉六點)  
  • Remote 工作時要與其他人有 overlap,建議 4 hours
  • 善用各種軟體以供協力作業(書的附錄有列表)
  • 每週進行一次「你最近在忙什麼?」的討論串
  • 一周工作以 40 小時附近為佳
  • 每個月至少打一通電話給 Remote 的員工,聊聊他們的情況(因為很多員工都在國外)
  • 員工會有一張公司的信用卡,使用準則是「spend wisely」(當然,賬單是記錄且公開的)
  • 員工如果要請假(無論長短),不用經過審核
  • 提防 overwork 而非 underwork
  • 有些員工在家會用各種不同的方法來區分出上班模式與休閒模式
  • 有人每天去不同的咖啡店工作,觀察細節上的異同
  • 書中有提醒到「人體工學設施」的重要性
  • 面試重解決問題的能力而不是腦筋急轉彎
  • 用 pre-hiring 的方式丟 mini-project 給面試者實作以評估能力(一兩周,給大約 $1500)
  • “Have I done a good day’s work?” 可以拿來自己詢問自己(不論是否 Remote)

另外,怎麼從到辦公室上班轉成 Remote?
他們建議可以從一周 Remote 幾天開始
看看發生了什麼事情?再來決定該怎麼做?
(建議要做 Remote 就真的做看看,一次 3 個月)

37Signals 在芝加哥的辦公室總部,有 13 個人有桌子
大多是情況只有 5,6 個人會出現


讀書前的疑惑

在公司租用正式的辦公室之前(住辦略分階段,一樓是辦公區)
我們就為了互相干擾、工作效率等等事情討論過

有同事說:「辦公室只能確保最低產值」
這句話大致上是對的,但是其實辦公室的作息有時候還不能守住最低產值
因為若精神不濟而寫出有 Bug 的程式,那就有機會變成負產值了 ...

隔一陣子以後,公司還是因為要招募設計師跟其他員工的需求,而租用了商辦
並且規定 10~12, 14~18 為工作時間(大致上是超短的工作時數)
儘管如此,工作了一陣子後我還是感到不對勁
當時我自己簡單筆記了一下家中工作與到辦公室工作的優缺表:
  • 家中
    • 優點 - 作息自己控制(可以無壓力的睡覺睡到自然醒)、自己切割上班/休息時間、工作效率佳
    • 缺點 - 可能會有家中事物的干擾
  • 辦公室
    • 優點 - 公私分明、有空調、視線明亮、便於溝通、有在工作的安心感、可訂便當
    • 缺點 - 睡眠品質變差、通勤要騎機車 25 分鐘(近 10 km)、很多干擾、中午飯後小憩的休息品質不佳、不喜歡公廁ooxx ...

不對勁的地方在於效率與工時,最終影響的結果是產量
在辦公室工作的效率評等,我自評大概是上午 C 下午 B,下班前會接近 A,工作時數是 6 hours
反之,以前在家中獨處時的平均效率是 B+,偶爾還能夠到達 S,工作時數 8+ hours
兩者的產值對比起來,相差甚遠

「這其中一定有什麼誤會!」

為了讓自己能夠在辦公室發揮更好的產能
我買了機械式鍵盤(讓打字變成樂趣 XD)
買了 111 人體工學椅(可以久坐不累、飯後還可以後躺 60 度休息,堪用)
無奈的是,產能的提升還是不夠 ...
更甚者,我發現下班之後,疲勞會讓我沒辦法在晚上做(與工作無關)其他需要專注的事情
至多只能讀讀少許較簡單的技術文章而已

大致估算一下,我發現一個事實:
我每天需要花 1 個小時通勤 + 8 個小時出門在外上班
然後可以得到中低效率的 6 hours 工作產值跟疲累的身心
荒謬的地方在於,同樣的事情是可以一個人在家中完成的,且效率更好
因此我一直在想「為什麼」跟「怎麼辦」 ...


讀書後的解答

與其說此書直接解答了我的疑惑
倒不如說隨著書中思考的脈絡,再來更加仔細想想「工作」這一件事情
一切就變得清晰易懂了

工作這一件事情建立在「意願」之上,有「意願」才有可能把事情做好
意即,在遵守最少的限制之下,「想工作才工作」「需要休息就休息」才是發揮效率的王道
限制工作的「時、空」並不是對每個人都適用的(或說對大多數人都不適用)
當時空限制被打破後,除了可以省下 context switch 的成本及消除 side effects 以外
有心要做事情的人自然會最佳化自己的「工作/休閒」演算法,以完成工作

舉例而言,上個月 MOPCON2013 結束後,我非常疲累(因為臨時投稿閃電秀)
隔天週一就在身心還沒回復的情況下上班,低效能地撰寫出程式碼
又心心念念該好好寫篇部落格來消化一下思緒跟補充演講的資料
最後 ... 遭遇許多外務後就很丟臉的就拖到現在還沒動工了 ...
理由是「下班已經累了、懶惰、過了最佳的時間點、有更重要的事情要做」

但是,事情是可以更加簡單而且圓滿的:
隔天上班,開完週會後跟處理必要的事務後,就該結束該天的工作的
剩下的時間應該轉為私人休閒時間拿來寫部落格
畢竟,「人要在最想要做的時候就去做那一件事情,才有可能把事情做好」
欠公司的時數,當天晚上或是分散在其他精神好的時候再補回來就好了

如果依循著這樣的思維仔細觀察
那麼就可以發現有許多公司,致力于企圖營造讓人覺得「很棒」的工作環境
比方說不強制上下班時間、良好的設備、能夠專心工作的小房間、休閒區 ...
這些措施的目的在於把對員工「時、空」的工作制約放寬,以提高生產力

會有 Remote 這樣的工作形態也變得合情合理
因為這樣可以打破大多數(並不是全部喔)的時空制約,以最大化效率
而就執行時數來講,Remote 其實也比較吃香:
  • 若一個員工一天到公司待 8 hours,則他的真實工作時間大概只有 6~7 hours
  • 但若要求 Remote 的員工做滿 8 hours,這可以說是很紮實的 8 hours

至此為止,若您是老闆,員工要求 Remote 工作,您會怎麼看待?


結論

請您也拿出紙和筆,簡單計算一下自己工作的效率與產值
想想看,有遭遇到哪些問題,有沒有辦法能改善與提升?
若您是老闆,也不妨對工作產值重新深思?坐在一起才是上班嗎?何不雇用遠方的優秀人才?

我相信當 Remote 的概念被您領略,即便不完全實行、甚至不實行它
您一定會發現能讓現況更好的契機

至於這一本 37Signals 創辦人撰寫的 Remote
它不但全局地從各個角度看待 Remote (絕非只有像本文般這麼狹隘的探討它)
也內含許多 37Signals 珍貴的思路與經驗,絕對值得一讀!

(對我而言,最大收獲是:告訴了我該如何工作與「生活」!