像 FEX 這樣的純技術研發團隊是如何在內部推進的？

01-04

這裡有一篇有關 FEX 的採訪 http://itindex.net/detail/52118-%E7%99%BE%E5%BA%A6-fex-%E5%88%98%E5%B9%B3 。可以窺見 FEX 這樣的技術團隊在公司內部很容易遇到的一些困難與阻力：
作為直接以技術研發作為產出的團隊。需要大量參與公司內的技術規劃、方向，也會直接負責大量基礎設施/框架的建設，比如資源打包優化、全流程優化、數據監控、技術選型、複雜應用的技術方案等等。
這類團隊建立的初衷是為了彌補業務團隊忙於業務而沒有精力進行技術建設的問題，讓一批人安靜的做好技術，長遠來看解決公司的技術發展與瓶頸。

但同時，這類技術團隊與垂直的業務開發團隊平行，並沒有上下級關係。要將技術產出推進給業務團隊，該如何做？在內部開會？在內部開源？
就算有上級和同級的支持、有公開的反饋與 Review 機制；做「標準化」、「統一」、「抽象通用工具」這類事件，都很容易受到業務部門的質疑，都很容易受到阻力。

作為 fex 現成員，以及某還算推進得成功的技術產品（因為對外版還在小範圍公測，就先不透露產品名字了，至於要不要大範圍開放，目前我們內部還有些沒達成共識的地方）的核心成員，update 一下現狀。

產品現狀是內部有一百多個部門在使用，也對接了一些外部用戶，開發周期從今年二月至今。我個人目前的角色可以說是研發+產品經理+客服+培訓師+運營+UI設計師（偽）的結合體。

純技術團隊最大的毛病，大抵是不接地氣以及愛炫技，並且瞧不起結果導向的思維。

許多失敗產品的核心原因就是沒有以目標用戶的需求為導向。見過很多沒有推出去的產品，基本都是搞一堆感動了自己的複雜東西，而目標用戶感覺這玩意並沒有什麼卵用。

所以技術產品要成功，第一步應當是確定好你要解決什麼問題，為此甚至需要經歷一段時間的「外包」階段。

我們項目早期的需求提取，基本就是靠我們幾個人加班加點給業務團隊切頁面確定下來的，時間跨度為去年七月到今年春節前。而那一階段我們向老大們體現出來的價值，就是「我們能做到別人做不到的效果」。

第二步，既然沒有產品經理，那自己就來成為產品經理。在這一點上，現老大 @吳多益是大神不解釋。他做另一個產品的時候僅僅花一天時間就完成了20餘個類似產品的競品調研。

而我自己在項目發展的初期至今，也承擔了繪製原型、項目結構拆分等一系列工作。

很多人覺得這種事就應該產品經理來做，但事實上作為一個純技術團隊，是很難找到合適的產品經理的，因為產品本身的門檻就在那，一個完全沒有技術背景的產品經理，甚至連理清需求都會很吃力。

在這一點上，我並不是所謂全棧工程師理論的擁護者，認為自己能夠大包大攬一個項目的所有職責。但既然我們的目標是項目成功，那麼任何可能導致不成功的因素，都應該由自己來排除，或者在自身無法排除的情況下，儘可能獲取來自外部的幫助，而不是整天在那嚷嚷我們項目半死不活都是因為沒有產品經理（事實上真有了產品經理，又該開始罵產品經理是傻逼了）。

至於怎麼獲取外部幫助，只能說是根據現狀，各憑本事。

我們一般的做法是用技術換取資源，以及在這個過程中反刺激產品本身的發展。例如某個產品線的需求和我們的平台功能恰好有70%的吻合，但是由於各種原因他們排不到fe資源。我們就會直接把這個活接過來，並用基於我們平台產出結果二次開發的方式來實現。在幫其他部門解決了問題的同時也提煉出了我們自己的需求。而這個過程其實也包含了推廣的意義，產品線基於這些合作會知道我們平台的存在及功能，當他們可能需要的只是另外現有的那70%的時候，他們就可以脫離我們的幫助，自行用平台功能解決問題。

這個模式至今為止還是很成功的。去年年底基本就靠這個解決了組內成員的伙食問題（因為幫運營們解決了需求，所以基本每周都會有人請吃飯）（≧?≦）。而且現在運營們每當有運營資源活動的時候都會很體貼地地問一句要不要幫我們一起宣傳Y(^_^)Y全方位解決了沒有推廣資源的問題。

在確定需求的過程中，作為技術團隊的大忌是炫技心態太重。見過一些技術產品，裡面的很多功能純粹是開發者迫不及待地要把自己掌握的技巧堆到產品中，並試圖得到目標用戶的認同。

在這個點上，個人建議是心態放寬，眼界開拓。很多人急於炫技都是出於「這個一定會讓別人大吃一驚」的心態，而事實上，自己費盡心思造的，覺得很棒的輪子往往可能是早就被人驗證過不可行的方案，或者是一些根本無法產生二次價值的奇技淫巧。換言之，你掌握的某些技巧或者腦洞大開覺得絕妙的某些主意，其實並沒有你自己想像中那麼稀奇。

當然許多技術人員會標榜這就是geek精神和情懷，包括我自己早期也是這樣。然而現在我只能說，比起你的情懷，還是保證項目不掛比較重要。

因為項目是大家協作的成果而不是任何一個人私有的東西，掛了意味著你是在用隊友的努力為你一個人的所謂情懷買單，這對其他人來說，是不公平的。並且只有項目生存下去，才能帶給大家更大的發揮空間。不然作為一個技術團隊，就會陷入「一直在做demo」的尷尬狀態。

比起「我要設計一個就算上億流量也不會掛掉的架構」，還是先思考「這個產品怎麼才能做到有上億流量」比較現實呢。

目前手頭的項目還算成功，基本上要歸功於早期的發展思路是完完全全是為了解決各產品線痛點，而不是為了做個很厲害的東西刷 kpi 這種目的。

設計師資源的短缺是純技術團隊的一個比較常見問題。我們團隊的解決方法是由土豪@吳多益老大花一百多美金從國外的模板站上買了幾個全站模板，然後我們自己修修改改作為第一期的外觀上線了。當然後續也拜託了長期合作的設計師團隊來為我們重新設計（用技術換資源的一個例子，因為那個設計師團隊期望的效果目前來說只有我們能夠實現並且願意承擔，這也是橫向部門的一個好處，就是可以自由選擇和不同的部門擦出不同的火花，而不用過度局限於本部門的業務），這是後話。

----12.23更新----

總的來說，技術發展的路線在於將一些本來需要人力，定製化的東西抽象出來通過程序和機器解決。而具體哪些東西可抽象，抽象到什麼程度，如何在生產效率和靈活性之間獲得均衡，正是技術團隊體現價值的所在。

一個通用工具最終能做到什麼程度，能解決多少人的問題，基本取決於技術團隊本身在產品設計和實現方面的素養。

同時，在產品到達「能夠解決部分問題」的階段時，用戶也會提出許多希望能夠支持的功能以及在使用過程中覺得期望改進的點。藉助這些反饋，基本可以確定下一階段就產品功能本身需要有哪些改進。

在發展用戶（也就是產品推廣）的過程中，應當做的是放下技術人員的傲氣，儘可能以良好的態度和非技術的同事們進行溝通。不可否認，的確是會有一些不太靠譜的人令合作過程相當不愉快，但是一個產品成功的標誌，正是令不靠譜的人也可以藉助這個產品靠譜地完成工作。在指責別人什麼都不懂之前，應當首先反思一下是否自己的產品並沒有達到「可用」和「易用」的程度。

----2016.3.27 更新----

感謝廠內外群眾捧場，經過一年多的耕耘，上面提到的「技術產品」百度 H5 現在開始正式對外開放使用，目前採取郵件申請開通許可權的公測階段，有需要的用戶請發送一封郵件到 h5@baidu.com 提供百度賬號昵稱和個人簡介，即可開通使用許可權。

附上早期用戶的兩篇精彩測評：

百度推H5設計工具：支持一鍵導入psd

一個Geek范的H5頁面製作工具 - 以德服人 - 知乎專欄

未來我們會更加努力地服務群眾^_^

----2016.5.20 更新----

產品已經於4.12正式對外，直接用百度賬號登錄完善個人信息就可以使用了，不用郵件開通 ^_^ 最近一段時間都在糾結圖表組件的開發，請期待下一次的更新。

謝謝關心，是個好問題，之前那樣確實有些問題，做過不少沒有落地的東西，今年 FEX 已經轉型了，不再只是提供技術支持的了，很大精力花在了自己的產品上面，有的產品已經開始獨立對外了，後續還會有更多，它們將能直接創造價值。

之前能推廣好在我看來有兩個重要原因：

* 最開始百度 FE 是一個大部門，大家相互了解和信任，有統一的 leader

* 很多事情我們做得非常早，類似 FIS 的自動化工具在 07 年就有雛形了，性能監控平台也是很早就做了，時間點很重要

1. 做對部門/公司有用的事情，能換到一些做技術理想的時間和空間。

2. 靜心做到最好。別人沒有義務為你捧場，做得足夠好才會有人用。

3. 很多純技術團隊其實是被高傲和裝逼自己作死的，擺正心態，做好服務。

結合題目先回答我在時重要的 3 點。

1. 技術產品市場化。FEX 以公司運作，其它部門是企業，做 To B 服務。

2. 技術方向的決定每半年一次規劃，每季度 Review 結果。總負責人大方向，各方向負責人拆解。目標除技術的之外還有新產品研發能力，技術落地及技術維護成本幾方面考量。每周例會看問題，以及各種技術討論。

3. 除上級壓力外，技術上價值 KPI 很難完全量化，但有的數還是能算的，節省人力和帶寬等。

以下補充一些細節。

我認為機制是團隊協作的「一般標準」，所以我比較重視機制，像代碼，周報，招聘，規劃，OKR 都有相應的機制。

說規劃與 Review，難在哪裡，難在「系統」的想清楚，有系統規劃和沒有系統規劃差距很遠。題主也說到如果你做得與業務線一致，業務線的工程師必然不樂意；如果你做得不好，就不用；如果開源已有，你再做也很容易引起造輪子的聲音。所以規劃技術與做新技術的 MVP 等機制與習慣就很重要。

提下怎麼做技術規劃.

簡單的說需要有全景圖（技術方向的功能樹、架構圖），考慮行業競品，公司內的情況，現有技術業務的問題總結抽象，你從哪個技術切入，用什麼技術方案，從哪個業務落地，如何設計最小的技術方案，需要什麼人，哪些資源，各階段的目標，有什麼風險等需要考慮清楚，再拆分成項目。

原先習慣做業務的工程師都不喜歡這麼干，因為動手之前需要系統全面的思考。內部有《如何做技術規劃》這樣高工培訓課，還有類似於技術的精益畫布類的問題，只有自己把這些問題想清楚了，才開新的方向。

14 年初（年底白色的已經做完）還已經孵化出「數說」。

團隊如何運作.

整體協作過程沒有純管理，但有決策的委員會。我與另兩名高工，其中一名我和他一同協作重點在招聘育人方向（同時他也負責一個子方向），另一名主要與我協作把關 4 個大方向。除此之外整個技術劃分成 4 個大方向分別進行開發。

技術如何落地業務.

一般來說，一個技術產品的生命周期為「孵化技術產品想法」、「技術研發」、「技術落地」、「技術成熟」、「技術維護」、「技術衰減」幾個階段。

孵化技術產品想法需要經過一個問答模板。於是需要規劃，然後是研發了最小 MVP 版本，落地採用以下方案：

1. 確定我們的目標與落地業務合作目標。定義它是最重要而且最難的一點，是體驗還是成本還是提高開發效率。

2. 輸出方式，根據不同項目採取不同的方式，一般來看有 3 種。

a）新產品先產出原型，然後落地到最適合的業務成熟再擴大。
b）邀請產品線同學參與到我們某技術方向的開發當中。
c）我們參與到產品線里參與開發，直到項目結束交接完畢。

3. 交割看成果是否滿足預期。

幾個例子，FIS 最早版本有眾多業務線工程師參與開發；WebUploader 就是工程師直接去相冊業務開發直接落地，然後回來之後花時間再優化；數說就是我認為移動可視化是趨勢，在一開始沒人願意做的時候，有一位同學一直在這個方向做了半年，後來一直等到百度 Q2 移動數據報告之後才爆發，相當不易；腦圖就是一位同學（圖形和富應用方向）平常先做原型，後來逐漸迭代產物；安全方面是那位同學調整了三次方向後做了 XSS 監控落地於貼吧查到有人釣魚專釣版主，加之博客上十幾萬的 pv 之後才定心轉安全方向了；做 UEditor 的工程師一做就是三年...

一些很多人不知道的項目在此就不述了，總之有各方向有產出壓力，但產出的項目相當多，Github 里除了能看到的，還有 private 項目。

技術成熟之後，下一階段（一般是下一季度）進行推廣，有相應宣傳會，開源，博客等一些手段（行業會議中較少參加，最全的一次是 w3ctech 走進百度，做了 WebUploader/性能系統/靜態資源打包幾個 Session），也會結合業務線實際問題開發出一些相應的解決方案；在技術維護後期中主要的目標則是將原有開發人力遞減，將人力放到新技術上。

另外，只要是落地業務一般都會涉及臟活累活，也要寫業務代碼，甚至後期「客服」工作，很正常。需要注意的是要以業務目標為核心，而不是以技術目標的抽象為目的。

問題里提到開源，也是有邏輯的。

我也經歷過業務團隊，所以有點感受就是一個業務團隊搭建成熟可能可以很快，也許一年就可以出成果；但是一個基礎團隊的搭建和成熟需要長年累月的沉澱才有所斬獲，一旦基礎團隊好，你會發現「技術問題在團隊里不是問題」，只是解決技術要解決哪些問題域和用何種方式解決的選擇。問題域的大小來自於業務的規模與複雜程度。

我想這也是為什麼 FLAG 公司產出很多優秀技術的原因之一。

其他的公眾號之前已寫，就不多說了：

FEX 技術演變（一）
FEX 技術演變（二）

從群眾中來，到群眾中去，毛爺爺的教誨對基礎技術團隊特別合適

不相關的。。。fex也有績效考核，也為自己的解決方案能否被其他部門使用而腦殼痛呢。

讓一批人安靜的做好技術，長遠來看解決公司的技術發展與瓶頸

其實沒有做到這一點。

相對於核心業務部門，晉陞資源是沒法比的，公司也未必就傾向於搞一個脫離產品線的純技術部門（除非是像IDL那種高精尖的）。

也會有很多項目是做出來拚死安利也沒人用的，所以很多人反而更願意接需求，至少產出是固定能落地的，不至於在年終總結的時候面對「我做的東西很牛逼，但是別人都傻逼，不識貨，沒人用」的情況。

象牙塔而已。

然而Ueditor團隊已經解散很久了~~

技術到盈利還是有很遠的距離的~