上周一时兴起写的技术团队管理笔记 (一)- 识人颇受大家欢迎, 让我感到意外更觉得这个总结有意义, 所以应当坚持下去, 争取能整理出一个系列.
如果说这个系列有幸能成为一条技术管理的总结大路, 则沿路的分支小道也会别有一番趣味. 我会尝试在主思路整理的同时插入一些小的 "甜点", 引出一些技术管理的小心得和小技巧, 希望能够帮助到大家, 期待更多的朋友能参与到讨论中, 也帮助我规整思路.
今天要讲的小甜点是: 技术管理者如何向上汇报
此处向上汇报的定义: 技术管理者向其上的业务负责人的汇报, 比如技术负责人向 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 个维度来考虑, 使用简单明了的数字是一个好的方法.
下一篇, 我们将回归主线: 技术团队管理笔记 (二)- 带人
来源: https://juejin.im/post/5c31f4b4e51d455243762c3a