書接上文：
繼續整理技術團隊最近的年終盤點，「採用我問他答的形式」主要是聆聽，這裡是跟一生之敵，小孫「孫狗」之間的對話！
個人在孫狗身上花的心思不可謂不少，之前有很多案例全部與他相關：
【Case】被下屬罵，記一次矛盾升級——有心無心，蝴蝶效應？
我們先看他一年來的性格測評：
執行相關屬性拉的很高，包括實幹家和完美主義者，凝聚者屬性應該是性格底色，沒什麼變化。但社交屬性、協調者、外交家變得很低，我們需要從總結中找找原因。
因為「孫狗」長了一張欠揍的臉，說話也難聽，所以聊天過程中情緒很難控制，既定的對談模式也輕易的被他打破了！
你印象最深的事
對話CEO
這一年過的很快，初期我負責一些離業務很遠的基礎服務如IM、使用者中心、推送、簡訊服務等，發現一個問題：
用心優化重構是這樣，不重構好像業務也能正常運轉，整體對整個業務的增長沒有太多幫助
時間切到2021年初，CEO找我們幾個同學聊天，按理說，我應該是很少能有機會接觸不了這種級別的大佬，他是小釵的leader，當時讓我記憶深刻的兩個問題如下：
- 你現在負責的團隊是做什麼業務的？
我們組是公共業務組主要負責使用者中心、IM系統、醫患等其它上層業務；還有一個醫院業務對接的小組，和現在業務方向關係不大，走正常的迭代。
- 你們小組規劃是怎樣的，需要多少人力？
我們組大概有30多人吧，做的是公司的公共服務大概羅列一下負責的基礎服務... ...，後續想要做
- 提升團隊的產出質效
現在技術棧不統一（PHP、Go 等），人員協調不方便，老架構本身不夠優化，我想推一套成熟的Go框架，讓系統效能提升，並且通過工程化的手段讓研發整個開發效率提升。
- 統一使用者中心
當時醫生和患者使用者中心繫統層面隔離，通用能力需要各自維護，希望能夠架構簡單通用。
- 醫院服務的業務線
根據業務同學、產品的訴求來進行業務迭代。
後面也聊了些其它的，最後他說別隻關注寫程式碼，多想想業務與團隊的規劃。
思考定位
之前沒怎麼帶過團隊，小釵非要強塞個不小的團隊給我，他真的在作死，把我放在那個位置上確實有些茫然。
之前的認知，就是自己努力幹跟著專案組跟著團隊就會有成長和成績，後面我一直再思考我在團隊的定位是怎樣的，我總結如下：
我的定位 = 創造的價值（把控力+基礎技能+遠期成長能力+瑣事處理）
在團隊中的位置，取決你在團隊中存在的價值，說創造的價值有點過了，創造是針對成功團隊來說的，普通團隊就說存在的價值吧。
「把控力」
對下，這是你對自己領域人事物的把控；對上，是你上級對你的把控。
自己領域的事情能處理好，才不會在關鍵時刻失控；上級對你預期沒有錯亂，才知道你能做什麼樣的事情，不會亂派任務，這一切都是不崩盤的基礎。
很顯然，小釵初期給我這麼大的團隊就是個錯誤，但我也只能幫他兜底。
「基礎技能」
這個毋庸置疑，就是對團隊來說你擅長的技能，技術、架構、業務側能力、前端、服務端、NA 技能；
專案層推動能力也很重要，他是能帶好一個專案的關鍵；管理層面對自己團隊的規劃管理能力。
這裡有個點要注意：
技術團隊都是慕強的，作為一級Leader，你的基礎技術能力一定要強
「遠期成長能力」
就是你能不能跟隨著公司或者團隊的成長一起成長，而不是跟不上團隊成長的節奏而掉隊
「瑣事處理」
面對非技術層面事情的一些溝通協調能力，有時候佔的比重還不小，他是你是否能承擔更多事情的基礎。
有朋友說「團隊的leader決定了團隊的文化」，我覺得說的很準確.
針對剛成立的公共服務組來說，我會優先招聘一些和自己性格類似(「吃苦耐勞能扛事」)的同學.
人到位了後面怎麼做呢？想了想之前leader怎麼帶我的，我就怎麼帶我的小夥伴：
- 抓關鍵人
我之前管7人，突然要管30人的團隊，這種時候「抓關鍵人」會很有用。
- 戰功文化
宣稱戰功文化，用成果來衡量後期的績效評定。
當時有4個關鍵人，一個是之前的醫院服務的負責人，一個是技術資歷比較老的同學，另外兩個是新招的一個服務端和前端。
前端同學不太適合管理也沒有凝聚力，很快就放棄了，最終只有三個關鍵人，根據業務不同分2個小組：
- 公共服務組；
- 醫院服務組；
當時有兩個關鍵人放在一個組，存在資源競爭問題，為了團隊穩定「需要馬上抉擇」，扶了之前資格比較老的關鍵人做了leader。
用人就需要滿足他的期望，加薪、升職必不可少更關鍵的還是要給機會和資源，小釵的說法好像也有一點用。
另外一個關鍵人在合適的時間為他開了新的業務線。
團隊整合
上面事件結束後，管理思維得到了初步建立，9月小釵帶我整合了一個子公司產研團隊......
面對一個陌生的團隊，如何在幾天的時間瞭解人事物，小釵使用的策略是人事盤點：
- 人才九宮格；
盤點將人才潛力和業績為座標將人才分佈到九個區域中，從而發現優質的人才。
- 事；
就是重要的業務線分享，整個業務的業務地圖勾勒；
- 具體的業務線和系統整合
我核心參與了供應鏈的整合。
首先進行業務部門整合，然後產品團隊整合，之後根據產品提的系統之間的整合再進行技術團隊的整合，但當時面臨的問題是：
- 被整合團隊的抗拒（自己幸苦做的業務線為什麼會送給你別人）；
- 整合多半會出現人員優化，哪些業務重要，需要留住哪些同學，這也正體現了上面人員盤點和業務線盤點的重要性。融合團隊是一方面，保證整個線上業務不出問題是最重要的；
- 為了更好的開展工作，產品團隊臨時出了一個整合方案，整體供應鏈1個月完成整合，當然1個月是不夠的，只是減少了後續系統合併的風險罷了。
果然11月人員開始動盪，產品離職，為此我作為產品的補位，臨時負責了供應鏈產品團隊。
「總結」
團隊整合需要進行「快速瞭解人員結構」、「明確目標」保持「業務穩定」、「團隊穩定」、殺伐果斷、快速執行防止後續核心人員離職
經過團隊整合我負責的團隊再次擴大，因為第一次管這麼大的團隊，這是我印象最深的事情。
你怎麼為團隊謀福利
擴充邊界
初期不熟悉全域性業務，團隊剛成立中心是如何穩定團隊，這裡我的心得與小釵一致：
讓喜歡的小夥伴做困難的事情「難受 => 忙碌 => 獲取成就感」；
還是讓他們保持現狀：「無所事事 => 空閒 => 然後團隊散了」。
我們和工程組做的事情有很多交叉，1月底為了提升公共團隊技術影響力，規劃了對外的閘道器係統。
之前公司的閘道器係統非常弱，當時出了方案做了壓測。但由於和工程團隊衝突，為了減少摩擦，方案來回過了好幾次，就是落不下去，大家討論的問題最終都是「誰來做」。
「這個時候往往比的就是落地能力了」，當工程組還在商量討論技術選型的時候，我們就已經選定了openresty作為技術棧，過年期間加班寫程式碼，過完年直接測試、灰度然後上線先佔坑。
公共組做工程組的事，直接把之前的工程組乾沒了，後續他們老員工基本都離職了。我認為他們心態太差，整體說來工程組同學的技術能力還是很不錯的，但沒打過仗，抓不住戰機，這次輸了，下次再來就行了啊。
這個事情上總結了2點：
第一：針對這中間雙方不確定的事情，就優先幹，如果不做這個系統，我這邊的團隊可做的事情比較少，很難提升技術向心力，關鍵人的成就感怎麼提升。
第二：要幫扶一個同學，就要給他更多的機會，並且「給他”高光時刻“」，做完閘道器係統後，拉一個全員的閘道器分享show他的成果，後續績效也好解決。
至此，公共組有了自己一系列使命：
- 大倉框架迭代（包括閘道器的優化）
在這個事情上參與的同學學到很多工程化的知識，有了成就感團隊就會更穩定，後續為了推動整個大倉工程化落地，公共組每個後端都需要進行全員的技術分享。
- IM+使用者中心優化
之前的IM併發能力低，而且業務隨處都會用到IM和使用者中心，這些複雜的事情整體也是持續了大概1年多的時間。
你最大的挑戰是什麼
負責供應鏈技術團隊
本來公共組我帶的得心應手，但小釵就是見不得我好。
8月後我負責了供應鏈組，小釵一直強調供應鏈業務需要謹慎對待，不能出大的問題。
供應鏈容易出事故，出問題鍋就很大，初期我心裡不願意，更想做工程技術業務，現在想想幸好能帶供應鏈業務，離業務近了很多。
要是整年都是一些基礎業務服務，不知道後續怎麼發展的更好，畢竟基礎服務離業務太遠了。
在這個團隊也遇到很多不好解決的問題，首先供應鏈太複雜，一出問題就是交易事故，原因可能是：
1）供應鏈本身涉及到訂單、拆單、ERP履約、售後等邏輯，整個系統邏輯比較複雜；
2）由於前期業務迭代快，很多業務邏輯不夠優化甚至帶傷上陣（這不是說之前的同學技術不行，是業務迭代的太快了，來不及考慮全就要發車）；
3、業務迭代快、系統迭代快、人員變動快，到最後熟悉的同學就成了這個業務上的”珍寶“，因為了問題只有他能解決；
於是整個團隊就變的「不可控了」，所以敬畏之心油然而生，對這個團隊的關鍵人調整會非常慎重。
「解決辦法」
開始業務重構，技術側自己驅動重構之前的業務程式碼，一方面是提升整個系統的設計規範化，方便後期迭代；另一方面是拉動更多的同學去熟悉業務。
這樣參與重構的同學會熟悉整個系統的內部邏輯，這樣「人員單點問題」就能夠友好解決。
「領地意識」強的同學肯定會反抗，這降低了不可替代性，而且是費力不討好，但是這種情況下可以通過上級來壓，「政治手段也是一個工具」。
「當然重構不是取代之前的核心同學」，因為在團隊中，這部分同學也是很好用的，要不然他們怎麼會成為單點同學，後續還是需要讓這些同學有更好的發展空間。
團隊需要他們解決問題，做這些的目的僅僅只為了「解決業務單點的問題」，增加「對核心業務的把控」，方便後續團隊分配和管理。
負責供應鏈產品團隊
小釵就是一隻狗，我剛把技術團隊搞好，他又給我找事！
之前自己都僅僅是做研發的事情，有少量的管理經驗也是研發側的，很少能出圈，小釵非要我做產品負責人！
到了產品側發現技術側的考慮真的太少了，自己也在思考什麼是重要的，很多事情變得顛覆認知，比如：
技術的重構是沒有意義的
研發：我進行的系統重構，把系統做好能更好的支援業務，維護成本也低了；
產品：需求之前提的，系統做好是你本質工作，你單獨做重構是不是之前沒做好（當然合理的重構產品能夠理解）；
技術需要多花些時間在新技術和工程上
研發：我們要多用新技術和新框架，技多不壓身，新專案我們就用來給新技術練手。
產品：我的需求能按時上線，不出問題。
我們業務邊界拆分，需要多分幾個微服務
研發：我們是微服務框架，微服務技術含量高，雖然這個應用流量不大，但是這樣更合理；
產品：如何實現我不管，應用越多浪費的伺服器資源更多，反正是公司給錢；
研發：那就不用給公司省錢了！
技術團隊之間業務爭搶
當時一個兄弟團隊想拿我們重構好的業務，理由按業務邊界劃分這個業務應該屬於他。
我的想法比較中立，研發都是我的資源給他又能怎樣......
負責這塊業務的技術同學不同意，自己辛辛苦苦將之前的老業務重構了，核心業務拿走後，團隊的小夥伴會怎麼想這個事情，那大家加班的意義在哪？這種是“殺富濟貧”，基於這個原因，我也就反對了這個事情。
以上都是技術同學會爭論的問題，但是作為產品一點都不關心，產品關心的是
- 供應鏈業務線應該如何發展；
- 如何提高部門之前的效率；
- 如何控制流程合規風險；
很多資源的消耗都是隻考慮到自己，但沒人關注公司資產的流失，「畢竟不是自己出錢」。
產品焦慮
剛來產品團隊還沒壓力，但Q4營收專案大爆發，這部分需求都會到供應鏈，簡單說來就是業務提訴求，產研去實現，不需要思考。
我管理供應鏈產研團隊，很多需求都能推動執行，只要能拉動營收，立項就做。
於是開啟了10月到12月供應鏈產品+研發加班忙成狗的模式，但當過了一段時間之後，發現又回到了之前的問題，「供應鏈應該如何規劃和發展」。這個問題讓我糾結到有些心態崩潰，原因是：
- 我自身是搞研發的，很少了解供應鏈整個行業的發展；
- 當時到這個位置，可能是小釵想讓我能更進一步。但是我考慮的是，這麼重要的位置，能力不行未免對團隊不負責，所以我心理壓力巨大；
我私下也找了很多供應鏈方面的資料，但短時間也給不出具體的目標和戰略。
因為企業遇到的問題很複雜，不是說了解的行業背景就能解決，更何況之前也來過很多行業大牛。
後面推專案制，所有的專案都是需要三要素才能做「目標、方案、時間」 ，所有專案目標都要量化，並不是定性就可以做了，定量的資料準備非常的複雜。
哎，這段時間我真的很焦慮！
下面給了一個戰略的規劃圖是比較全面的，做一個大的規劃需要有四步：
- 做評估，內外部、行業資料標準支撐；
- 繪藍圖，也就是頂層設計、戰略藍圖如下圖；
- 找路線，為了達成戰略目標有哪些具體實現路徑；
- 強管理，專案執行則是PMO關注的；
繪藍圖如下：
整個研發到產品經歷就像個洋蔥：
最裡面是研發、第二個就是產品，第三個就是業務：
- 研發：做好產品的給的需求，並把系統做好，學好技術；
- 產品：配合業務拉通其它部門和組，產出產品需求支援好業務；
- 業務：我們公司這部分業務怎麼增長，怎麼能達成營收，行業內其它企業是怎麼搞的那麼優秀的；
大產品經理是需要做產品+業務的事情，越到大圈做的事情越難，一方面可能是這個事情本來就很難；
另一方面也不是所有事情本身難，是需要配合的人太多了，不是一個團隊你的leader也制約不了其它人什麼，不可控的因素就變多了。
遇到過找人直接不理睬，但是為了專案持續下去軟硬兼施心態很重要，做高貴的研發的同學怎麼可以受這種氣，我內心也不想這樣，但是「有人非讓我去吃屎」，難啊！
有什麼想對小釵說的
一年的時間結束了，感謝leader給我的指導和幫助！
再回顧之前CEO的問題，感覺自己也只能回答一部分，我現在能理清楚供應鏈需要多少人，人員怎麼分配，具體到事都能很明確。
但是如果說就供應鏈作為一個起點來改變公司的現狀這個我做不到，我也不能做出長遠的規劃，你們不要逼我了，我也不知道該怎麼辦！！