内卷情况下，工程师如何汇报工作

系列文章

一、背景

上一篇讨论了工程师需要了解的项目管理，本篇打算讨论了一下工程师工作中如何汇报。实际上在笔者看来讨论的是职场沟通技巧。

试想一下这个场景，同组几个人参加一个会议，每个人轮流发言汇报，上司基于此进行提问，一个说的磕磕绊绊，没有条理，说了半天你都不知道他表达啥；另一个干净利落，条理清晰。

那么哪一个给人的感官比较好，让人第一印象觉得工作做的不错？相比是后一个。

当然回答磕磕绊绊的同学可能所做的工作并不差，甚至更好，但是没有表达出来，那么就不会取得最大的效果。如果上司是一个比较开明的人，会从多方向去验证，可能问题不大。如果不是这位同学就会减分了。

二、认识到沟通重要性

工程师们通常会有一个误解，我将代码写好就好了。或者我将性能优化好就好了，其他的我不关心。

这是一个非常错误的认知。

汇报也是工作的一部分，它也同样重要。

很多搞技术的同学属于相对内向，性格比较内敛的。但是性格内敛不代表着完全不与人沟通吧，工作还是一个讲究团队协作的地方，很多团队甚至会考核你的沟通以及团队协作能力。

技术大拿那么多，笔者没有见到那个技术大拿分享技术时，是磕磕绊绊条理不清的。所以这是一个职场基础能力问题。

其次不是所有的人都会盯着你的代码看，让人清晰的了解你的工作成果，也是这个工作的一部分。

三、先讲结论

任何汇报，先讲结论。

例如上司上周布置了一个任务，需要你去修复一个Bug，今天要汇报结果。

要怎么组织语言？你可以考虑这样说：

xxx，上周的Bug已经修复完成，将在xxx版本上线；【给出明确结论，以及时间表】

产生这个Bug的原因是xxx；【这里说明产生问题的原因】

后面我计划【这里给出后面的计划】

1. 全面梳理某个模块，确认没有此类Bug；
2. 做一个功能避免以后出现此类Bug；
3. xxx

上面的汇报基本包含了以下几点

1、先说结论

先明确这个Bug已经修复掉了。

别上来先说我排查A模块，然后排查了B模块，找A同学沟通了一下，找B同学确认了一下，找测试同学模拟了一下，最终找到了复现步骤，然后怎样怎样修复了这个Bug。

这些都不重要，可能这些可以体现你的思考过程，但是上司首先在意的还是你是否修复了这个Bug。他读了半天才看到结论，这样实际上就没有耐心了。所以汇报先说结论，给他一个确定的答案。

2、给出时间

说完结论后，也要给出上线时间。是今天晚上就可以上线，还是哪天可以上线。当你说出上线时间时，上司就会有一个预期什么时候这个Bug算是彻底解决掉了。

这里给出上线时间也要重要，如果是一个很严重的Bug，那么就要考虑是不是立即上线，尤其是关乎到收入的。影响收入的Bug，给出一个两周之后上线的时间，显然是不合适的。

3、酌情给出原因

可以基于实际需要给出产生这个Bug的原因。注意言简意赅，别长篇大论，上司估计也没有那么多的时间看。如果这个Bug存在影响范围，也可以在这里简单说一下影响了多少用户，损失了多少金钱。因为很可能你的上司也要向上汇报，他也需要这些信息。

4、给出后续的计划

这个是加分项，如果你给出这一点，证明你确实好好思考了，能够举一反三。修这个Bug的同时，是否还存在其他类似的Bug，也要排查一下。同时思考好能够做什么，避免再次发生此类Bug。

5、小结

综合上面的四点，个人认为已经比较完整了。有事情的结论，有事情的结束时间，有事情的产生原因，有后续的计划。上司看到这个安排大概率就不会追问了。

四、学会用数据说话

在汇报时要学会用数据说话，总是说一些漂亮话大家都会说，但是很容易让人产生怀疑。因为你在汇报自己的工作时，大概率不会自己贬低自己，很大概率会抬高自己。说一些好听的，但是这些如何让人信服呢，就要给出数据。

案例一

假设你做了一个开放服务，其他的业务可以接入来为自己的业务提效。那么此时你在汇报工作时要怎么说？

答案一： 我们上个月针对开放服务新增了哪些接口，满足了哪些能力（这里可能会详细介绍新增的接口）。目前有几个业务正在对接中，对接比较流畅顺利，暂无问题反馈，预计他们会在哪个版本上线等等。

答案二： 上个月我们将开放服务完善到95%，还剩余优先级较低的5%待完善。目前有几个业务正在对接中，当前业务对接好评率为90%，差评率10%，下个月我们会针对差评率推进以下几个措施等等。

以上答案明显是答案二较好，你说自己的开放业务做的好，对接流程比较顺利，都是比较虚的。当你给出数据时，就比较有说服力。好评率是多少？差评率是多少？差评的原因是什么？

案例二

你正在推进App内存优化，做汇报时怎么说？

答案一： 最近我们正在做内存优化，优化了进入XX模块内存飙升的问题，解决了多处内存泄露，如xxx模块，xxx模块。

答案二： App当前内存状态为平均内存xxM；线上内存泄露数量为xxx个，我们这个版本修复了多少处？还剩余多少处？预计什么版本全部修复掉等等。

两个答案版本答案二就比较有说服力，因为你说的比较具体，具体就有说服力。因为答案一，你只说了你修复了多少处问题，但是没有说当前是一个什么状态，App整体处于什么水平。实际上可能两个答案所做的事情是一样，表述不同，最终呈现的也不同。

五、时机很重要

1、汇报的时机

任何任务都是有时间点（deadline）的。

首先汇报结果一定是不能超过DeadLine，这点大家应该都没有什么异议了。超过规定的时间点，可以说是大大的减分了。

其次如果是一个长期复杂的任务，那么笔者建议可以考虑在过程中选取几个时间点，拿阶段成果物来汇报一下，同时汇报一下当前的进度，反馈一下当前是否存在风险。如果存在风险如实反馈，给出解决方案。

阶段性汇报可以给上司吃一些定心丸，你不会汇报上司都不知道当前是什么状态。尤其是周期较长的任务。

2、回复消息的时机

建议是能够立刻回的就立刻回，笔者见过以下几种做的不是特别好的。

• 等一下，我正在忙，稍后回复
• 立即回复了，但是言之无物，回复的信息毫无营养
• 看到了，但是很久之后才回复

这里笔者建议是能够立刻回复的，就立刻回复。

当然回复前要组织一下语言，要言之有物，别上来又问了一个问题，但是答案都在上司说的话中了，这就是一个无效的回复。例如上司询问【周五这个版本能否发】，你回复【周五吗？】。当然这里例子太傻了，还有一些需要总结一下信息就能得出的结论也别又问一次。虽然这里立即回复了，但明显没有用心。

如果是没有办法立即给出有价值的回复信息的，可以先说一下【收到，我整理一下信息稍后马上回复】。

3、布置任务时怎么回复

上次布置了一个任务，指定你去修复某某个Bug。如何回复上司的消息，你可以回【好】【嗯】【好的】【好的，收到】。

笔者建议是选择：【好的，收到】。同时能够给出这个事情的时间预期，这个时间预期可以依据优先级、重要性来判断。如果你认为这个事情没有那么紧急，没有关系可以大大方方的给出时间预期，说明你的理由。如果上司觉得这个时间预期不合适，会和你同步的。

六、总结

作为工程师编码能力依然是第一重要的，在职场中如何汇报，所体现的是个人的基础能力。如果个人掌握了很多职业技巧，实际上就已经超越一部分人了。汇报、项目管理等在笔者看来是一个职场专业性的问题，在职场就要有职场的态度，要体现出专业性来。

首先认识到汇报的重要性，其次学会先说结论，再说原因。如果有数据的话，一定要给出数据。掌握汇报的时机，汇报时注意按照优先级给出时间预期，事情结束给出后续优化计划。