技术同学如何做好向上管理

昨天抽空整理以前的工作笔记和绘制的思维导图，无意发现了一篇季度工作汇报的思维导图，如下：

由于当时负责稳定性相关的工作，因此汇报的内容主要集中在性能测试和稳定性保障领域。一直想写篇工作汇报和向上管理的文章，但都找不到一个好的切入点。今天借这篇文章，来聊聊我对于向上管理和工作汇报的一些经验和想法。

我对向上管理的看法

说句实在话，大部分人这一生其实都是在职场底层，向上管理的技巧方法其实学了也没多大用。

钱多不了多少，心思倒是费了不少。如果对职场没有太大的野心和晋升欲望，只要做好本职工作，不要把同事关系闹僵，日常沟通汇报不出问题就行了。

无论哪个行业，向上晋升的每一步都是一个坎，特别是互联网行业的技术岗位，凭自身能力就能摸到职场天花板。所谓的向上管理，更多是一种助力和锦上添花。相比于真正的管理岗位，技术反而是更好提升的，而且提升带来的收益更明显。

当然，职场嘛，大部分人的第一追求还是物质收入，向上管理的本质是一种期望管理，是个人价值诉求的主动传递。向上管理的关键，其实就是六个字：多沟通常汇报。这关键的六个字，同样包含一些能帮助你更好提升的技巧。

向上管理的方法技巧

有经验的技术同学对这几件事应该都不陌生：转正述职、晋升答辩、绩效评审、年度工作总结。从我的经验来说，技术同学特别是测试同学，在做向上管理的汇报时，可以从这几个方面去汇报。

需求吞吐量

技术同学的日常工作，就是将需求实现然后保质交付，需求吞吐量，可以看做是我们日常工作产出最基础的构成部分。当然，需求吞吐量也是可以度量的，比如参与了几个版本，具体的需求数量。

在度量或者汇报时候，可以用人/日这种工时的角度去度量，也可以用人/需求数这种方式。当然这种度量方式的前提是需求优先级划分和需求评审、工作量评估方面，团队内部有一个比较统一的认知。

线上交付质量

很多测试同学，或者很多公司在评估测试产出时，经常用 case 数量、bug 数量来评估工作产出，其实这样做其实完全背离了软件测试或者质量保障的初衷。

为什么要对软件系统进行测试？因为我们知道从需求设计到编码实现存在风险和不可控因素，这些不可控的因素会导致最终交付用户使用时出现问题，导致企业的业务目标或者商业价值不能很好的实现。

case 数只能说明测试工作做的是否细致，bug 数量只能说明需求设计或者编码质量存在不足。而线上交付的质量，才能证明这个版本或本次交付最终的价值是否实现。

线上交付质量，一般可以采用线上 bug 数量、资损量和故障定级来评估。当然，长期来看，也可以用线上缺陷收敛趋势来说明整体的交付质量是不断提升的。

研发过程效率

从软件工程的角度来说，影响交付质量的因素有三个：成本、范围和时间。

从企业的角度来说，成本肯定越低越好，无论是软硬件成本还是人力成本，而工作和需求的范围，在国内这种环境下，大部分企业的基层员工，是没办法改变上行下效的命令式范围的。能做的只能是加班或者提高单位时间内的工作效率。

工作效率的锚点，其实还是需求。在汇报时可以用同比或者环比的方式进行对比，表明自己的效率提升数据，通过什么方式，发现什么环节可以提升，最终提升的效率结果如何。

工具平台建设

近几年很多公司都在搞自研工具、平台建设，原因是什么呢？其实说白了，又产出，有事干，可以要资源，扩充团队人数，增加不可替代成本。当然，工具和平台是可以带来效率的提升，但在职场中沉浸久了的同学，肯定明白我在说什么。

还有一点，工具平台的建设，我个人认为不是要取代其他工具，而是为了打通部门或者流程墙，用更标准化和简单的方式来提高效率，减少重复造轮子的成本和内耗。

因此在汇报时，要注重工具和平台解决了什么问题，带来了什么提升收益。多讲价值和收益，少说技术方案和如何实现。

团队技术影响力

很多技术同学在工作中其实都忽略了技术影响力的建设，但这种影响力其实可以帮助我们在工作中更好的达成一些目的。简单来说，影响力可以增加个体或者团队的话语权，观点的受重视程度，便于工作更好的推进下去。

而影响力的建设，除了上述的几点硬产出之外，一些软性的工作建设也是必不可少的。比如：技术案例沉淀、技术博客输出、技术干货分享、最佳实践规范等。

向上管理的注意事项

上面讲到的一些方法，更适用于时间跨度更长的汇报，比如年度汇报、晋升述职。

而在日常工作中，向上管理的精髓在于这几点。

快速暴露风险：往小了说是避免背锅，往大了说是有责任意识和质量意识。

及时同步进度：让领导或者协同的部门团队知道你在做什么，当前的进度，是否和预期进度匹配。

表明当前难点：说困难说挑战，要资源要支持。

准备备份方案：很多时候领导更希望能看到更多的解决方案或者方法，而不是死磕一个方案孤注一掷。让领导做选择，而不是让领导进行思考。