生鮮 B2B 如何搭建高效的技術團隊（B2B 技術共享第四篇）

最近不少人找咱們取經，很好奇咱們爲何用了這麼少的人，能夠開發出這麼多、這麼複雜的交易平臺，咱們如今產品技術部一共35我的，可是開發了：7 個 APP + 1 個運營支撐平臺 + 1 個數據分析平臺，咱們從不追求人海戰術，咱們甚至都沒有測試工程師，那咱們是如何搭建這樣一個高效開發的團隊的呢？

搭建技術團隊以前，咱們要清楚B2B業務對於技術團隊的要求是什麼？B2B業務有本身的特徵，團隊要求和其餘業務不同：B2B業務和產品有如下一些特徵：

一、B2B業務不一樣ToC的業務，瞬間成交量不會太大，因此B2B業務對於技術的挑戰不是高併發，而是業務複雜度高；

二、B2B業務更強調貨品的性價比和服務，在大規模鋪開以前，產品端不用追求極致的用戶體驗，甚至能容忍偶爾有些小bug；

三、B2B業務中，客戶產生衝動購買的慾望並不強，客戶只是根據本身的生意規模進行下單，不用向淘寶同樣花裏胡哨的產品介紹，下單要儘可能簡潔；

四、B2B業務打法變更很是快，必定要快速迭代，要求技術人員開發的效率很是高；

OK，以上四個特徵，是咱們這個業務的特徵，咱們在組建團隊是，自然就和一些ToC的團隊不太同樣，通常一個產品技術部所須要的四我的數最多的小組分別是：UED、產品經理、技術開發（包括前端、服務端、數據庫開發等）、測試人員；下面分別從這幾個角色看看須要什麼樣的能力的人才：

對於產品經理，根據上面咱們總結的業務特徵，產品經理具備如下幾個能力很是重要：

一、產品經理具有較強的邏輯思惟能力，由於B2B業務複雜度高，好比整個交易環節，從註冊、到商品發佈、訂價、支付、下單、採購、物流運輸、提貨、售後服務，整個業務流程很是長，裏面涉及到的流程和狀態不少，若是邏輯思惟能力不強可能會理不清楚，也不可能把產品的流程和邏輯弄清楚，這樣對後面的產品開發簡直就是災難；

二、產品經理須要很強的同理心，對於交易平臺，角色衆多，好比生鮮從業者年齡偏大，對於手機操做不是很順暢，就須要理解這羣用戶的操做習慣；再好比作CRM系統的產品經理，若是不瞭解銷售的工做環境和心理特徵，只會坐在辦公室裏面YY產品，確定也是作不出好的CRM產品；

三、產品經理須要很強的溝通協調能力，好比在B2B交易平臺中，無論是內部仍是外部產品，會涉及到不少的交易規則，須要和各方去溝通，平衡各方面的利益，若是是一個孤僻的產品經理，很難作好B端的產品；

四、產品經理須要較強的平臺化建設能力，B端的業務部門更多的精力在業務指標上，業務指標每每比較短暫，不會很長遠，這時候就須要產品經理思考的更遠，不能只接業務方眼前的需求，要思考平臺化的將來，思考咱們沉澱什麼樣的數據，思考咱們將來要長出什麼樣的平臺，併爲之作準備；

對於技術開發，通常是一個產品技術部人數最多的小組，再細分的話，裏面人數最多的是服務端和前端開發，B2B業務服務端開發人員須要具有的能力是：

一、須要較強的架構能力，這裏的架構指的是業務架構能力，上面講到，B端業務高併發狀況並很少，難度在於業務複雜，資深服務端人員須要把業務模型、業務實體之間的關係梳理的很清楚，在ToB的業務中，業務架構師的比純技術架構師的要吃香，好比能快速理解業務，又能快速搭建技術架構，還能快速實現的技術人員在每一家B2B公司都很是稀缺；

二、須要具有除編碼能力以外的數據庫管理、運維、項目管理等綜合能力，因爲是初創公司，崗位不可能齊全，這就要求程序員不只僅侷限於編碼，從系統分析、到編碼、數據庫管理、運維甚至測試，都是由開發人員完成，特別是初創公司，開發人員是萬能的，這樣也是開發效率最高的，咱們一個產品從需求分析開發，基本兩週就要發佈，要求開發人員快速響應。

三、B端開發追求開發效率，須要開發人員具有紮實的技術功底和開闊的眼界，服務端通過十幾年的積累，各類中間件、開發工具相對於來講趨於成熟，技術功底紮實、眼界開闊，能夠對各類中間件、工具使用起來遊刃有餘，能夠大大提高開發效率；

同理，對於前端開發人員，因爲前端技術的特徵，咱們總結爲如下四個能力：

一、須要較強的學習能力，前端這些年飛速發展，不斷有新的解決方案涌現，不管是 Node.js 社區豐富成熟的框架庫，仍是 ReactNative 跨系統開發 App 的能力，提升前端數據接入效率的 GraphQL，包括新的產品形態下的端場景，好比微信小程序/公衆號，凡是提升效率的手段，在 toB 的業務場景下都須要積極研究，謹慎落地，這就須要前端有快速適應的能力，以開放的心態擁抱社區的優秀方案。

二、須要較強的項目合做能力，生鮮 B2B 的流通路徑，鏈路很是長，每一個節點上都能長出產品，這些產品背後有着全新的業務概念，而這 7 款 App，不一樣的前端工程師均可能參與，參與時候所合做的業務方/產品/設計/服務端也都不一樣，須要前端跟合做方有效率的溝通，快速消化理解產品的交互形態和背後的業務路徑，才能在項目中有效的發現和推動出現的問題。

三、跨端編程和體驗優化能力，不一樣的端意味着不一樣的物理設備和使用場景，也意味着不一樣的用戶人羣，好比 PC 端跟 App 不一樣，iOS/Android App 跟微信小程序又不一樣，它們背後的技術棧也有差別，宿主環境、佈局原理、系統規範、接口能力也都不一樣，這就須要前端對不一樣的端都有理解，不只在編程技巧、工程健壯性、跨端組件複用上面有較好的實踐，同時對於用戶真實的端交互方式和使用體驗有更加準確的判斷，前端是在用戶體驗上最接近用戶的羣體，由於前端的工做就是用代碼來輸出體驗。

四、創造性的工程基建能力，儘管在工程保障和線上運行穩定性上面，社區工具也不斷推陳出新，但新輪子疊舊輪子，並無系統化的方案，尤爲是小菜主技術棧是 2015 年才面世的 ReactNative，甚至是小程序，在這方面更爲匱乏，這就須要前端工程師利用 Node.js 這個順手工具來在團隊內外，業務流上下，快速研發貼合 toB 工程場景的工具系統，保障前端的研發效率和線上產品體驗。

當咱們把這些核心角色所需具有的核心能力梳理出來後，就開始找人了，對於初創公司來講，找人是很是很是難的，一般幾種方式：

一、殺熟，第一批技術人員，大可能是經過本身以往工做經驗或者圈子找的，由於剛開始公司啥都沒有，只有彼此的信任，把你身邊的人先捋一遍吧，咱們第一批產品技術人員，大都是「殺熟」來的；

二、利用我的影響力招聘，做爲產品技術部的負責人，在外面須要具有必定的影響力，多去參加些活動多寫寫文章擴大影響力，對招聘頗有幫助；

三、推薦，利用身邊一切資源幫你推薦人才，無論是作運營作市場的朋友，在他們身邊也許就有你想要的人才。

四、外招，早期比較難，公司名氣小，甚至不少人都不來面試，或者說好來面試的都會放你鴿子，這很正常，第一年咱們甚至遇到了一個工程師來上了半天班就偷偷溜走的狀況（由於第一天來正好公司公司的站立會，CEO嚇唬了一下你們），但人一旦來面試了，若是感受人不錯，面試工做就變成了「偵探+BD」，一個優秀的工程師，手上有四、5個offer很正常，在面試的後半段，就要開展你的BD工做了，講行業、講團隊、講公司前景，這將成爲他選擇的關鍵因素之一，一個好的面試官也是一個好銷售；

萬事開頭難，一旦公司慢慢運轉起來了，公司名氣也有了，行業地位也慢慢創建起來了，到了這個階段，能夠加大公司的PR和技術的PR，組織行業會議，創建技術的影響力，招聘相對來講就會容易一些了，各路大俠會慢慢向你靠攏。

關於如何搭建高效率的生鮮B2B平臺，由於包含的內容較多，也很複雜，沒法再一篇文章中給你們講清楚，本篇文章只是拋磚引玉，下面將分爲多篇文章從行業現狀、業務現狀、產品概述、技術團隊搭建、服務端技術平臺搭建、前端開發等多個維度來說述，咱們將三年多在B2B領域沉澱的核心產品和技術平臺公開，但願更多行業的人能深刻了解，少走一些彎路，但願對你們有幫助，本系列文章分佈以下（會繼續更新）：

一、《如何搭建高效率的生鮮 B2B 平臺（B2B 技術共享第一篇）》

二、《宋小菜如何切入生鮮 B2B 市場（B2B 技術共享第二篇）》

三、《生鮮 B2B 平臺的產品體系如何迭代（B2B 技術共享第三篇）》

四、《生鮮 B2B 如何搭建高效的技術團隊（B2B 技術共享第四篇）》

五、《如何從 0 到 1 搭建生鮮 B2B 的技術體系（B2B 技術共享第五篇）》

六、《宋小菜技術如何應對生鮮 B2B 業務的快速變化（B2B 技術共享第六篇）》

七、《生鮮 B2B 技術平臺的前端團隊該如何搭建（B2B 技術共享第七篇）》

八、《宋小菜有關「能力」的設計和思考（B2B 技術共享第八篇）》

九、《服務拆分的設計和思考（B2B 技術共享第九篇）》