原創不易，求分享、求一鍵三連繼續整理技術團隊最近的年終盤點，「採用我問他答的形式」主要是聆聽，今天這位同學，我之前給他打的標籤是「老黃牛」，我們先來看他一年來的角色變化：
居然是個完美主義者和凝聚者的「矛盾結合體」落地能力很強，交到手裡的東西一定會做，並且會堅持做到最好。
但因為凝聚者屬性很高，所以不會要求其他同學跟自己乙個要求，作為組員是好事，作為leader很有問題，這樣會導致下屬躺平，自己把活做完，死撐。
我其實不太了解為什麼，這個同學協調屬性和外交屬性會急劇下降，反而是凝聚者屬性明顯上公升，難道是因為談戀愛了嗎？
該同學表示應該是跟性格有關，他今年更願意去多聽其他人的意見，而且也不太會拒絕人，有點中庸（其實也有點和稀泥的味道），也想讓團隊的人都覺得我們團隊是乙個有溫度的，輕鬆，暢所欲言的團隊。
之前小釵帶著大家使用「ddd按業務線劃分組織架構」後，也形成了乙個虛擬職能線，分別有前後端「技術委員會」，我是前端技術委員會的成員之一。
這是乙個由vue寫的大型系統，已經迭代了「近4年時間了」，是個嚇人的老傢伙。
技術解決方案已經有些落後，而且最近頻繁出現「依賴安裝報錯」，提交**報錯。
這是因為公司幾乎所有的業務都寫在了這上面，不同的團隊同時在乙個專案開發，規範這些根本沒法約束。
即使之前統一處理過一次，但是隔段時間又會冒出這些問題來。所以我們決定按照業務對系統進行拆分，各個業務組只需要維護各自的系統，這樣的話衝突更少，效能也會更好，然後這個負責人指定給我了。
這也是小釵之前幹訓班分享的分而治之的思路。
首先進行**的拆分，我們按照模組將**進行拆分，單獨部署每個拆分出來的系統，這一步進行的還蠻順利。
然後技術部基建也在進行，剛好這時sso系統許可權管理系統上線，需要去接許可權系統，但現在乙個系統被拆分成11個子系統，每個系統去接許可權十分的麻煩。
而且又要保證現在使用的人的許可權保持不變。這時我們想到的方法就是讓產品去收集許可權，建立角色。產品大佬們很無語，但是也配合我們搞了。
老系統我們是沒有角色概念的，就是每個賬號需要哪個選單就勾哪個，現在賬號要關聯角色，角色關聯選單（「他說的sod系統，審計要求」）。
讓產品來決定哪個賬號需要哪些角色，這幾乎是「不可能的事」，系統設計之初沒有意識到這一點，至少沒有往深的想，反正是產品搞，管他們那麼多幹嘛，他告訴我需要哪些角色，我就賦予哪些角色就行了。
這一拉扯，一拖就是幾個月，產品最後無能為力。這個時候我們才回過頭來想，是不是可以通過技術手段來解決，跟小夥伴們頭腦風暴，最後我們通過技術手段在「兩周時間內」解決了問題。
回過頭來看這個問題，我們最開始的方案看似沒有太大的問題，其實是有「甩鍋」的成分，我們把麻煩丟給了產品，產品只能乙個個賬號去看有哪些許可權，哪些許可權可以聚合為乙個角色，哪賬號能配置這個角色。
我們有幾百個許可權，幾百個賬號，這靠人是完全不能可能完成的事，但是我們「選擇了視而不見」，所以我們還是需要站高一點，凡事都得多想點，而不是只把自己手邊的事完成。
現在開源腳手架有很多，而且也很強大，這造成了我們使用的腳手架沒有統一，大家都「按照自己的喜好」進行選用。而且由於是開源的腳手架，如果要定製一些場景其實還是有點麻煩的，所以我們就打算自己造乙個。
這個腳手架也是我們明年前端開發平台的乙個開端。這個沒有啥具體好說的，就是純技術方面的規劃。
我們的團隊是公司第乙個單元化組，為解決乙個具體的業務問題而成立的。
當時的系統基本已經處於癱瘓不可用的狀態了，為了能快速解決這個問題，小釵決定成立單元組專門來解決，我被選中了擔任這個單元組的負責人。
組建隊伍之初，後端老大幫忙找了個大佬來幫忙，自己又拉了乙個平時有合作的小夥伴。
前端拉人時還是遇到了些問題，大家一聽說是做這個業務其實「都不是很願意搞」，最後在軟磨硬泡之下，還是把團隊給建立起來了。然後就開始了系統的優化迭代，然而每天問題反饋群裡都有「幾十個不同的問題反饋」，當時真的是焦慮得要死。
在這過程中，我們經過了幾次大大小小的重構迭代，在2023年底的時候，我們的系統已經解決了大部分的問題，問題反饋也少了很多。
在2023年初的時候，我們開始了新一輪的重構優化，將php重構成了go，終於在今年6月份的時候，完成了所有的優化，整個系統的穩定都得到了很大提公升。
一年過去了，基本已經沒有在反饋啥問題。在這個過程中團隊的小夥伴都很給力，特別是在成立單元組的初期，大家頂著壓力加班加點的搞，但是看著反饋問題越來越少，系統越來月穩定，大家的「成就感其實挺高的」，覺得自己的努力是有成效的。
首先是業務問題太大必須解決，然後是團隊組織結構混亂，但我畢竟是空降，不想強行改架構
不論從業務角度還是團隊角度，這個專案都不可能失敗，會有足夠的資源傾斜
在這過程中，公司有幾次組織架構的調整，但是對我們單元組來說影響並不大，我們團隊的人基本都是穩定，只是平移到其他部門下，而且人員還有了增加。
但由於公司業務變化，我們負責的業務迭代減緩，小組的成員都被借去幫忙，整個小組七零八散，甚至我們組乙個前端和後端小夥伴長期支援其他組的業務重構。
最開始的時候其實還並沒有意識到這是乙個問題，覺得都是在做事嘛，在哪不是做。而且我們都是作為研發部，在別的組人員不足的時候，肯定需要支援嘛，這不是集體榮譽感嘛，然而這就是我「短視的表現」。
雖然我們的承擔的「壓力減小」了，但是我們卻「沒有感到輕鬆」，每天奔波在各個組的業務之間，有時候過需求都會忘記我們，而是在快提測的時候發現需要支援，就被拉去搞一下。
最後的結果是個人成就沒有，團隊成就也沒有，難道我們要說我們幫其他小組創造多少收益，這關我們什麼事，績效又不會分我們一點。
作為小組leader，我認為這一年的工作「是失敗的」。
如何去帶領好乙個團隊，是「我們」一直都在想的問題，所有交給我們的業務都保質保量的完成，然後等著下一波需求來，然後再完成，「依次迴圈」？
這樣肯定不是乙個好的團隊，這樣的話我們只是「一群工具人」，別人有需要就拿去用，不需要就晾著。作為團隊leader，我覺得應該有以下的幾方面需要做到：
1）領地意識要強，在自己的領地裡進行深耕
高手的破局思路： 找到自己的**值區——讓自己成為某個領域的頭部——再借助頭部效應的系統推力。從乙個小頭部不斷地向大頭部移動，實現躍遷。
而作為乙個小組要實現躍遷，就需要在自己負責的領域裡面進行深耕，將自己組負責的業務做精，只要把自己負責的一畝三分地搞出彩了，才有可能獲得更多的資源，而不是靠著給別人組打工，這樣白白浪費了自己小組的資源。
2）努力擴充套件自己的業務邊界，有擔當
組織架構無論是如何完善，都會有一些三不管地帶，這些三不管地帶做也可以，不做也行，拉扯起來溝通成本太高。
這時應該適時的站出來，短期看可能接了些不好的業務，讓自己組上的成員多了無謂的工作，但是往上看這是團隊利益最大化。
3）多站在業務角度看待問題
乙個優秀的小組，不僅僅是要能承接需求，也要有能力去pk需求。產品給啥做啥，這樣就只是把自己做為乙個工具。
需要拔高自己的視野，與產品共同**出最優方案，而不是一味的接受。
4）努力為組內小夥伴創造成長機會和成就感
對於中低t職級的夥伴，多組織分享，並且督促他們進行學習成長，讓他們覺得有所收穫。
自從小釵來了後，開始實施「人才運營機制」，幾場幹訓班培訓，和平時他不加保留的分享，對整個團隊都產生了莫大的助益。
這一年對我來說，最大的改變應該是「認知改變」，提公升沒提公升不好說。
以前我認為作為乙個開發，就是你給我原型，我給你**，然後萬事大吉。作為乙個leader，上面給我需求，我分給下面的小夥伴，然後開發完成，上線穩定就好了，但是目前其實有了一些「不一樣的認知」
做為leader，更多的會想如何把團隊建設的更好、如何去激勵團隊的士氣、如何去為團隊獲取資源、如何讓我們團隊的小夥伴們更好的工作。除了技術方面，業務方面的事也需要去了解，並且要更加深入到業務中，要有「長期的規劃意識」。我是產品和團隊開發小夥伴們的溝通橋梁，也需要幫助產品更好理解技術實現，幫助開發小夥伴更好的了解產品的規劃。
雖然說了這麼多，但是具體怎麼去做，我還是不是特別的清楚，目前來說也只到了「知」的地步，希望明年形成自己的一套體系，達到「知行合一」。
總結如人，這個同學的總結很實在，沒有抖機靈的部分。
他最大的問題是「沒有戰略能力」，提不出來目標，所以小組同學只能打零工。
而他顯然已經意識到這一點，開始在業務著手，我也希望他能繼續深耕，走出一條自己的路線。
加油！好了，今天的分享就到這，希望對各位有用。「原創不易，多多分享」
技術部如何做覆盤 「年終盤點一對一」之很剛的同事
近期開始了年終盤點，會跟所有我關注的同學做一次相對深入的交流，採用我問他答的形式 主要是聆聽，這裡是跟第二位同學脫敏後的交流。這位同學性格一直很剛，甚至有點 呆呆的 但他今年的回答讓我很滿意，我們看他今年有什麼變化呢？另外，跟乙個同學賭錢1w年底2000粉的事情還有2周，求關注，不然得輸錢了.這個和...
如何做專案覆盤
前段時間，覆盤了一下自己所做的乙個專案，完成之後，所有人都覺得收穫很大，在這裡把經驗和做法總結一下。什麼是專案覆盤？覆盤，是乙個圍棋術語，也稱 復局 指對局完畢後，復演該盤棋的記錄，以檢查對局中招法的優劣與得失關鍵，這樣可以有效地加深對這盤對弈的印象，是提高自己水平的好方法。專案覆盤直白的講，其實就...
如何做技術積累
凡事預則立，不預則廢 定方向正確的規劃需要 眼界 敏感 運氣 準則拒絕夕陽產業 不做沒有積累的事情 如何學習 短期規劃 以考核週期為乙個時間參考 本質是多目標優化問題 晉公升 績效 生活 健康和成長的折衷 學習規劃和工作規劃結合 學以致用 理論聯絡實際 避免鄭人買履式的笑話 最低目標必須能夠輕鬆完成...