阅读 984

技术管理者如何向上汇报

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

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

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

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

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

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

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

按照之前的经验,大概有3点:

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

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

  1. 获得更多的资源支持(人员招聘,市场投放资源支持等等)
  2. 期望能在产品推出前更多地做好市场推广准备,便于后续工作
  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个维度来考虑,使用简单明了的数字是一个好的方法。

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

关注下面的标签,发现更多相似文章
评论