Venders，外包測試團隊。我們有大約六七個人的外包測試團隊（on-site），主要負責我們主要產品的人工驗收測試。我們對外包測試團隊的工作方式也有一個設想，就是一個項目剛開始的時候，外包測試團隊應當是先上很多人，然后隨著 SED 的介入，讓自動化程度加強，慢慢人少下來，直到下一個新項目開始。但這個設想在國內想實現，卻沒那么容易，主要有幾個原因：1）國內的外包測試的工程師，通常是技術和經驗都比較初級的人來做，外包測試成了一個門檻低天花板也低的行業，技術和經驗缺乏，導致進入新項目以后沒辦法非常快的上手，而有經驗有能力的人，很快就會脫離外包行業；2）外包測試的公司，人才儲備不足，很少有人力資源池，都是有需求，現從市場上招，或從競爭對手那里挖，有的人都沒見過，就派到客戶那邊來面試，這也導致了沒辦法幾個月就撤下來，因為他沒辦法跟候選人簽合同。這兩個客觀原因，我們也比較無奈，所以我們的外包測試團隊基本上還是長期 on-site。
UOE，user operation engineer。用戶運營工程師，這個崗位很多人不太容易理解，一般用戶運營人員都是跟內容啊、用戶打交道的，就像貼吧管理員就是典型的用戶運營人員，那為什么要有個運營工程師呢？這個我們是跟硅谷的 Dropbox 學習的。因為在日常工作中，我們發現有想當一部分用戶的反饋，不論是新功能的需求還是缺陷，都是技術性很強的，如果你能做到第一時間和用戶做深入的，技術含量較高的溝通，從解決問題的成功率上會高很多，而如果你反饋一個技術問題，總是過了幾天才有技術人員跟你聯系的話，你可能配合排查問題的愿望會小很多。基于這個思路，我們增加了這個角色，同時他們還負責一些運營過程中使用的工具和平臺類的研發。可能會有人問這個角色為什么會在 EP 團隊？其實仔細分析一下用戶運營的工作，會發現他們處理的對象是一個個用戶提交的 ticket，這非常像 test case，不同之處是一個是用戶事后提交，一個是事先設計，分別保證了優先級和完備性，因此結合起來，對提高質量是非常有益的事情。
EP 團隊的工作方式與面臨的挑戰
上面這幾個角色，就組成了我們的 EP 團隊，這樣的一個團隊，這樣的一個能力構成，就有了一些鮮明的特點，例如：
1）沒人管的事情我們管，支持所有團隊。公司內部雖然分成了很多個團隊，但是很多技術問題是找不到人負責的，例如，一個簡單的內部數據統計腳本，或者一個發布內容到 CDN 的 CMS，等等。這些事情基本都會由 EP 團隊接過來。
2）做事情沒有計劃。這個特點可能很多人會覺得匪夷所思，甚至不能接受，但實際上這跟 EP 團隊的工作有關系，比如汽車 4S 店，有多少車禍的汽車要修理，多少人為損壞的車要修理，怎么做計劃？實際上是遇山開道、遇水搭橋。外部的市場的變化、內部的技術人員的變化，都會有不斷的瓶頸出現，而 EP 就要快速發現并解決這些瓶頸，直到發現下一個瓶頸，這個過程沒辦法有詳盡的長期的計劃。而替代的是使用目標管理的方式，我們公司內部所有團隊都會用一種叫做 OKR（Objective and Key Result）的方式來做管理，簡單的說，就是設定目標，然后評估完成度。EP 團隊的目標大致有兩個方向，一個我們叫做 「Smoothly & Fast」，就是讓一切跑通做順的能力，還有一個就是「實現自助」，能讓其他團隊的成員，不管是技術還是非技術背景，都能自己通過我們的工具完成任務。
這些特點看起來很不錯，但是實際上帶來的問題也非常多，例如：
沒有成就感。因為所有人都是你的需求方，這個感覺實在是不太好，另一個角度講，很多研發工程師會覺得開發一個對外的產品比較有成就感，對內的總覺得沒意思。這個問題要解決，其實就要靠所謂的「工程師文化」來解決，國內長期以來在職業化上有一些不好的習慣，其實能發明工具的人都是大師，開發語言就是工具，操作系統也是工具，真正的牛人，都在做各式各樣的工具。能幫助別人成功的人，是最成功的。
還有，就是脫離實際。很多人做工具，怎么炫怎么做，流行什么做什么，要么就大而全，這還是好的，更多的時候是想的大而全，半年做不出來。整個公司的價值取向是一致的，特別是小公司，容不得這種炫技一般的工作方式。所以我有一句話，叫做「自 high 無價值」，什么叫「自 high」？就是自己跟自己玩，玩的很高興。
還有一個問題，就是招聘困難。這個在 SED 的工作職責部分提過，就不展開了。因為招聘困難，我們就要考慮怎么培養這樣的人才，所以我們有一個方法論，叫做「要改進，先體驗」，因為很多 EP 的成員是要改進工作過程的，但是怎么改，不是所有人都能搞定，這依賴于大量的經驗積累，對經驗不足的人，很簡單，就是讓他去做。要提高研發效率，找到痛點，那就先去做一個月研發；要去改進測試過程，提高效率，就去做一個月測試。一個技術和思維方式都很不錯，只是經驗少的人，經過一個月的體驗，能提出非常多的、而其他人已經麻木了的改進點，并推動實施。
再有，依賴整個團隊的成熟度。不是說有了 EP 這樣一個團隊，整個公司的效率和工作模式就會有大幅度提升，因為一個汽車再好，你開的方向不對，也到不了目的地。現實中存在著非常多缺乏責任感的 Owner，很多人覺得，我寫完代碼編譯通過了，丟給測試組就行了，沒我的事了，這樣的想法大有人在，所以從成立 EP 團隊，到整個公司的生產力真正被提高，中間不只是提供工具這么簡單，還有一系列的指導和訓練的工作。
Why we can & why you can
最后，關于我們為什么能做這個事情，我們也有一些總結：
1）創業團隊。創業團隊就是短小精悍，精力集中，沒有太多無謂的紛擾，快速交付產品快速迭代是主要的工作方式。
2）從第一天開始堅持自由和責任的工程文化。從創始人開始，很堅持這種工程文化，有什么樣的 leader 就有什么樣的團隊，所以大家接收和擁抱 EP 的工作模式，也非常快。
雖然上述這兩條很多公司沒有，但不代表做不成這個事情，在我看來，只要具備下面幾條，想做成 EP 的工作，就并不難。
1）互聯網行業。互聯網行業有一個非常好的，區別于以往其他行業的特點，就是你的產品在物理上是自己控制的，提供的只是服務，這非常有利于快速迭代，因為傳統行業不可能做到。
2）快速變化的業務模式。這不是說我們自己要快速變化，而是業務模式和市場不斷變化，來推著我們前進。只有業務模式的快速發展，才對生產力有不斷更高的要求。
3）有改變的決心。這個說起來有點虛了，但也很重要，因為 EP 這樣的工作模式會有陣痛，例如團隊的重組、轉型，都會影響到一部分人的利益，特別是團隊的管理者，而這些中高層管理者，也確實有能力阻止變革。但坦白的說，很多時候你不主動改變，到了客觀環境推動你不得不變的時候，到最后就成了被淘汰的人了。我還有一句話，叫做「組織結構決定工作模式」，意思是說，很多工作模式的出現，是因為組織結構的需要。反過來說，在你的組織里很多很好的工作模式推動不下去，或者效果很差，你就要看看你的組織結構是不是有問題。比如兩個本來應該緊密合作的團隊，一直合作不好，互相鄙視，你想簡化流程，最后流程越做越多，大家都在壘墻，那你就要看看兩個團隊共同的老板，是不是級別太高了。
4）對團隊成員的高標準。前面我提過，我們 EP 團隊的大部分是 Geek 型的人，Geek 這個詞在英語里是一種很高的評價。只有一個技術和經驗都非常豐富的人，才能勝任 EP 這樣的工作，所以要堅持不懈的雇傭一流的人才，人不夠，可以抓大放小，但絕不能有二流、三流的人在團隊里。