原創不易，求分享、求一鍵三連
兩個故事
技術的價值？
大家不要看我很樂觀，其實去年考核拿了個C：
那時候一顆疑惑的種子也種下了，一直在問自己一個問題：
技術團隊對於公司的價值是什麼？
跟外包團隊有什麼差別？
技術是個成本部門，並沒有自己的產品，也不帶流水！
這也是很多技術總監會面臨的一個問題：
多數時間去寫程式碼了，行業知識這種枯燥的東西他們怎麼可能太瞭解呢？
誰瞭解的多，誰對細節有掌握，誰就對那件事情有話語權
技術是個通用技術，只要技術好在哪裡都能待，所以丟掉技術無異於自絕後路。
而事實上技術負責人寫程式碼帶來的幫助微乎其微，於是技術負責人就會陷入一種死迴圈，甚至會有些自責：
就是自己不給力，就是因為自己做的不夠好，才導致了團隊在公司中話語權不夠；但你讓他不要寫程式碼那也是「萬萬不能的」
我認真去觀察了下，看看不同團隊技術話語權問題，竟然發現外包團隊的技術話語權最高？這尼瑪真的氣人！
然後我又去研究了下，哪個CTO是公司決策層的核心？額，有點不好看呢...
看了《經濟學原理》後，我「感覺」真實世界執行的「另一個」底層邏輯是資本流動，做為一個負責人，你瞭解公司資金流嗎，你瞭解為什麼要收購一個公司嗎，你看得懂財務報表嗎？
是的，這些都是非本專業的，我們除了技術，其實對其他所知甚少，而高管會議時，你說的效能優化、模組重用、效率提升天老爺才感興趣呢？
甚至個別同事連研發和IT都分不清，這是痛苦的地方，說不清楚說不明白啊，讓你問業務點問題都不知道說什麼。
當然，話不可絕對，這個也許只是圈子問題...
兜底
前面的章節簡單探討過leader由於安全感、焦慮感搶下面小夥伴活幹的問題，這是一種卡位、上下鎖死，是對資訊量的不負責，也是對下面下夥伴的不負責，屬於偏內卷的做法。
於是我們提出了五維能力模型和Leader的五件事回答這個問題：
但是，方法論太虛，我們舉一個例子說明總監以上該做什麼：
之前一個產品同學跑來跟我們說需要採購一套供應鏈系統，以滿足某方面的需求，而他十分迫切，希望我們儘快進行評估。
產研是天生的「敵人」，這類採購行為，當然是直接叫停（玩笑罷了），取而代之的是幾個問題：
1）供應鏈系統是我們產品矩陣（框架）中的什麼角色；
2）供應鏈系統是不是我們的核心依賴項；
3）其他類似的公司，供應鏈系統是否採購，是什麼樣的狀態；
4）更成熟的公司是如何做的；
於是產品同學便去調研了......
這裡大概得出了技術總監的一個重要差異化：
要有大局觀，要有成本意識
大leader需要跳出技術框架，部分進入產品（業務）框架，對每一部分要有自己足夠的認知，也要知道這個部分對於全域性是什麼角色。
因為一般來說，各個小leader只會關注到自己的模組，大leader才有這個資訊量以及時間（畢竟不寫程式碼，不跟太多細碎的專案）將這些模組串聯，如果沒有關注全域性的人，就會出現灰色地帶區域無人管理的情況。
所以技術Leader可以成為團隊兜底的存在，但他為什麼能兜這個底，除了兜底這種保下限的事情，還有沒有什麼可以彎道超車的事？
業務端的技術創新
什麼是業務架構師
所謂業務架構師即⼀個優秀的技術站在業務⻆度思考問題，扮演部分產品、運營⻆⾊，然後形成⼩團隊，站在⼯程效率⻆度與產品業務⽅⼀起解決實際問題，擁抱變化也控制變化。
說白了就是——結合業務做技術創新...
業務是資訊輸入是底色，技術是創新能力，底色+能力=創新的可能
從個人發展來說，大概是這樣的：
1）更大的認知
比如，之前管50人團隊，我現在能管500人團隊。
2）更多的認知
比如，之前做了兩年開發，又去做了兩年產品，再去做了兩年語文老師。
3）1+1>2的認知
比如，兩個相關聯的領域，先做了兩年技術，升職做了架構師，甚至需要負責某個產品的設計。
這裡比較晦澀，再舉個不恰當的例子是，學了九陽神功，後面又學了九陰真經，最後達到了1+1>2的效果，Hybrid架構就是這類產物。
業務工程師便是要融合業務與技術兩個領域，設計出更好的結果，這裡的輸入是業務及技術知識，產出可以是產品、服務、合作流程、合作機制等。
大公司有明顯的「邊界」，很難允許技術去做產品決策，但是前端做點後端的工作，做點Native的工作，這個限制沒那麼嚴格，畢竟有fullstack的說法嘛。
2W1H
業務架構師，事實上就是要從技術領域轉到產品領域，這有一定要求，首先你得在技術領域做到至少是「自己的上限」，確實找不到什麼增長點了才去做；
如果專業領域本身能再進一步，並且興趣點就在這裡，還真沒必要做這個事；其次是你至少有一些「天賦」，想接觸下業務，要有興趣。
真實情況下也是很多總監及以上會開始接觸業務，技術+管理畢竟沒有技術+業務+管理來得香。
其次是時機點，成長也是有成本的，讓技術總監去負責某條業務、產品線事實上是有很高的試錯成本，能不能拿到這種成長資源去吃這個經驗包，也是要考慮的。
強行轉可能需要降維，不是所有人能承擔，資金上不划算嘛
比如，我這裡就是負責技術團隊的同時，又恬不知恥的要了某塊產品線，雖然恬不知恥，但還是立了軍令狀。
這裡要注意的是，管理團隊和把自己作為一個產品設計者是兩回事，比如之前管客服團隊，可能只是招個客服leader，做代理即可。
這裡的區別是，下場去把腳打溼，甚至把頭髮打溼，淹不死就行。不懂的就把頭放低，初期承認不丟人，中後期還不懂就別折騰了...
最後具體到怎麼做，就千人千面了，這裡舉個例子。
案例·建立主線
業務架構師的第一要務是建立產品（業務）主線，不管你以什麼方式，以你認為自洽的邏輯將產品線串起來，最好有完善的資料流向支撐串聯邏輯，比如比較流行的人貨場：
PS：圖都是知乎上截的
先拆分業務（產品）模組，再思考技術模組，做到一定對映關係，這樣方便了解全面。
我這邊喜歡採用三層框架做分解，之前看了劉潤的一篇文章，裡面大概有幾句話：
企業的唯一目標是創造顧客，創造（獨特、品質）價值+（儘量）傳遞價值；
創造價值=做產品（服務）；
傳遞價值=做營銷+做渠道=提高觸達；
於是可以把產品分為三層框架：
之前我問了老闆一個問題：如果微信九宮格給我們開放入口，是不是就成功了？
這裡的問題的本質其實是，是不是產品流量足夠大就算成功。
老闆想了想說了下，流量這麼大，你也承接不了啊。
這裡的邏輯相當於你在村裡開了一個小餐館，突然給你挪到火車站，就算流量大，你這個小餐館也服務不了，這裡除了菜品好不好吃，還涉及到整個後廚的供應鏈管理，整個餐館的服務（人員服務，菜品服務），整個銷售攬客策略等......
所以初期，基礎服務非常重要，其次流量很重要，再次營銷策略很重要。
PS：這不廢話嗎，肯定都重要啊！
以世面上的直播平臺為例，可能是這樣的：
不論是人貨場還是三大框架，或者其他什麼模式，只要能用一條線一個資料流將現有的產品主線串起來都可以，然後再以你的邏輯判斷其中每個產品模組在產品大藍圖中是什麼角色，未來產品藍圖演化過程中應該是什麼位置即可。
案例細化·營收框架
PS：這部分完全是初學者認知，大家笑一笑就好
形成系統性的思維後，需要對某條線建立足夠的認知，比如深入營收模組，便至少需要回答以下問題：
1）公司的營收基本盤是什麼；
2）既然營收活動可以刺激消費，那麼他是怎麼做到的，具體到一個週期幾個營收活動可以利益最大化；
3）某些對營收有關係的模組要下線，這些模組屬於哪部分，為什麼下線為什麼做不起來；
4）什麼是貨幣體系，他是如何崩毀的；
......
這裡稍微深入一點，首先回答一個問題，「什麼是營收框架」？
營收框架其實是平臺各個產品的市場集，是「所有消費產品或者服務」的「提供方」（賣方）和「消費方」（買方）組成的群體
消費方決定了產品的需求（量），提供方決定了一種產品的供給（量）；
營收框架中有許多角色參與其中，核心就是買賣方。
第二個問題是「營收框架如何執行的」？
事實上平臺一般不提供內容服務，比如直播平臺的服務是主播提供的，教育平臺的服務是「教師」提供的；
這些角色提供內容服務的時候，使用者消費平臺提供的產品對服務提供者進行獎勵（現金、流量、榮譽），平臺通過消費模組使用的「權益」（特效、身份感）對使用者進行獎勵。
簡單來說就是，平臺與賣方提供服務、使用者消費服務，三方都獲得獎勵，這個就是營收框架執行的方式，——「花錢大家都開心」
作為平臺方，非常關心整個營收的規模，所以平臺需要使用各種方法，讓這個「營收盤子」越做越大，需求量變大或者效率變高（賣方產出變高）都是可行的方向。
第三個問題是，「平臺如何影響規模」？
流量不是這裡考慮的範疇，關於營收框架執行效率如何提高，這裡首先要思考另一個問題：
單一產品營收規模=產品價格*產品銷量
所以無論什麼公司，做活動（撒幣）變向降低產品價格，就是最好的手段，通過提高服務「有效價值」的手段來增加消費量，從而增加總體消費額；
另外，平臺提供了「營銷事件」，也可以觸發需求量提升，比如傳統節日、520節點是一致的。
在這種一步步發問中，將產品的所有收入手段做分類，比如會員、折扣、遊戲折扣...如此一來，便對這個模組有了較為清晰的認知了。
理想情況下，產品（業務）認知建立結束，便可以同步執行技術相關的建設，設計基本盤，設計營銷活動，什麼服務需要組合，折扣怎麼設計，全域性貨幣體系如何設計，便可以娓娓道來。
然後實際情況可能稍顯複雜......
結語
成為總監是獲取某些資訊的入場券；
瞭解業務、深入業務、融合技術與業務才是進階之道。
全面的瞭解業務，也是中層管理的第一要務！
好了，今天的分享就到這，希望對各位有用。「原創不易，多多分享」