作为技术负责人，我为什么做不好向上汇报

上周我的老板让我和产品负责人分别写一份汇报文档，把当前所有业务系统和团队情况做一个梳理和汇报。

我们的产品负责人的文档包含当前业务现状、业务系统融合情况、未来业务规划方向做了一个比较全面的介绍。

我作为技术的负责人，虽然对各个业务系统的架构、服务的拆分、微服务架构很熟悉，但是很显然我的老板并不想了解这些。而我本身跟业务又有些距离，对他们的规划也不够了解。再去照着产品负责人的文档去改一版，其实也没意义——既没新的信息，也没有新的视角。

所以，最后我从技术的角度分别对每个系统当前的融合情况和未来如何从底层数据融合再到服务代码融合做了一个很详细的说明。

可是，汇报当天，当我讲到第2个系统的时候，我的老板就已经很不耐烦了。

所以，今天想聊的是“作为技术负责人，到底应该如何做好汇报？”

问题出在哪？

其实我和产品负责人我们两个的整体方向是一样的，只是他写得更抽象、更聚焦业务价值，而我写得太具体、太落在细节上了。

在汇报这种场合，老板们更想听到的是：

• 当前业务的整体状态是什么？
• 系统融合对业务有什么价值？
• 下一步有哪些重要动作？风险点在哪里？
• 哪些地方还能优化或创造新可能？

而这正是我作为一个技术人最欠缺的表达能力，即对业务现状和未来规划没有那么清楚，也没能力根据系统情况做出产品层面的抽象。

是我能力不足吗？

坦白说，那天汇报完我挺受打击的，一度觉得自己是不是能力不行。但冷静下来想想，这不是“能力不行”，而是我在这方面没经过训练而已。

在以往的经历里，我就是老大，不需要向任何人做这种类型的汇报，所有的架构和规划都在我的脑子里，我可以很好的安排好技术架构的优化和需求的迭代，就是不需要写出这么一个给别人看的文档出来。

写这种文档，我既不知道如何组织文档的结构，也画不出来各种结构的图形来表示不同的业务逻辑。还记得上次看集团一个业务架构师的文档，上面画了一个很好看的图，它不仅好看，还能把各个系统之间的复杂交互关系讲明白。

说到底，时间花在哪，哪里就是好的。

如何改进

事实证明，我如果想要在这种规模的团队里待下去，就需要培养自己这方面的能力。否则即使我技术再好，说不出来、画不出来，也是白扯。

提升产品思维

我还是太聚焦技术了，自己一有时间就去琢磨系统架构。一直以为这是自己对技术的热爱和负责，但其实到我目前这个程度，再做这些事就是对自己的不负责、是给自己设限。为什么这么说呢？因为我已经设计过好几家公司的技术架构了，从最开始的网段划分、K8S搭建、服务部署和各种跨语言架构的设计等等，对我来说已经没有什么挑战了。

而我本身追求的也不是技术的深度，所以为了我自己未来更好的发展，我需要更有针对性的提高自己的产品思维。

多靠近业务

不管是技术还是产品，最终都是为了解决业务问题。所以接近技术和产品的需求最源头，可以让我们对技术和产品现状有一个更清晰的审视，才有可能设计出来更适应未来业务发展的产品和系统架构。

学会画

画图这个事情，我一直很排斥，因为真的太消耗时间了，尤其是在我经验有限的情况下。但其实人的大脑相对于长篇的文字，还是更喜欢看图这种结构化的内容。

好的图，是一种“结构性语言”。它不仅能让别人理解你的思路，更能让你自己看清问题的结构。后续不管是对上做汇报，对下做拆解，还是横向推动协作，图比文字都更有效。

最后

我前面提到“怀疑自己的能力”，这种怀疑有时候真的很致命。

你本来很熟练的事，一旦开始怀疑自己，反而容易越做越乱，最后搞得一塌糊涂。

所以，一定要相信自己。

尽自己所能去做，做到问心无愧，剩下的——就交给别人去评价吧。