遠端工作與工作環境研究

遠端工作，在武漢病毒的影響下，突然得到許多公司的支持的，但是我是覺得等到熱潮一過，多數公司還是會叫大家乖乖回去上班的。

以谷歌為例，在 2015 年以前，是支持員工遠端工作的，只要你是好人材，可以在地球的任一地工作，一個團隊的成員可以在不同的時區跟地區上班，但是自 2015 年後，谷歌開始要求團隊的成員搬家到同一個城市去，不再繼續支持遠端工作。

以谷歌二十萬的員工數量來說，是有辦法做很多辦公室研究的，我猜想谷歌內部的研究單位應該是發現遠端工作的效率並不好，才會要求團隊在同一個都市上班。

遠端工作

在我的記憶中，最早鼓吹遠端工作的，是 Ruby on Rails 、Rework 中譯：重來：更為簡單有效的商業思維、Remote: Office Not Required、It Doesn't Have to Be Crazy at Work的作者，37 Signals 的兩位創辦者 Jason Fried 與 David Heinemeier Hansson （DHH）

他們這幾本書，從第一本出版在 2010 到第三本在 2018 出版，內容的精神都很接近，但是讀者我的心態卻有很大的不同，我把我當年寫的感想引在這邊

原文寫於 2014/05/12 談 DHH 與 Kent Beck RIP TDD 的戰文

DHH 在 Rework 中自述到，他偏好帶領一個三十人的團隊自在的工作，而不要把組織擴大到上百上千人把自己搞的焦頭濫額。 DHH 在組織架構跟應用範圍的偏好偏食，讓我在讀 DHH 文章時都會先考慮過他的出發點跟局限性。

以程式設計師的角色來說， DHH 的精兵政策當然看起來很爽，我自己也做過類似的選擇，捨棄 Java 而就 Scala ，追求更高的個人產值。

然而若是以一個架構師的角度來說，我的目標是成為像 Martin Fowler 的角色，相較於只有 36 個員工的 37 signals ，ThoughtWorks 是個有超過 2500 個員工的專業代工廠，在 ThoughtWorks 掛頭牌的 Martin Fowler 在技術的選用上，自然的考量要更全面，顧慮到不同應用領域的開發需求、以及不同程度的程式設計師該怎麼管理

DHH 對 TDD 的批評我多數同意，尤其是 Testing / DI 對 Design 的入侵也是一直困擾我的問題，但是我是把 Testing 當成一個需求來看，所以是多一個需求造成的額外成本在困擾我，而不是降低可讀性等問題在困擾我。

在目前看不到較好的替代品之前，我還是會繼續用 TDD (w/o test first) 來做設計上的工法。

原文寫於 2017/09/02

這幾天被新的歐盟法規 GDPR 整得很慘，對整個商業軟體的市場，又有不同的見解。 在商業 CRM 市場上，有四個主要供應商 Salesforce, Dynamics, Oracle, SAP ，四個都是有口皆呸的，但偏偏這四個就佔了市場的六成的市佔率。

為什麼呢？因為美國這邊大多數是上市公司，不管什麼規模的公司都在資本市場上市，相較於私人公司，上市公司受到許多的法規管制，在資訊系統採購上，只能跟某幾大公司採購符合法規限制的產品。

過去在飛向我們五個人做三個月的產品，在領英要十幾個人做九個月，然後還比較難用

領英上市前只有七百人，上市後，每年人力成長 30% 業績成長 50% ，沒幾年就變成一萬人的巨型公司，完全看不到軟體業說的乘數效應，在裡面工作，實在驕傲不起來....

過去我曾覺得 DHH 講說不想把公司做大，是他是野心不夠大，現在我反而很認同 DHH ，公司不用去追求大企業的訂單，而把自己的軟體架構、組織架構弄得異常肥大，每天上班都是處理不完的整合問題。

扯遠了，把主題拉回來，我接觸過一些遠端工作者及遠端工作公司，發現，遠端工作有許多的先決條件，例如：團隊成員的流動性不能太大，大家要有時間磨合出來默契跟信任感，而且遠端工作者通常是對軟體設計流程有經驗的老手，不需要人帶入門；公司的產品要有很強的核心產品，團隊成員能夠理解公司的業務是什麼，像是 37 Signals 曾有五個產品線，但是為了強化核新產品，公司把產品線收到剩一個。

在這種先決條件之下，在疫情前，推廣全遠端工作的團隊，公司規模沒有超過 100 人，超過 100 人，就是 IBM Accenture 等做外包專案的公司。沒有常常需要跨部門合做的需求。遠端工作，並不適合「成長型新創公司」及「大公司」，較適合沒有對外募資的非成長型中小企業使用。

Peopleware

軟體業現在使用的開放辦公室，是從金融業交易員的辦公方式學習過來的，這種開放辦公室的優點，是資訊可以快速流通，適合在專案的初期，大家快速的交換意見，當兩個員工在討論時，其他人可以很容易的參與討論，但是缺點也是顯而易見的，就是當你專心在做事時，會被其它的員工干擾甚至打斷。

那是否有其它的辦公室型式呢？在Peopleware 中譯：腦力密集產業的人才管理之道這本 1987 年出版的老書中，引用了很多當年 At&t, IBM 等大公司做的辦公室研究，說個人辦公室才是較適合腦力工作者的辦公方式

TODO: 重讀 Peopleware 補上辦公室的介紹

TODO: 找出我 RealNetworks 辦公室的照片，或畫出配制圖

結語

軟體工程發展了近五十年下來，在工程方法論這塊上，大多時候，還是比較偏工匠精神，只知其然不知所以然，看到別人做有用，就照著做就對了；並沒有踏入工程科學的領域，找出在何種條件狀況下，遠端工作是適用的，在何種狀況下，遠端工作是不適用的。像是我上面對「遠端工作」的條件需求，也只我個人觀察後，做出的假設，並沒有透過統計學的方式，來支持這個觀察是否正確，更別說找出其中的相關性。

期望本文能啟發未來的軟體工程師，沿續前人的辦公室研究，用科學的方式，去分析出整理出，在那一種狀況下，該使用那一種工作方式。