如果你仔細觀察過宋小菜技術同學的日常工作，你就會發現他們很喜歡談論一個詞，那就是“能力”。無論是在系統架構規劃的時候、技術方案設計的時候、開發問題探討的時候甚至PRD評審的時候，“能力”這個詞會不停地出現在他們的口中。是什麼原因，使得這個詞這麼頻繁的出現在開發小夥伴的交流中呢？
一、什麼是“能力”
在詳細介紹什麼是“能力”之前，先賣個關子，想先給大家介紹另外一個詞——VUCA時代（烏卡時代）。
VUCA是四個單詞的首字母組成的新詞，分別是volatility（易變性）、uncertainty（不確定性）、complexity（複雜性）、ambiguity（模糊性）。VUCA最早出現在軍事用語中，但是現在這個詞越來越頻繁的出現在我們的日常生活中了，原因就是人們發現，這四個詞實在是太符合我們現在的社會和時代了。我們的生活、工作、社會以及這個高速發展的時代，不就是充滿了易變性、不確定性、複雜性和模糊性嗎。
回到技術同學的日常工作中，大家就會驚奇的發現，我們接到的需求、產品方案、視覺稿、運營計劃甚至習以為常的框架技術、依賴的服務、使用的中介軟體工具，不也充滿了VUCA的特質嗎。所以在這裡非常想和技術的同學（特別是處於創業公司，業務正處於高速發展的的公司）說一句，不要再沉迷於“打死不改版PRD”或“再改就殺一個設計師祭天版UI”的罵戰或爭吵中了。因為當你回過頭review的時候就會發現，所有罵戰和爭吵的結論一定是“該變還是得變”。原因其實很簡單，VUCA是我們這個時代所具備的特點，如果我們不去適應他，而是想盡一切辦法去抵抗他，這是一件非常不划算的事情，而且往往你的努力會變成徒勞。
介紹了這麼多有關VUCA的思考，是時候引出“能力”這個詞了。因為我們發現，無論公司的方向變化的有多麼快，或是死掉的業務數不勝數，還是創新性的專案一個接一個的誕生，總有一些是相對不變的，並且可以被我們沉澱下來的東西，那就是“能力”。這樣介紹，可能還是比較抽象，接下來舉兩個例子，可能大家就會有些感知了：
1.隨著業務發展，公司有越來越多的系統或者應用了，每個系統總是需要有登入流程的。一開始登入流程可能全都是獨立的，A系統有一個登入流程（使用郵箱+密碼登入），B系統有一個登入流程（使用動態簡訊登入），C系統有一個登入流程（使用登入名+密碼+驗證碼登入）。這個時候我們就發現“能力“了，登入流程，就是我們需要沉澱的”能力“。因為登入流程是可以被列舉完的，並且某一種登入形態一旦被固化下來了，就可以快速的輸出給其他的系統使用（高度複用），如下圖所示：
2.業務總是多樣和複雜的，X業務中有一個場景需要郵件通知主管審批，Y業務中有一個場景需要簡訊通知銷售某個客戶已經下單，Z業務中有一個場景需要push給客戶優惠券馬上要到期了。這個時候我們又發現“能力“了，訊息通知中心，就是我們需要沉澱的”能力“。和第一個例子一樣的思考方式，因為通知的途徑是固化的，並且某一種訊息通知的途徑一旦被沉澱下來了，就可以快速的輸出給其他的業務場景使用（高度複用），之後這些訊息通知的能力，還可以組合使用，如下圖所示：
看了上述兩個例子的介紹，很多技術的同學會覺得，這些不是很正常嗎，在我們的公司裡不就是這樣設計的嗎。舉這兩個例子，並不是想給各位介紹多麼高深的技術方案，而是想把“能力“這個詞講透。因為”能力“的設計更像是一種思維模型，即”將抽象和穩定的向下沉，將多變和不確定的往上浮”。這個思維模型，無論是在介面編寫、架構思考、技術方案設計甚至日常的生活工作中，都會起到很大的幫助，並且也是適應VUCA時代的有利技巧。
複製程式碼二、設計“能力”的關鍵點
2.1 分清“業務”和“能力”
很多剛畢業的同學或是工作經驗尚淺的開發同學，在接到一個需求或任務時，往往會犯一個通病，是什麼呢？就是不能很好的區分“業務“和”能力“。他們往往”只面向業務程式設計“，請注意，在這裡提到的是”只面向業務程式設計“，重點是這個”只“字。好多開發同學一邊聽著產品經理描述需求和功能，一邊腦子在飛快運轉。需求評審結束，腦海裡已經充滿了表結構的設計和欄位的含義了，要不是還沒確定開發分支，都認為自己已經進入開發階段了。這裡有一句玩笑話”沒有什麼問題，是加一個介面或者加一張表不能解決的，如果有，那就加兩個。“講到這裡，是不是會引起很多開發同學的會心一笑，這個階段估計所有的程式設計師都經歷過。
為什麼我將這個問題總結為——不能很好的區分“業務“和”能力“呢。就像剛才提到的，其實關鍵是因為沒有形成那樣的思維模型，即”將抽象和穩定的向下沉，將多變和不確定的往上浮”。”業務“擁有的最多標籤，就是易變的、模糊的、不確定的，這是”業務“天生就具備的特質。很多時候，運營同學也是邊跑邊摸索，還一邊修正運營的戰略戰術，這個情況在創業公司中，就更加明顯了。這時候如果技術同學在開發過程中不加思考，開發起功能來兵來將擋水來土掩，不停地加表不停地加介面，可想而知，如果長此以往結果將會多麼可怕。這也是宋小菜業務高速發展了三年，我們犯過的錯誤，也給我們帶來了長足的思考。舉一個我們犯類似錯誤的例子：
因為業務發展快速，越來越多的角色被納入到我們的業務鏈路當中，比如有“交易客戶“、”供應商“、”司機”、”囤貨商“等等。因為不同的專案組承接了對應的需求開發，所以設計出來的結果可想而知，只能用”非常貼近我們的業務“來形容了。後面遇到了什麼問題呢，比如隨著業務變化，使用者的身份是會多樣化的，比如有的使用者可能既是”供應商“又是”司機“，有的使用者身份既是”供應商“又是”囤貨商“等等。這時候問題就來了，“我怎麼知道他到底有幾個身份呢？”、“有的身份需要能登入系統A，有的身份需要登入系統B和C，有的身份不需要登入我們的系統，到底要怎麼控制呢？”
複製程式碼其實在我們系統中出現兩三個身份後，按照剛才介紹的思考方式，我們的心中就應該敲響警鐘了，是時候是要做“業務”和“能力”的區分了，以便讓“能力下沉，業務上浮”。我們根據業務的抽象，沉澱了使用者中心的“能力”，其中包括了賬戶體系、使用者體系和身份體系，並以相對抽象的“屬性”和“標籤”的擴充套件能力對外輸出，以此來支援高速的業務變化。
2.2 不要一開始就談“能力”
當開發的同學們慢慢理解了“能力”的作用和價值的之後，往往又會帶來一個新的問題，那就是一開始就談“能力”。“能力”並不是空想出來的，他一定是經過了一些業務形態的觀察和抽象，才能被沉澱出來的。比如一上來就談“我們先做一個庫存中心，反正我們是電商模式，一定用的到的”、“這個時候就需要一個商品中心了，因為XX公司說他們有，我們業務有很多相似的地方，有個商品中心一定不會錯的”等等。像商品中心、庫存中心這些核心“能力”，一定不是這樣出現的。
切記切記，“能力”不是憑空冥想出來的，也不是靠經驗設計出來的。一定是貼合著具體的業務場景，不停的思考和抽象，在合適的實際沉澱下來的。又到了講述宋小菜慘痛教訓的時候了：
宋小菜前兩年的業務，物流業務一直處於城際配送，比如從杭州城內的某個地，配送到杭州城內的目標站點。這時候我們做了一個統一的排程物流平臺，想將其作為“能力“，輸出給宋小菜所有的物流排程業務。現在回過頭來看，只能怪當初太年輕了，看的業務太少了。之後我們物流的複雜情況，遠遠超出了當時的想象，比如我們接入了骨幹物流，出現了從上游基地發貨的業務；比如城內大車無法通行，必須先由大車倒給多輛小車的業務；比如一輛半掛車，先送杭州再送嘉興最後送上海的跨城業務。當初設計的物流排程中心，根本承接不了這樣多變和複雜的業務場景，而且就現在來看，當時的資料模型抽象都是有問題的。
所以，如果能意識到“能力下沉，業務上浮”這個設計思路，並明白他的價值和威力，只是第一步，千萬不要跌入憑空冥想“能力“的坑，這樣設計出來的”能力“，往往都只是霧裡看花，只是美好的願景而已。
複製程式碼三、如何建設“能力“
3.1 在專案過程中沉澱“能力”
如果認定了某一個能力特別重要並希望沉澱，那接下來怎麼做呢？組一個專門的開發小組悶頭苦幹，快速產出？這樣當然可以，但是從創業公司的經驗來看，這樣的模式往往並不可取。我們更願意看到的專案形態是這樣的：“能力”從0到1的誕生，一定要緊貼某一個具體的業務J，以優先順序最高的功能需求，輸出給這個業務J。別的業務Q、業務K知道我們開始誕生0到1的“能力”的時候，一定會向“能力”產出方提出五花八門的需求。這個時候就需要“能力”產出方自己心中有一杆稱了，因為現在是“能力”從0到1的誕生的過程，你不可能滿足所有的功能特性，你甚至都無法判斷那些需求是否合理。所以我們有一個準則：“能力”的從0到1，只為一個業務服務。這樣的好處有哪些呢：
1.“能力”必須緊貼某一業務，避免了“能力”設計者霧裡看花，以防最後做出來的“能力”連一個場景都服務不到；
2.只服務一個業務場景，也避免了“能力”設計者胃口太凶，覺得所有的需求都合理，所有的需求都得滿足，最後自己卻成為了瓶頸；
3.給予“能力”設計者足夠的思考時間。因為順利的服務到了第一個業務，會更加有效的幫助“能力”設計者去抽象和思考“能力”；
3.2 在基建重構中優化“能力”
“能力”從0到1的誕生一定是最難的，你可能得擋住一些業務需求開發的任務，或是苦口婆心的向別人述說“能力”的好處，直到他們認可為止。但“能力”的誕生往往只是紅軍長征的開始，“能力”是需要不停迭代，不停建設的。這些迭代的點或是需要建設的點，到底來自於哪裡呢？來自於源源不斷應用場景的接入。是時候介紹我們的第二個準則了：只有服務了超過三個業務場景，才是真正被認可的“能力”。這個準則就逼著“能力”的設計者，不停的思考業務的本質，以及抽象“能力”真正的價值。這樣的迭代，往往會安排在一些基建的專案中，讓“能力”的設計者有明確的目標和使命，去優化自己負責的“能力”。
四、結束語
和一些業內的朋友，或是前來面試的同學交流，也經常會聊到“你負責的是一個XX中心，那你知道為什麼你們需要有一個XX中心嗎？”，得到的答案往往是“架構師覺得需要”或是“這不是很正常嗎，別的公司也都有”。如果你問我這個問題，這篇文章就是我的答案了。
關於如何搭建高效率的生鮮B2B平臺，因為包含的內容較多，也很複雜，無法再一篇文章中給大家講清楚，本篇文章只是拋磚引玉，下面將分為多篇文章從行業現狀、業務現狀、產品概述、技術團隊搭建、服務端技術平臺搭建、前端開發等多個維度來講述，我們將三年多在B2B領域沉澱的核心產品和技術平臺公開，希望更多行業的人能深入瞭解，少走一些彎路，希望對大家有幫助，本系列文章分佈如下（會繼續更新）：
1、《如何搭建高效率的生鮮 B2B 平臺（B2B 技術共享第一篇）》
2、《宋小菜如何切入生鮮 B2B 市場（B2B 技術共享第二篇）》
3、《生鮮 B2B 平臺的產品體系如何迭代（B2B 技術共享第三篇）》
4、《生鮮 B2B 如何搭建高效的技術團隊（B2B 技術共享第四篇）》
5、《如何從 0 到 1 搭建生鮮 B2B 的技術體系（B2B 技術共享第五篇）》
6、《宋小菜技術如何應對生鮮 B2B 業務的快速變化（B2B 技術共享第六篇）》
7、《生鮮 B2B 技術平臺的前端團隊該如何搭建（B2B 技術共享第七篇）》