▲ 左為宜睿智慧台灣區總經理吳宗翰，右為宜睿智慧亞太區產品策略總監蘇菲德索

Edenred 宜睿智慧於 1962 年創立，是一家在法國巴黎證交所上市的國際票券發行公司，去年集團年收高達 10 億歐元（約 360 億台幣）服務範圍遍佈歐洲、南美、亞洲共 42 個地區，有豐富的實體票券兌換經驗，在 2010 年開始進入以 B2B 為主的電子兌換券領域，發行「Ticket Xpress 即享券」，而台灣則是他們第一，也是唯一一個提供 100% 實施電子兌換券的國家。

台灣的行動市場廣大，接受度也高

宜睿智慧亞太區產品策略總監蘇菲德索 （Sophie de Thoré ）表示，選擇台灣作為電子兌換券先鋒，主要是因為台灣行動裝置持有率高，而且對數位兌換券接受度也很高。根據波士特市調《2015 國人電子兌換券使用行為》報告，有 8 成民眾希望透過 app 使用電子兌換券，也有 78% 的台灣民眾曾收過電子兌換券， 2015 年有1/4 的台灣人使用過宜睿提供的電子兌換券，同年也創下 728 萬張兌換券的發行新高。

由於主要面向企業客戶，宜睿智慧發行的 Ticket Xpress，對一般消費者而言可能很陌生，但宜睿智慧來台 5 年默默耕耘，一路上也得到了中國信託、台新銀行信用卡、SOGO、Yahoo 超級商城、LINE GIFT ，以及各電信業者、點數平台等 350 家企業客戶、45 個兌換品牌，提供 API 讓消費者透過簡訊、e-mail、app 兌換，已在台灣建設起了電子兌換的基礎。

包辦兌換券金流與資訊流

宜睿智慧台灣區總經理吳宗翰分析，對消費者而言，電子兌換券易保存，好管理，領取兌換過程又迅速，加上智慧手機普及，兌換券電子已成趨勢。不過 Ticket Xpress 負責的，是中介兌換品商家及提供消費者點數的企業客戶，舉例來說，消費者使用中信卡 app 的點數（企業客戶、點數平台），兌換摩斯漢堡的餐券（兌換品商家），在消費者按下「兌換」到成功拿到餐點之間，Ticket Xpress 幾乎包辦所有流程，包括談妥簽約兌換品牌、提供 API 給中信、替兌換品牌接上系統等。不同於「折價券」、「團購券」，「兌換券」是有價且長期的合作關係，企業客戶通常會每月或每週結清兌換品費用，Ticket Xpress 也會經手當中的金流。

吳宗翰也提到，宜睿智慧在歐洲有電子支付相關執照，在台灣信用評等也相當高，技術上有能力申請台灣的第三方支付資格，但由於台灣支付工具多元且成熟、電子支付市場小，因此暫時不考慮發展電子支付。

研究中國市場，伺機而後動

蘇菲德索表示，目前宜睿智慧在中國、印度、馬來西亞皆有據點，不過主要是早期的行銷以及實體兌換券服務，這幾個市場都是未來電子兌換券的目標，儘管中國行動支付發達，但情況複雜，仍在仔細觀察中，目前還是先在台灣累積經驗。

吳宗翰則提出，今年在台灣的目標將專注於拓展兌換品牌及通路，讓兌換更便利、品項更豐富、應用更廣，同時也要好好把握行動應用成長趨勢。

人事方面，宜睿智慧在台灣有 35 名員工，蘇菲德索認為亞洲電子兌換券後勢看漲，未來不排除在本地徵求人才，不過吳宗翰則表示目前工程部門位於上海，行銷部門在新加坡，而台灣則是以負責尋找合作夥伴的業務人員為主。

歡迎加入「Inside」 Line 官方帳號，關注最新創業、科技、網路、工作訊息

This posting includes an audio/video/photo media file: Download Now

photo credit:DAVID HOLT

Facebook 的工程師有哪些高效能工作的經驗呢？軟體工程師訪談了多位 Facebook 的高產能工程師，在 Medium 總結了他們的共同經驗以及晉級之路，供各位參考。文由 36 氪編譯，Inside 獲授權刊登。

成為高效能開發者這件事你可以透過經驗、書本、或者試驗和錯誤來學習。但成為高效能開發者的最有效方式之一是直接向高效能開發者學習。我訪談了 Facebook 的幾位最高產能的工程師，想找到這些開發者實現最高生產力的基礎結構是什麼。

第一級：減少不必要的干擾

這一點似乎很明顯，但是正是這些累積起來的小事情最影響我們的生產力。

避免開會

我盡量少開會。例會我一般都不參加。這條未必適合每一個人，因為經理喜歡安排例會，你也不想把經理給惹毛了，但我建議給他看看開會的成本：（10 工程師 x 30 分鐘）/ 周 +10 分鐘任務切換開支=浪費工程師半天時間 / 周，這可不是小數。我總是努力爭取用有議題的討論或者站立會議來代替例會——匿名

許多工程師都強調必要的時候會議是有用的。但是必須對開會保持批評性的眼光，不開不必要的會。

準備好做小任務

在生成或者修訂的時候我會迅速清理信箱保持收件箱為 0 —— Michael Novati

有時候在你完成手頭任務之後到開會之前會有 5 到 15 分鐘的間隔，或者你進行的試運行可能需要花費 1、5 或 15 分鐘的時間。對此通常的反應是「這種時間裡面做不了什麼大事的。」這種說法當然沒錯，許多任務可能都要花 30 分鐘到 1 小時的時間才能集中注意力，但並不是所有任務都這樣。許多工程師提到自己會做一份小任務清單，這樣在每天稍微閒暇的時間裡就能把那些事情處理掉。比如處理信件、diff¹評審，回覆內部訊息，或甚至可以進行小規模的 diff/ 重構，從而提高一天的工作效率。

戴上噪音消除耳機

如果你在成立時間不久的軟體公司待過，你就會注意到那裡的辦公區域設置是如何的空曠。對於工程師來說這是一把雙刃劍。一方面你跟團隊的距離可以更加靠近。團隊成員間的合作和友情可以一直保持很高水平，問問題很方便，跟同事關係也可以很融洽。不好的是你寶貴的專注度被環境噪音干擾了。當你正在思考棘手問題的時候，聲音很大的討論會贏影響到你的生產力。這時候噪音消除耳機就可以派上用場了。這種耳機的技術已經非常先進了，遠不止是在你的耳邊豎起一道屏障，調大耳機音量。真正的噪音消除耳機能夠排除環境噪音並且抑制周邊低沉的交談聲。跟 Michael Novati 談過以後我也買了一副他推薦的耳機，說實話要沒了它我都沒法幹活了。很顯然，戴上這樣一副耳機進行對比之後，你就會知道辦公室的環境噪音有多大。

在別人沒法干擾你的時候工作

（關於如何應對干擾）2年 前搬到紐約去可能對我的幫助很大 —— Adam Ernst

我通常把更困難更複雜的任務留到星期三（那時候我可以在家工作不受干擾）—— Bob Baldwin

實際上「正常」工作時間內我幹不了什麼事情，只有靠加班時間才能完成事情。—— 匿名

我通常在早上 6 點到 9 點間能夠幹的事情比一天其他時間能幹的都要多，長時間的不受打斷至關重要。—— 匿名

我得承認，跟這幫工程師聊的最大發現之一是他們當中許多都工作很長的時間。為什麼他們要幹那麼久呢？原因挺有趣的。因為只有在早上、深夜、周末這些時間才沒人打擾他們。透過尋找一天當中受打斷最小的時間，這些人得以推進自己的重大任務，把程式碼給弄出來。

減少煩人的信件 / 通知

我會關閉所有非緊急的信件提醒。只接受需要行動的信件，並強迫自己按照合理的頻率來檢查任務 / 信件頁，把其他東西當成垃圾信件實際上對我是有幫助的，我錯過的東西反而更少了。—— Ari Chivukula

每次收到新信件時都要停下來去看看的話，你一整天都會被各種干擾打斷了。透過減少和過濾通知到只保留必要的那些，你就能在不受干擾的情況下工作更久。

不要失去狀態

我被打斷（或者必須去洗澡）的時候會在腦中「保存狀態」，就像在 Gameboy 模擬器中保存狀態一樣，這樣回頭繼續的時候我就可以盡快恢復了。—— Michael Novati

永遠要在一項相當簡單或機械的任務中結束一天。這讓你第二天很容易就可以撿回來恢復工作狀態，而不是又要從頭開始。—— Adam Ernst

對於我來說，當我在認真思考問題時、被打斷時、忘記自己在想什麼時就會在寫程式方面會失去狀態，也就意味著我需要重新把整個思考過程再過一遍。

當你在工作狀態時遇到干擾最好的辦法之一是推遲干擾。如果你在全神貫注的時候被干擾，那就告訴那個人你稍後會處理，速記一下此事，然後繼續工作直到你到達合理的停止點。一旦到達停止點，馬上處理完堆積的那些事情。

如果干擾無法推遲，也有很多辦法可以「保持狀態」。比如寫下自己當前的思考過程，寫下失敗測試，或者簡化正在思考的問題。

第二級：寫出「更好」的 Diff

好程式碼意味著很多東西。好程式碼應該是功能性的，容易評審的，經得起時間考驗的，等等。

寫更小的 Diff

許多小的 diff 就像是在解決工程問題時「展示你的工作」—— 匿名

我訪談的每一位工程師都非常強調把程式碼變更拆分為邏輯模塊，這樣可以讓其他人更容易理解，更快接受。透過減少 diff 帶來的認知負荷，評審者對於接受變更會更有信心。此外，透過減少 diff 的規模，變更對於評審者來說也沒那麼令人望而生畏，這樣評審效率也會更高。

可以告訴你們的是，這篇文章問到的工程師都是過去 6 個月 Facebook 裡面提交 diff 最多的人。可能會有兩種風格的工程師群體，一群是提交很多小的 diff 的，一群是提交數量較少但規模較大的 diff。

堆疊 diff² 以及多任務處理

大多數工程師提到自己會將 diff 變更相互堆疊起來，逐步建立 diff 間的邏輯依賴：

有時候當我做了一個規模很大的 diff 時，我會回過頭把它拆分成一系列邏輯步驟，這樣我就能慢慢變更一些東西，然後程式碼的總體品質也會逐步得到改善。—— 匿名

我從來不堆疊 diff，相反，我會並行做幾樣獨立的事情，然後在等待評審的時候交替處理。把一項大的變更分解成獨立部分這種做法也很有效，比方說增加界面，增加端結點，把這些事情安插進待辦事宜裡面⋯⋯這樣可以把事情堆起來交替做，不用在 diff 之間產生嚴重依賴。對程式碼進行結構化，這樣就不必堆疊或者弄子分支出來，評審、交付、還原都容易一些。—— Michael Novati

如果我覺得自己在把多個 diff 放進一個 diff 的話，我會拿出來放到 stack 上形成相互依賴關係。—— 匿名

要做小的，至少是容易評審的 diff。這不僅是為了更容易更快地審核，也能讓我寫出更好的程式碼，因為我認為如果每次處理的東西邏輯分明的話，浪費的調試時間就非常少了。此外對堆疊 diff 的經驗可以可以讓小的 diff 可管理。—— Ari Chivukula

我大量使用堆疊 diff。這麼做除了讓我可以在等待程式碼評審時有事可做以外，把程式碼分解成更小的 diff 往往能讓我從宏觀上考慮自己在做什麼，甚至還能簡化架構。—— 匿名

無論工程師是使用堆疊 diff 還是進行 diff 的多任務處理，其生產力似乎都相當出色，這說明這兩種辦法對提高效率都很有效。

單元測試

測試規模要盡可能小，這樣我會感覺舒服一點。—— Michael Novati

大家對經過單元測試的程式碼更容易接受些。—— 匿名

單元測試這個東西在一些技術公司會引起爭議，大多數團隊和公司對於工程師要不要寫測試都有自己的指導意見。不過有一件事可以肯定，如果你所在的公司別人可以修改你寫的程式碼的話，確保某人不會搞砸你的程式碼的最好辦法是在測試中強制功能要求。

溝通

對於比較棘手的 diff，我會適當增加幾個評審人，把 diff 共享到合適的群裡面。不管有沒有動作，我每天都會 ping 一個 diff 出來。如果好幾天都沒有動作，我會問評審的對 diff 有什麼驚人的發現，然後對結構做出改變。最後我會盡可能跟對方多溝通。我總是以 「[產品 / 標簽]」作為標題開頭—這樣大家就能知道 diff 是做什麼的，如果我想盡快得到接受，我會寫上「[product-ASAP]」或者 「[product-PUSHBLOCKER]」之類的東西。—— Michael Novati

這一點似乎顯而易見，但是就 diff 評審進行溝通的方式有很多種。一般的經驗法則是按 diff 來進行。如果審核你的 diff 的人平時不怎麼跟你打交道的話，你可能要在描述和標題上面增加一些平時跟團隊成員溝通時不需要的上下文訊息。你還可以在需要別人重點審查的地方做批註，如果相關邏輯比較複雜的話。

在設計會議上就提出期望還可以簡化寫程式碼的過程，開發出好的 API 和架構等。

不要害怕提醒評審者注意你的 diff。如果他們不想審核你的 diff，他們可以退出或者建議其他人來做。如果讓 diff 一直留著待審查隊列，那無異於給將來埋下衝突。

第三級：具備團隊精神

寫程式是一項團隊運動，就像所有的團隊運動一樣，個人能實現的事情總是有限的。

評審他人的程式碼

快速掃描，通讀，打補丁，測試，評論。—— 匿名

多進行評審以便提高你的程式碼產量，這句話聽起來似乎有點矛盾。我們可以把「多做評審」解讀為「清理別人的隊列」。當你換個角度看問題時，情況就清楚多了，如果你清理了其他工程師的隊列，那別的工程師也就更有可能幫你清理掉你的隊列，替你解鎖。

與評審者 / 團隊成員建立信任

我有一個核心工程師小組，跟裡面的人維繫著良好的信任關係，我們會一起努力迅速評審對方的程式碼。—— 匿名

這一點跟上一點有點類似。如果你有一組核心的工程師，相互能夠信任對方能寫出好程式碼的話，你就可以相對安全地做出變更，因為哪怕某位工程師寫錯了東西，大家也會在出現問題時一起努力改好它。

對自己在做什麼要透明

進行新項目（greenfield development）開發時應該用 RFC（請求評論）diff。相對於在後面才改變方向，預先獲取 /header/ 提議 API 回饋所消耗的時間是值得的。—— Adam Ernst

如果大家不知道你在做什麼，因為評審 diff 時需要的訊息量不足會導致他們困惑。透過儘早把評審者 / 團隊成員納入圈子裡面，他們就能在一大塊工作完成前提供回饋，前進道路的路障也就被解除了。

提供好的反饋

專注於提供高品質的回饋而不是挑刺。如果你發現 bug 了就指出來，但是要相信工程師已經測試過（並且相信他們會改正任何發現的 bug）—— Bob Baldwin

先略讀了解概況，如果有什麼地方不清楚就批註一下或者提出改進建議。如果總體感覺良好，再細讀看看是否存在最佳實踐問題或者小細節問題，沒有的話留幾條註釋接受變更就行了。—— Ari Chivukula

「評審 diff 的策略是什麼」這個問題的常見回應是首先從高層視角理解待評審的 diff。在理解了 diff 的基本結構之後，再深入了解程式碼風格並進行邏輯檢查。

請求變更

要頻繁使用請求變更—最糟糕的事情莫過於他們重新請求評審（當然要鼓勵作者這麼做，如果對方認為你的請求變更是錯誤的話）—— Adam Ernst

如果我可以看出自己的問題，那就請求單元測試或者重構，這樣出問題的可能性會低一點。如果東西太大太複雜而且顯然沒人把心思放在這上面，那就請求他們結束評審，或者至少給出將來更好做法的建議。——匿名

在一些非標準事情上對 diff 提出請求變更可能會有點令人尷尬。但是從長遠看，鼓勵採取更好的寫程式碼做法和校驗是值得的，工程師以後會從錯誤中吸取教訓並作出改進中得到回報。

不知道要承認

如果我對程式碼庫的一部分不太清楚我會直接說然後跳過。
—— Michael Novati

不懂裝懂是裝不了多久的，如果要評審的東西你不懂就坦白告訴別人，然後讓對方去找別的更懂的工程師評審。

第四級：組織與推進

待辦事宜

我會把日程表裡面的個人事務先放到一邊，設置提醒稍後再辦。如果日程安排裡面不設提醒我會忘了。—— Michael Novati

大多數情況下，我問到的工程師每個人都會使用不同的任務跟蹤工具。同時要跟蹤管理的來源還包括紙、任務、信件、日程、清單、高級目標等。不過在確定接下來該幹什麼，在對任務、信件的組織和分類方面，許多工程師都有一個「層次化」機制。

快速失敗與迭代

我會盡量快速調整程式碼，哪怕自己不能確定那是（獲得註釋的）最優方案。對於想法的嘗試，我寧願快速失敗而不願先 100% 考慮清楚。—— Ari Chivukula

程式碼嚇不倒我，我可以很容易進入狀態 ，兵來將擋水來土掩。 —— Michael Novati

許多工程師（包括我自己在內）可能會隱瞞的一點是害怕失敗。馬上就要做出完美產品的想法是可怕的，會導致我們考慮太多的問題。要養成在不知道結果會怎樣的情況下馬上寫程式碼的習慣，這樣我們就可以更快地迭代，更快看到結果。

工作 / 生活平衡

有一位比你還要努力的（重要他者）是有幫助的，不然的話你就得自己扛了。我的做法是張弛有度，有時候我會衝刺一段時間，然後放鬆一下。大概是高強度 2 個月，然後放鬆 1 個月這樣子。在我看來，這要比 3 個月保持相同節奏更具高效率（不過這一點並不適合每個人），因為工作不是線性的。—— 匿名

「洗澡的時候考慮問題」這個比喻還是有點道理的。—— Adam Ernst

這些工程師的確幹活非常努力。為了完成大量的程式碼他們花費了很多的時間。儘管我沒有具體詢問工作 / 生活平衡的問題，但是他們當中很多人工作、生活是分得很清楚的，哪怕是「全力以赴」的工程師，這點挺讓我驚訝的。看起來這些人不僅可以高效率得工作，而且工作 / 生活平衡也能做得很好—如果願意的話。

零星想法

你希望別人怎樣待你，你就該怎樣去對待別人。你得成為別人希望共事的那種工程師，而這大部分是透過回饋來了解的。要早點問，經常問，被問到的人會感覺自己受重視。—— Ari Chivukula

經過這些訪談後，我感覺自己的開發進程正在一點一點地發生演變（同事要很努力才能引起我的注意，因為我現在戴上去噪音耳機了）。拆分 diff，請求評審，待辦事宜清單，這些東西我之前也做，但現在我知道如何更有效地利用這些工具了。說實話，採取了上面的做法之後，我的效率提高了不少。

This posting includes an audio/video/photo media file: Download Now

photo credit:Sylvain Kalache

有什麼事情是可以在公司股價暴跌 44% 之後，讓員工如此振奮？

LinkedIn 在週三向美國證券交易委員會的文件中，概述了他們針對公司高層所提出的薪酬組合，而當中並沒有執行長 Jeff Weiner 的名字。對此 LinkedIn 發言人的說法是，Jeff 告訴美國證券交易委員會，他打算放棄年度股權授與，並將之讓給員工。

據 Re/code 從相關消息人士所得到的消息，Jeff Weiner 所放棄的股票價值粗估約 1.4 億，而去年 Jeff Weiner 所獲得的股票則約莫價值 1.3 億。由此看來，Jeff Weiner 是真的有意安撫員工們的情緒，而由他放棄股票並讓給員工，也的確是相當實際的一招。

當然，Jeff Weiner 也不是唯一一個這麼做的人，早在去年十月，Twitter 在大規模裁員之後，執行長 Jack Dorsey 就曾自掏價值 2 億美元股票（約 65 億台幣）發給員工，藉此修復自己和員工之間的關係。

This posting includes an audio/video/photo media file: Download Now

Slack 昨天才對外預告很快推出語音聊天功能，今天就馬上在桌機和 Chrome 瀏覽器上推出「通話（Calls）」功能。

這項功能可以進行私人通話，也可以在任一頻道中，發起電話會議對談。不僅如此，為了保持 Slack 輕鬆活潑的企業風格，使用者都能在通話過程，向另一方發送表情符號。而目前這項功能僅開放給不到 50% 的用戶使用。

正如先前所提，Slack 其實早就整合了像是 Skype、Google Hangouts、Zoom、Bluejeans 等 App 的通話功能，但這些都必須另外安裝，效率仍舊比不上能直接在 Slack 中打電話。至於視訊聊天功能，Slack 也正在努力籌劃推出中。

Slack 產品副總裁 April Underwood 對於新功能的推出表示，我們的任務就是要讓人們在工作的過程，簡單、愉悅並且充滿效率。而語音電話對於一個團隊來說，一直是很寶貴的溝通形式，這也是為什麼我們早就透過和第三方 App 的合作提供用戶在工作中能夠進行通話的這項選擇。而對於那些早就在使用 Skype 等其他通話工具的用戶來說，這項新功能可能僅是一個新的通話選項，但對於那些需要更簡單的通話解決方案用戶來說，這將是一個很實用的功能。她說，Slack 歡迎大家提供他們在測試新功能之後的心得感想，而他們也希望能儘速在 App 上推出這項通話功能。

以平台為核心發展一直是我們的 DNA，而我們正積極探索整合各種第三方服務，像是電話語音這樣的功能，使其更深層的融入我們的產品當中，

This posting includes an audio/video/photo media file: Download Now

線上民調公司 SurveyMonkey 週二發出通知，公司計畫遣散 100 人，以利公司進行產品改革。這波裁員訊息在其公司內部會議上發布，裁員比例約佔公司 750 人的 13%，受影響的單位主要以銷售部門為主。

不僅如此，該公司更在上週聘請了兩位新的主管，包括負責產品業務的資深副總 Steve Norall 和負責全球業務的資深副總 Brad O’Neill。這兩人此前曾共同創辦自動化內容行銷公司 TechValidate，並在 2015 年八月被 SurveyMonkey 收購。

自從去年七月春天，SurveyMonkey 就經歷過許多高層的轉換，Zander Lurie 是在今年一月正式接任執行長的，而其在此之前的幾個月，他曾擔任過公司的董事會主席，以及因應原執行長 Dave Goldberg 於 2015 年五月突然離世的噩耗而暫代執行長。

詳細有關公司為什麼需要裁員並進行產品改革的細節，外界不得而知，但這很有可能與公司早前致力於上市的野心有關。而當時的計畫正因爲 Goldberg 的離世被暫時擱置，這也是為什麼如果 SurveyMonkey 打算重新進行公開募股（IPO），Fortune 表示沒什麼好驚訝的。

據 Lurie 向媒體 Re/code 所透露，SurveyMonkey 有望在 2016 年迅速取得 2 億的收入。他說，當你有一個像我們一樣的體質健全的公司，你就必須在進入新的業務時設立出高標準，並且在你沒有達到該有的結果時，能夠做出策略性判斷。而當前的產品和解決方案並不能真的為 SurveyMonkey 創造長期價值，對於公司，我們有更遠大的理想，為此我們打算重新整頓公司。

歡迎加入「Inside」 Line 官方帳號，關注最新創業、科技、網路、工作訊息

This posting includes an audio/video/photo media file: Download Now