上周一时兴起写的技术团队管理笔记(一)-识人颇受大家欢迎，让我感到意外更觉得这个总结有意义，所以应当坚持下去，争取能整理出一个系列。

如果说这个系列有幸能成为一条技术管理的总结大路，则沿路的分支小道也会别有一番趣味。我会尝试在主思路整理的同时插入一些小的“甜点”，引出一些技术管理的小心得和小技巧，希望能够帮助到大家，期待更多的朋友能参与到讨论中，也帮助我规整思路。

今天要讲的小甜点是：技术管理者如何向上汇报

此处向上汇报的定义：技术管理者向其上的业务负责人的汇报，比如技术负责人向CEO汇报，技术总监向BU业务负责人汇报，技术经理向产品负责人汇报。

曾经我看到过很多技术管理者的向上汇报，是这样的：

制作了一个非常专业的技术架构PPT向上汇报，列举了业务架构，技术架构，部署架构，包含了当前使用的缓存，数据库，异步队列等细节，甚至还有各系统之间交互的时序图。汇报的目的是为了让大家理解当前技术的复杂度，从而希望获得更多资源的支持(比如招人和扩充服务器)。为了便于后续分析引用，我们简称为“专业技术PPT汇报”
经常身先士卒带领团队加班赶进度，为了让业务方意识到技术的辛苦，时常会拍摄团队加班的照片分享到朋友圈，期望老板看到并点赞。为了便于后续分析引用，我们简称为“朋友圈分享加班”
在产品需求讨论时，只要轮到技术这里发言，就尽量能说多细就多细，能说多复杂就多复杂，这个很麻烦要一周。这个不值得能否简化下需求，总而言之就是期望做到重视技术，以技术的意见为准，以后讨论产品需求一定要叫上技术。也利于控制好产品经理预期，为团队赢得一些空间。为了便于后续分析引用，我们简称为“产品需求讨论时突出技术”

其实这些做法都是有些问题的，在逐个分析修正之前。我们先依旧遵循理性分析的风格，来拆解归纳一下，作为技术管理者做向上汇报的目的到底是什么？

按照之前的经验，大概有3点：

获得更多的资源支持(人员招聘，服务器扩充，团队工作设备升级等等)
期望能在项目开始前更多地做好技术准备，便于后续工作（比如在需求还没有交付前就先做好一些准备，这样后续进度和质量都比较容易保证）
做到真正的“技术驱动”，以技术主导来开发出一些产品，比如搜索，信息流等（这个最难）

我们先抛开技术的这个专业限制，来看一下如果一个公司的市场部也需要向上汇报，目的是什么，如下：

获得更多的资源支持(人员招聘，市场投放资源支持等等)
期望能在产品推出前更多地做好市场推广准备，便于后续工作
做到真正的“市场驱动”，以市场主导来打响一些产品，比如脑白金（这个最难）

发现没有，之前有一种说法：技术部门的向上汇报相比其它部门的方式会比较特殊，其实是并不成立的，两者的目的都是一样的呀。如果碰到王兴，张一鸣这样的技术类CEO，那市场部门岂不是更苦逼？那美团的几万人地推团队是怎么建立起来的呢？

这里我们可以引出向上汇报方式的核心了：以结果为导向，说清楚技术团队需要什么资源支持，然后可以做到什么目标，为公司带来什么，即可

大家可以回想一下，你见过的市场部门是怎么和CEO向上汇报的？他们一般会这么说：我们期望能把今年的销售额提升30%，所以经过计算，我们需要500万的网络推广费用，分别用于微博100万，微信200万，其它200万。这真是一种简单有效的沟通方式，清晰的目标: 销售额提升30%，说清楚了要哪些资源：500万以及它的构成。

这才是向上汇报该有的方式，把你的团队想象成一个独立公司，把你的业务负责人想象成天使投资人。说清楚你需要多少资源能做到什么目标，他觉得有价值，自然会投你，不要让你的领导者帮你去想该怎么做。

我们回到前面的3个例子，逐个做出分析，如下：

案例	本来的目的	实际的效果
专业技术PPT汇报_____	说明当前技术的复杂和挑战，期望获得更多资源支持	业务负责人：你说的是啥啊，我一脸懵逼。哦，原来就是想招人，绕那么一大圈子，是不是要忽悠我啊？为啥所有开发都要换mac pro啊，真的能提升开发效率吗？
朋友圈分享加班_____	说明团队非常辛苦，期望不要逼太狠，理解技术兄弟们的苦	天天分享，不就是想让我点赞吗？你只是烦技术那点事，不知道其它业务部门也是焦头烂额吗？而且你们做的确实不怎么样啊，系统老是崩，天天加班也没看到产出啊？
产品需求讨论时突出技术_____	突出技术的重要性，产品以后不要忽视技术的意见，要以技术驱动	我们是产品，目前是关注需求对用户是否有价值，这个会怎么变成技术难度实现的讨论会了？而且讨论的时间特别长，算了，万一做不到就和CEO说技术做不到吧,和我关系也不大，公司缺这个功能也不会怎么样。不过讨论得还是挺累的，这种会以后要不要再让技术来参加啊？

很遗憾，作为技术管理者本意是希望大家更重视技术，为团队争取更多的资源，但是沟通汇报的结果反而导致了失去信任，失去支持。问题的症结在于：很多技术管理者还是只关注了前面两个字“技术”，而丢失了后面的“管理者”。一旦如此，就难免陷入到技术不被理解，技术很难说清楚，技术就是那么苦逼的思维怪圈中(哈哈，有一定代表性的程序员思维)，你忘了自己其实更是一个“管理者”啊！作为技术管理者，你应该关注的是“技术团队需要什么资源，然后可以为公司做到什么！” 仅仅就这么一条而已！什么技术氛围，工程师文化，slack协作工具，mac开发设备这些都只是你作为技术管理者的资源，你只要说得清楚，这些资源都能获得到。

继续以上面3个案例来举例，我们用“以结果为导向”的思维来修正，如下：

案例	修正方法
专业技术PPT汇报______	修改PPT，里面只包含：当前的技术架构分别需要多久来支持未来的几个潜在业务需求，当前团队的大致分工，行业其它竞品公司的团队配置，服务器配置。我们需要招多少人，增加多少服务器就可以帮助公司业务落地速度提升30%，稳定性保证到99.9%，且成本只有竞品公司的3分之2（你可能会说，是不是在逗我，提升速度还要那么高的稳定性，成本还要低？是呀，谁让你是管理者啊！任何部门的管理者，都是单一高压结果导向的，你做不到，就是你的能力不足啊，做啥管理者！）
朋友圈分享加班______	向上说明最近团队加班确实比较多，举例已经有些影响到系统的稳定性了。期望在这段时间忙完后，可以获得2周左右的修整期用于稳定系统，之后再接需求，可以保证提升开发效率15%和提升稳定性20%
产品需求讨论时突出技术______	这个功能的实现技术实现确实有些难度，大概需要2周时间且有一定的风险，麻烦产品同学评估下，如果确实是关系到用户体验的，我们就按这个计划来推进。另外能否说明一下这个产品的后续大致规划，我们可以在之前就做一些技术调研准备，便于加快落地。

这样的沟通方式首先完成了我们的首要目标“以结果导向，获得资源”，顺带让大家了解了技术团队的辛苦和对用户体验的坚持（你的小小私心在满足大目标后自然也能满足:)）

再补充一下，之前说的第3点“以技术驱动”，除了要做到上面说的“以结果导向”之外，还真需要你手里有些“活”。简单来说，需要有极强的技术能力和对商业逻辑的深刻理解，搜索引擎，新闻信息流，AI产品都是这类业务，这里只是一个简单扩展，不做深入讨论。

汇报时机这里也简单说明一下，在客观情况下，技术团队确实存在汇报时间不够的情况。大概有以下几个解决方式：

以结果为导向的周报
让技术团队里的更多人参与向业务方的汇报，而不只是你一个单点，增加火力的密度。好的领导者，应该培养出更多的领导者
找机会主动和你的业务负责人聊天，基于能为业务带来什么提升，来引出技术的需求

最后总结一下，对于一个好的技术管理者，向上汇报应当以“以结果为导向，说清楚技术团队需要什么资源支持，然后可以做到什么目标，为公司带来什么”。在制定目标结果时，应该尽量基于团队能力、业务价值、实施节奏3个维度来考虑，使用简单明了的数字是一个好的方法。

下一篇，我们将回归主线：技术团队管理笔记(二)-带人