技術管理進階——扎心了！老闆問我：你們技術部和外包團隊有什麼區別？
原創不易，求分享、求一鍵三連
作為技術負責人一定會面臨的幾大難題：
- 迭代速度真的不能再快了？
- 工程、技術重構類專案的價值闡述？
- 如何降本增效？
- 如何在高管會上說人話，如何讓其他部門不會認為我們是工具人？
- 在高管會上，除了這個BUG我讓人看下以及資源問題我去想辦法外，還有什麼可以聊的？
- 可不可以不寫需求？
- 技術團隊的價值如何量化？
- ...
偶爾老闆們問的不專業但侮辱性更強：
我們技術部跟外包團隊有什麼區別呢？
一口氣直衝腦門，忍著想懟他臉上的衝動，細細思量，你還真說不出區別，幾個詞在心中躍躍欲試：
- 響應快；
- 服務好；
- 質量佳；
- 成本低；
- ...
自己心裡都在打鼓，說出來大家又不買賬，這不就很氣人！
精明的資本家相信的是三方比價，實際做事又不願意出那麼多錢，所以多半時候這只是一次向上管理，他需要你給一個說辭，證明當前未必是最優但一定是最合適的選擇；但如果過於拉胯PlanB也不會太遠...
所以，作為技術負責人首先是有必要回答這類疑問，其次自己心理要真的有本賬，比如：
- 當前團隊到底已經爛到什麼程度了；
- 當前團隊最大的問題是什麼；
- 當前團隊下一步該怎麼發展；
- ...
這需要一個技術團隊評價模型，或者說技術團隊評價體系，這個是你心裡的小九九，得有數！
上述問題很典型，首先嚐試回答三個：
- 你們與外包團隊的區別到底是什麼？
- 如何反向管理迭代速度？
- 如何做降本增效？
評價模型
一般來說技術團隊的工作是做專案
- 成本指標
- 過程指標，執行效率
- 結果指標，交付質量
粗粒度的表格可以是這樣的：
上述模型比較通用，有一個前提是：需求很清晰，並且不會改，稍微懂點事的同學都知道這無異於痴人說夢，所以真實執行的模型需要擴充套件：
外包團隊最大的優勢是成本低，但是對需求細化程度要求高；對需求更改次數容忍低，想要配合度高，那麼得加錢！
另外一個情況是程式碼質量得不到保證，穩定性一塊要打折扣，只要驗收通過，如果線上出現事故，要積極也沒問題，得加錢！
以上問題還是其次，外包專案最大問題其實是難以維護，可能是工程層面的原因，可能是意願層面的原因，反正沒有技術團隊會願意維護外包專案，至少我是絕對不幹的！所以現在模型演化成了：
可以下一個結論：
外包團隊適合做生命週期較短，需求明確的專案
以後老闆再找你聊和外包有什麼區別的問題，首先要知道他本質想問的是ROI的問題，你要給他算一本大賬，並且積累幾個外包成本高的案例，匹配給出這個模型即可。如果有團隊承諾我都行，我都優秀，那老闆多半是被仙人跳了...
迭代速度·呵呵
正所謂文武之道一張一弛，100天的工期，50天到底能不能做完？
當然能啊！但要看50天的定義是什麼？不過是加班嘛...
需要注意，下面所有手法的使用一定要到逼不得已！，不可濫用！
加班大法
只要近期業務方或者老闆哪裡在竊竊私語迭代速度四個字，不要猶豫，馬上安排加班！
做什麼不重要，按時發朋友圈很重要
上游的土鱉們，半年出不來需求，好不容易憋出來，居然想一個月上線，這顯然不可能嘛。但不要拒絕業務方，就說我們儘量，我們盡力，然後不停朋友圈就好，最後該延期就延期。加班大法的運用有兩點要注意：
- 這個事情是不是值得一搏；
- 是不是搏一搏真的能搞定；
如果不是，那就注意“節奏”，注意“分批”，注意“訴苦”，多年經驗，言盡於此，聽不懂也不多說了...
砍需求法
需求倒排，不可延期，所有的問題又到下游技術側了？不要猶豫，馬上哭訴！
需求不可延期不重要，MVP很重要
拒絕不了時間點那就拒絕工作量，非主幹需求全部幹掉，這裡砍需求也是個藝術活，有幾點要注意：
- 這個需求能不能砍；
- 你砍了這個需求，產品會不會砍你；
砍需求不能一刀砍到樹幹，還是要保證主流程的完善性，舉個例子：
- 許可權功能莫有必要；
- 後臺功能先不上線；
- 詳情頁面下期迭代；
- ...
最後，帶著產品一起，不要完全自己決定，知情權要給出去。產研體系就是這樣，需求沒出來產品是爹，需求出來了技術是爹，要把握做爹時刻。
集中力量法
需求確實很急，也確實很有價值，怎麼辦？不用怕，讓產品自己PK！
資源不夠不重要，優先順序很重要
需求有價值、時間且有限，那就集中力量辦大事，告訴老闆，當前只有停掉所有業務，全力支援需求才能保證按時按量上線，看老闆怎麼辦咯。
不要自己決定，讓老闆決定，不要自己說服業務線，讓業務線說服業務線
一旦真的走到這一步，那就只有一點需要注意：把他搞定...
夜半無人私語時
凌晨兩點在高管群嗨，嗨什麼不重要，聊聊近期產品迭代，聊聊開發過程中遇到的問題，發發加班照片，試試吧，挺招人“喜愛“的。
確實壓力扛不住，半夜去問候CEO，跟他聊聊困難，聊聊規劃，他回不回不重要，反正發出去就行了。
犧牲質量法
不多說，沒好結果的，慎用...
終極大法
撂挑子...
降本增效
前面扯了不少犢子，真的到技術降本增效卻是繞不開的話題，也是技術負責人不得不面對的問題，這裡給一個具體case吧。
首先，當前團隊的問題是什麼？
背景介紹
我們這個場景很有意思，兩個公司合併後，具體到技術團隊居然有以下情況：
- 兩個團隊初期規模300多人，當前兩個APP同時維護；
- A團隊使用騰訊雲；B團隊使用阿里雲；
- A團隊後端技術棧為Java；B團隊後端技術棧是golang，還有部分php；
- A團隊APP體系之前可能放棄治療了，居然使用的是原生+Flutter+Hybrid；B團隊使用的原生+RN；
- 前端體系Vue、React都在用...
- ...
真可謂是神仙打架啊！好在合併後人員還算充裕，可以各自安好，但去年行業不景氣，技術側也不好過，結果就是100人不到的團隊要維護這個體系，我真的是佛了！
不考慮業務熟悉度、團隊穩定性，單這個技術體系就很令人頭疼了...
技術人員減少了，而服務規模未減少，在人員急劇減少的情況下需要研發側從工程建設、團隊管理、服務資源、需求控制等四方面進行降本增效的規劃且同時還要穩固團隊來保障業務穩定增長，所以怎麼做呢？
巨集觀診斷
團隊合併、多技術棧、歷史悠久，加上人員一大波流失，所有負面條件都佔齊了，什麼都想要註定什麼都失敗，所以可以得到第一個結論：
翻新老樓顯然不可能
好訊息是，合併回來的業務產品也走的差不多了，所以暫時做保守維護即可，新業務全部使用未來規劃技術體系。所以這裡的整體思路是：
維持老系統，重開新局
具體幾個大決策是：
- 統一雲服務；
- 統一DevOps等基礎服務；
- 統一前後端技術棧；
- 其中一個APP只維護不迭代，有大的迭代就集中所有力量，全部推翻重來；
之所有做這些決策是因為資源確實有限，另外老業務年久失修，熟悉的人也不在了，也沒有更好的辦法，就當不破不立，先破後立吧！
說服老闆
光是你想還不行，至少還得說服老闆與產品！
- 讓他們知道你有多難，那隻會同情你不會支援你；
- 告訴他將會獲得什麼好處，那麼結果會有所不同；
這其實是一次向上彙報，可以用這個彙報結構：
比如說明問題嚴重性，不要光說現在有多少服務，每個人維護了多少個服務，做張表出來，技術棧問題也是：
問題清晰了，後續工作會更好繼續。但由於專業性，最終他們的關注點會留到概覽的專案列表，所以你需要清楚告訴他們：
- 到底要做哪些事；
- 做這事有撒好處；
- 做這事有撒成本；
- 做這事有撒風險；
具體到每個專案怎麼做，他們聽不懂也不會感興趣了...
結果預測
統一雲服務與技術棧後，人員才能流動起來；把資源從老舊業務釋放出來，才會有更多的人蔘與創新業務。
到一定階段在看老舊業務的訪問情況，比例低到一個數字後就全部關停。
最終當然是分給下面同學做實施啊，過段時間再說實施情況，有值得分享的實施細節再拿出來吧。
好了，今天的分享就到這，喜歡的同學可以四連支援：
想要更多交流可以加我微信：