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

若是你仔細觀察過宋小菜技術同窗的平常工做，你就會發現他們很喜歡談論一個詞，那就是「能力」。不管是在系統架構規劃的時候、技術方案設計的時候、開發問題探討的時候甚至PRD評審的時候，「能力」這個詞會不停地出如今他們的口中。是什麼緣由，使得這個詞這麼頻繁的出如今開發小夥伴的交流中呢？

1、什麼是「能力」

在詳細介紹什麼是「能力」以前，先賣個關子，想先給你們介紹另一個詞——VUCA時代（烏卡時代）。

VUCA是四個單詞的首字母組成的新詞，分別是volatility（易變性）、uncertainty（不肯定性）、complexity（複雜性）、ambiguity（模糊性）。VUCA最先出如今軍事用語中，可是如今這個詞愈來愈頻繁的出如今咱們的平常生活中了，緣由就是人們發現，這四個詞實在是太符合咱們如今的社會和時代了。咱們的生活、工做、社會以及這個高速發展的時代，不就是充滿了易變性、不肯定性、複雜性和模糊性嗎。

回到技術同窗的平常工做中，你們就會驚奇的發現，咱們接到的需求、產品方案、視覺稿、運營計劃甚至習覺得常的框架技術、依賴的服務、使用的中間件工具，不也充滿了VUCA的特質嗎。因此在這裏很是想和技術的同窗（特別是處於創業公司，業務正處於高速發展的的公司）說一句，不要再沉迷於「打死不改版PRD」或「再改就殺一個設計師祭天版UI」的罵戰或爭吵中了。由於當你回過頭review的時候就會發現，全部罵戰和爭吵的結論必定是「該變仍是得變」。緣由其實很簡單，VUCA是咱們這個時代所具有的特色，若是咱們不去適應他，而是想盡一切辦法去抵抗他，這是一件很是不划算的事情，並且每每你的努力會變成徒勞。

介紹了這麼多有關VUCA的思考，是時候引出「能力」這個詞了。由於咱們發現，不管公司的方向變化的有多麼快，或是死掉的業務數不勝數，仍是創新性的項目一個接一個的誕生，總有一些是相對不變的，而且能夠被咱們沉澱下來的東西，那就是「能力」。這樣介紹，可能仍是比較抽象，接下來舉兩個例子，可能你們就會有些感知了：

1.隨着業務發展，公司有愈來愈多的系統或者應用了，每一個系統老是須要有登陸流程的。一開始登陸流程可能全都是獨立的，A系統有一個登陸流程（使用郵箱+密碼登陸），B系統有一個登陸流程（使用動態短信登陸），C系統有一個登陸流程（使用登陸名+密碼+驗證碼登陸）。這個時候咱們就發現「能力「了，登陸流程，就是咱們須要沉澱的」能力「。由於登陸流程是能夠被枚舉完的，而且某一種登陸形態一旦被固化下來了，就能夠快速的輸出給其餘的系統使用（高度複用），以下圖所示：

2.業務老是多樣和複雜的，X業務中有一個場景須要郵件通知主管審批，Y業務中有一個場景須要短信通知銷售某個客戶已經下單，Z業務中有一個場景須要push給客戶優惠券立刻要到期了。這個時候咱們又發現「能力「了，消息通知中心，就是咱們須要沉澱的」能力「。和第一個例子同樣的思考方式，由於通知的途徑是固化的，而且某一種消息通知的途徑一旦被沉澱下來了，就能夠快速的輸出給其餘的業務場景使用（高度複用），以後這些消息通知的能力，還能夠組合使用，以下圖所示：

看了上述兩個例子的介紹，不少技術的同窗會以爲，這些不是很正常嗎，在咱們的公司裏不就是這樣設計的嗎。舉這兩個例子，並非想給各位介紹多麼高深的技術方案，而是想把「能力「這個詞講透。由於」能力「的設計更像是一種思惟模型，即」將抽象和穩定的向下沉，將多變和不肯定的往上浮」。這個思惟模型，不管是在接口編寫、架構思考、技術方案設計甚至平常的生活工做中，都會起到很大的幫助，而且也是適應VUCA時代的有利技巧。
複製代碼

2、設計「能力」的關鍵點

2.1 分清「業務」和「能力」

不少剛畢業的同窗或是工做經驗尚淺的開發同窗，在接到一個需求或任務時，每每會犯一個通病，是什麼呢？就是不能很好的區分「業務「和」能力「。他們每每」只面向業務編程「，請注意，在這裏提到的是」只面向業務編程「，重點是這個」只「字。好多開發同窗一邊聽着產品經理描述需求和功能，一邊腦子在飛快運轉。需求評審結束，腦海裏已經充滿了表結構的設計和字段的含義了，要不是還沒肯定開發分支，都認爲本身已經進入開發階段了。這裏有一句玩笑話」沒有什麼問題，是加一個接口或者加一張表不能解決的，若是有，那就加兩個。「講到這裏，是否是會引發不少開發同窗的會心一笑，這個階段估計全部的程序員都經歷過。
爲何我將這個問題總結爲——不能很好的區分「業務「和」能力「呢。就像剛纔提到的，其實關鍵是由於沒有造成那樣的思惟模型，即」將抽象和穩定的向下沉，將多變和不肯定的往上浮」。」業務「擁有的最多標籤，就是易變的、模糊的、不肯定的，這是」業務「天生就具有的特質。不少時候，運營同窗也是邊跑邊摸索，還一邊修正運營的戰略戰術，這個狀況在創業公司中，就更加明顯了。這時候若是技術同窗在開發過程當中不加思考，開發起功能來兵來將擋水來土掩，不停地加表不停地加接口，可想而知，若是久而久之結果將會多麼可怕。這也是宋小菜業務高速發展了三年，咱們犯過的錯誤，也給咱們帶來了長足的思考。舉一個咱們犯相似錯誤的例子：
由於業務發展快速，愈來愈多的角色被歸入到咱們的業務鏈路當中，好比有「交易客戶「、」供應商「、」司機」、」囤貨商「等等。由於不一樣的項目組承接了對應的需求開發，因此設計出來的結果可想而知，只能用」很是貼近咱們的業務「來形容了。後面遇到了什麼問題呢，好比隨着業務變化，用戶的身份是會多樣化的，好比有的用戶可能既是」供應商「又是」司機「，有的用戶身份既是」供應商「又是」囤貨商「等等。這時候問題就來了，「我怎麼知道他到底有幾個身份呢？」、「有的身份須要能登陸系統A，有的身份須要登陸系統B和C，有的身份不須要登陸咱們的系統，到底要怎麼控制呢？」
複製代碼

其實在咱們系統中出現兩三個身份後，按照剛纔介紹的思考方式，咱們的心中就應該敲響警鐘了，是時候是要作「業務」和「能力」的區分了，以便讓「能力下沉，業務上浮」。咱們根據業務的抽象，沉澱了用戶中心的「能力」，其中包括了帳戶體系、用戶體系和身份體系，並以相對抽象的「屬性」和「標籤」的擴展能力對外輸出，以此來支持高速的業務變化。

2.2 不要一開始就談「能力」

當開發的同窗們慢慢理解了「能力」的做用和價值的以後，每每又會帶來一個新的問題，那就是一開始就談「能力」。「能力」並非空想出來的，他必定是通過了一些業務形態的觀察和抽象，才能被沉澱出來的。好比一上來就談「咱們先作一個庫存中心，反正咱們是電商模式，必定用的到的」、「這個時候就須要一個商品中心了，由於XX公司說他們有，咱們業務有不少類似的地方，有個商品中心必定不會錯的」等等。像商品中心、庫存中心這些核心「能力」，必定不是這樣出現的。
切記切記，「能力」不是憑空冥想出來的，也不是靠經驗設計出來的。必定是貼合着具體的業務場景，不停的思考和抽象，在合適的實際沉澱下來的。又到了講述宋小菜慘痛教訓的時候了：
宋小菜前兩年的業務，物流業務一直處於城際配送，好比從杭州城內的某個地，配送到杭州城內的目標站點。這時候咱們作了一個統一的調度物流平臺，想將其做爲「能力「，輸出給宋小菜全部的物流調度業務。如今回過頭來看，只能怪當初太年輕了，看的業務太少了。以後咱們物流的複雜狀況，遠遠超出了當時的想象，好比咱們接入了骨幹物流，出現了從上游基地發貨的業務；好比城內大車沒法通行，必須先由大車倒給多輛小車的業務；好比一輛半掛車，先送杭州再送嘉興最後送上海的跨城業務。當初設計的物流調度中心，根本承接不了這樣多變和複雜的業務場景，並且就如今來看，當時的數據模型抽象都是有問題的。
因此，若是能意識到「能力下沉，業務上浮」這個設計思路，並明白他的價值和威力，只是第一步，千萬不要跌入憑空冥想「能力「的坑，這樣設計出來的」能力「，每每都只是霧裏看花，只是美好的願景而已。
複製代碼

3、如何建設「能力「

3.1 在項目過程當中沉澱「能力」

若是認定了某一個能力特別重要並但願沉澱，那接下來怎麼作呢？組一個專門的開發小組悶頭苦幹，快速產出？這樣固然能夠，可是從創業公司的經驗來看，這樣的模式每每並不可取。咱們更願意看到的項目形態是這樣的：「能力」從0到1的誕生，必定要緊貼某一個具體的業務J，以優先級最高的功能需求，輸出給這個業務J。別的業務Q、業務K知道咱們開始誕生0到1的「能力」的時候，必定會向「能力」產出方提出五花八門的需求。這個時候就須要「能力」產出方本身心中有一杆稱了，由於如今是「能力」從0到1的誕生的過程，你不可能知足全部的功能特性，你甚至都沒法判斷那些需求是否合理。因此咱們有一個準則：「能力」的從0到1，只爲一個業務服務。這樣的好處有哪些呢： 1.「能力」必須緊貼某一業務，避免了「能力」設計者霧裏看花，以防最後作出來的「能力」連一個場景都服務不到； 2.只服務一個業務場景，也避免了「能力」設計者胃口太兇，以爲全部的需求都合理，全部的需求都得知足，最後本身卻成爲了瓶頸； 3.給予「能力」設計者足夠的思考時間。由於順利的服務到了第一個業務，會更加有效的幫助「能力」設計者去抽象和思考「能力」；

3.2 在基建重構中優化「能力」

「能力」從0到1的誕生必定是最難的，你可能得擋住一些業務需求開發的任務，或是苦口婆心的向別人述說「能力」的好處，直到他們承認爲止。但「能力」的誕生每每只是紅軍長征的開始，「能力」是須要不停迭代，不停建設的。這些迭代的點或是須要建設的點，到底來自於哪裏呢？來自於源源不斷應用場景的接入。是時候介紹咱們的第二個準則了：只有服務了超過三個業務場景，纔是真正被承認的「能力」。這個準則就逼着「能力」的設計者，不停的思考業務的本質，以及抽象「能力」真正的價值。這樣的迭代，每每會安排在一些基建的項目中，讓「能力」的設計者有明確的目標和使命，去優化本身負責的「能力」。

4、結束語

和一些業內的朋友，或是前來面試的同窗交流，也常常會聊到「你負責的是一個XX中心，那你知道爲何大家須要有一個XX中心嗎？」，獲得的答案每每是「架構師以爲須要」或是「這不是很正常嗎，別的公司也都有」。若是你問我這個問題，這篇文章就是個人答案了。

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

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

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

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

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

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

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

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

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

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