技术管理进阶——扎心了！老板问我：你们技术部和外包团队有什么区别？

原创不易，求分享、求一键三连

作为技术负责人一定会面临的几大难题：

1. 迭代速度真的不能再快了？
2. 工程、技术重构类项目的价值阐述？
3. 如何降本增效？
4. 如何在高管会上说人话，如何让其他部门不会认为我们是工具人？
5. 在高管会上，除了这个BUG我让人看下以及资源问题我去想办法外，还有什么可以聊的？
6. 可不可以不写需求？
7. 技术团队的价值如何量化？

偶尔老板们问的不专业但侮辱性更强：

我们技术部跟外包团队有什么区别呢？

一口气直冲脑门，忍着想怼他脸上的冲动，细细思量，你还真说不出区别，几个词在心中跃跃欲试：

自己心里都在打鼓，说出来大家又不买账，这不就很气人！

精明的资本家相信的是三方比价，实际做事又不愿意出那么多钱，所以多半时候这只是一次向上管理，他需要你给一个说辞，证明当前未必是最优但一定是最合适的选择；但如果过于拉胯PlanB也不会太远...

所以，作为技术负责人首先是有必要回答这类疑问，其次自己心理要真的有本账，比如：

1. 当前团队到底已经烂到什么程度了；
2. 当前团队最大的问题是什么；
3. 当前团队下一步该怎么发展；

这需要一个技术团队评价模型，或者说技术团队评价体系，这个是你心里的小九九，得有数！

上述问题很典型，首先尝试回答三个：

1. 你们与外包团队的区别到底是什么？
2. 如何反向管理迭代速度？
3. 如何做降本增效？

一般来说技术团队的工作是做项目，其工作产出物是代码，作为偏执行团队的评价指标一般是三个：

1. 过程指标，执行效率
2. 结果指标，交付质量

粗粒度的表格可以是这样的：

上述模型比较通用，有一个前提是：需求很清晰，并且不会改，稍微懂点事的同学都知道这无异于痴人说梦，所以真实执行的模型需要扩展：

外包团队最大的优势是成本低，但是对需求细化程度要求高；对需求更改次数容忍低，想要配合度高，那么得加钱！

另外一个情况是代码质量得不到保证，稳定性一块要打折扣，只要验收通过，如果线上出现事故，要积极也没问题，得加钱！

以上问题还是其次，外包项目最大问题其实是难以维护，可能是工程层面的原因，可能是意愿层面的原因，反正没有技术团队会愿意维护外包项目，至少我是绝对不干的！所以现在模型演化成了：

可以下一个结论：

外包团队适合做生命周期较短，需求明确的项目

以后老板再找你聊和外包有什么区别的问题，首先要知道他本质想问的是ROI的问题，你要给他算一本大账，并且积累几个外包成本高的案例，匹配给出这个模型即可。如果有团队承诺我都行，我都优秀，那老板多半是被仙人跳了...

迭代速度·呵呵

正所谓文武之道一张一弛，100天的工期，50天到底能不能做完？

当然能啊！但要看50天的定义是什么？不过是加班嘛...

需要注意，下面所有手法的使用一定要到逼不得已！，不可滥用！

只要近期业务方或者老板哪里在窃窃私语迭代速度四个字，不要犹豫，马上安排加班！

做什么不重要，按时发朋友圈很重要

上游的土鳖们，半年出不来需求，好不容易憋出来，居然想一个月上线，这显然不可能嘛。但不要拒绝业务方，就说我们尽量，我们尽力，然后不停朋友圈就好，最后该延期就延期。加班大法的运用有两点要注意：

1. 这个事情是不是值得一搏；
2. 是不是搏一搏真的能搞定；

如果不是，那就注意“节奏”，注意“分批”，注意“诉苦”，多年经验，言尽于此，听不懂也不多说了...

需求倒排，不可延期，所有的问题又到下游技术侧了？不要犹豫，马上哭诉！

需求不可延期不重要，MVP很重要

拒绝不了时间点那就拒绝工作量，非主干需求全部干掉，这里砍需求也是个艺术活，有几点要注意：

1. 这个需求能不能砍；
2. 你砍了这个需求，产品会不会砍你；

砍需求不能一刀砍到树干，还是要保证主流程的完善性，举个例子：

1. 权限功能莫有必要；
2. 后台功能先不上线；
3. 详情页面下期迭代；

最后，带着产品一起，不要完全自己决定，知情权要给出去。产研体系就是这样，需求没出来产品是爹，需求出来了技术是爹，要把握做爹时刻。

集中力量法

需求确实很急，也确实很有价值，怎么办？不用怕，让产品自己PK！

资源不够不重要，优先级很重要

需求有价值、时间且有限，那就集中力量办大事，告诉老板，当前只有停掉所有业务，全力支持需求才能保证按时按量上线，看老板怎么办咯。

不要自己决定，让老板决定，不要自己说服业务线，让业务线说服业务线

一旦真的走到这一步，那就只有一点需要注意：把他搞定...

夜半无人私语时

凌晨两点在高管群嗨，嗨什么不重要，聊聊近期产品迭代，聊聊开发过程中遇到的问题，发发加班照片，试试吧，挺招人“喜爱“的。

确实压力扛不住，半夜去问候CEO，跟他聊聊困难，聊聊规划，他回不回不重要，反正发出去就行了。

牺牲质量法

不多说，没好结果的，慎用...

撂挑子...

前面扯了不少犊子，真的到技术降本增效却是绕不开的话题，也是技术负责人不得不面对的问题，这里给一个具体case吧。

首先，当前团队的问题是什么？

我们这个场景很有意思，两个公司合并后，具体到技术团队居然有以下情况：

1. 两个团队初期规模300多人，当前两个APP同时维护；
2. A团队使用腾讯云；B团队使用阿里云；
3. A团队后端技术栈为Java；B团队后端技术栈是golang，还有部分php；
4. A团队APP体系之前可能放弃治疗了，居然使用的是原生+Flutter+Hybrid；B团队使用的原生+RN；
5. 前端体系Vue、React都在用...

真可谓是神仙打架啊！好在合并后人员还算充裕，可以各自安好，但去年行业不景气，技术侧也不好过，结果就是100人不到的团队要维护这个体系，我真的是佛了！

不考虑业务熟悉度、团队稳定性，单这个技术体系就很令人头疼了...

技术人员减少了，而服务规模未减少，在人员急剧减少的情况下需要研发侧从工程建设、团队管理、服务资源、需求控制等四方面进行降本增效的规划且同时还要稳固团队来保障业务稳定增长，所以怎么做呢？

团队合并、多技术栈、历史悠久，加上人员一大波流失，所有负面条件都占齐了，什么都想要注定什么都失败，所以可以得到第一个结论：

翻新老楼显然不可能

好消息是，合并回来的业务产品也走的差不多了，所以暂时做保守维护即可，新业务全部使用未来规划技术体系。所以这里的整体思路是：

维持老系统，重开新局

具体几个大决策是：

1. 统一云服务；
2. 统一DevOps等基础服务；
3. 统一前后端技术栈；
4. 其中一个APP只维护不迭代，有大的迭代就集中所有力量，全部推翻重来；

之所有做这些决策是因为资源确实有限，另外老业务年久失修，熟悉的人也不在了，也没有更好的办法，就当不破不立，先破后立吧！

光是你想还不行，至少还得说服老板与产品！

1. 让他们知道你有多难，那只会同情你不会支持你；
2. 告诉他将会获得什么好处，那么结果会有所不同；

这其实是一次向上汇报，可以用这个汇报结构：

比如说明问题严重性，不要光说现在有多少服务，每个人维护了多少个服务，做张表出来，技术栈问题也是：

问题清晰了，后续工作会更好继续。但由于专业性，最终他们的关注点会留到概览的项目列表，所以你需要清楚告诉他们：

1. 到底要做哪些事；
2. 做这事有撒好处；
3. 做这事有撒成本；
4. 做这事有撒风险；

具体到每个项目怎么做，他们听不懂也不会感兴趣了...

统一云服务与技术栈后，人员才能流动起来；把资源从老旧业务释放出来，才会有更多的人参与创新业务。

到一定阶段在看老旧业务的访问情况，比例低到一个数字后就全部关停。

最终当然是分给下面同学做实施啊，过段时间再说实施情况，有值得分享的实施细节再拿出来吧。

好了，今天的分享就到这，喜欢的同学可以四连支持：

想要更多交流可以加我微信：