项目汇报的正确打开方式

前几天接了个私活儿，帮一家 To B 企业为甲方的一个技术方案做在线支持和咨询答疑，其实就是根据甲方的需求，优化方案，然后做汇报，最终目的是为了签合同，达成交易合作。在分析甲方需求和优化方案过程中，和这家 To B 企业的技术同学交流了很多，颇多感触。

这篇文章，我想聊聊在日常工作中，关于汇报的一些想法和思考。

技术人的职场局限性

优化方案过程中，与对方负责技术方案和实施的同学沟通了很多，发现了几个很有意思的点。在为其他企业做技术咨询时，也遇到过类似的问题：

• 技术同学大多只专注于自己岗位所在的技术领域；

• 相比于全局的技术视野，技术同学大多更关注技术细节；

• 遇到超预期或者本岗位的技术挑战，很多技术同学就容易卡壳；

和一个技术大佬聊起这个话题，他也说道：很多找他咨询的技术同学，都是局限在自己会的那一块，没办法成体系的去思考和解决问题。这样很容易导致一个现象，就是职场瓶颈明显，上升空间和横向腾挪的范围太小。

在 IT 技术领域，现在的技术架构越来越复杂，一个项目会分很多岗位，对应的技术栈也是越来越细化。企业为了降低人员流动和替换的成本以及风险，也会将个人固定在一个狭窄领域的岗位上。虽然说现在很多工作都需要团队协同配合来推动完成，但这些协同沟通和推动的职责，在一个项目中往往也会有专门的项目经理或者少部分关键人员去负责。

客观来说，因为缺少机会去扩展自己的能力，大部分技术同学被限制在自己所在的狭小领域；主观因素来说，大部分人缺乏自主学习能力和向前一步的承担责任意识。长此以往，能力和所能创造的价值并没有随着年纪和经验增长而匹配递增，就导致了大部分同学所谓的职场“35 岁失业危机”。

项目汇报的正确打开方式

回到本文的重点：项目汇报。对技术同学来说，专注于技术，提升自己的专业技能以及利用技术解决问题的能力，是最基础也是最核心的能力。但工作并不仅仅是有技术能解决问题就能得到很好的结果，很多时候还受限于方案能否被采纳，自己的技术能力能否被放在更合适的位置上去体现自己的价值。这句话包含 2 点：

1. 方案能否被更多人认可采纳；

2. 能力是否被放在了合适的位置上；

一般在项目中，方案评审有多个角色参与，提出建议和指出不足，但最终是否采纳和认可，往往受限于能拍板的管理者。因此在设计项目方案时，要考虑到这几点：

• 基础因素：方案是否可行，是否能解决面临的问题；

• 加分因素：潜在风险是否有考虑到，是否有冗余措施；

• 决定因素：方案实施成本如何，领导是否听懂了，是否能解决更大范围的问题；

其中，基础因素主要考验技术同学的技术能力，加分因素则考验技术同学对团队和项目的了解程度，决定因素则是方案所能带来的价值。这个价值并不是解决多少 bug 或者提升多少性能，而是对项目或业务来说，能带来的可量化的预期指标。

我们都知道影响项目质量的因素有范围、成本、资源。技术同学往往考虑的是范围，因为这个决定了技术实现难易程度；而管理者更关注的是成本和资源问题，因为成本和资源投入多寡会影响预期收益，更进一步，影响管理者自己的能力体现和向上汇报。因此在项目汇报时，要重点体现出如下几点内容：

• 风险：潜在风险是什么，可能导致什么影响，应对措施是什么；

• 目标：业务目标是什么，技术指标有哪些，技术实现对业务带来的可量化价值；

• 实现：准备多套方案，罗列各自的优势和不足以及所需的资源，供管理者选择而不是判断；

• 收益：方案对业务、对团队带来了什么收益，比如：提高效率（降低成本）、降低资源投入（提升预期收益）；

总结一下，就是：成本和收益用明确的指标表明，并且指标一定要和业务价值挂上关系。