工程施工人员招聘网站,wordpress移动模块位置,WordPress实现扫码登录,企业网站建设与推广范文3 月 23 日#xff0c;由高端技术领导者社交平台 TGO 鲲鹏会主办的 GTLC 全球技术领导峰会分站首站在北京举行。会上马蜂窝技术副总裁 \u0026amp; TGO 鲲鹏会会员张矗发表了主题为“我在马蜂窝的技术管理实践”的演讲。本文根据其演讲整理而成。大家好#xff0c;我是来自马蜂…3 月 23 日由高端技术领导者社交平台 TGO 鲲鹏会主办的 GTLC 全球技术领导峰会分站首站在北京举行。会上马蜂窝技术副总裁 \u0026amp; TGO 鲲鹏会会员张矗发表了主题为“我在马蜂窝的技术管理实践”的演讲。本文根据其演讲整理而成。大家好我是来自马蜂窝的张矗。在座的很多朋友可能都用过我的一些 APP2012 年我来到马蜂窝进行二次创业我的整个工作经历都是集中在互联网行业今天分享内容更多的适合在互联网领域其他领域的同学可以参考一下。
无法衡量就无法管理
无法衡量就无法管理这句话是管理学大师——彼得·德鲁克说的。其实后面还有一句话叫无法管理就无法改进它。今天分享的主题主要是关于技术研发人员在绩效考核上如何进行衡量、量化。
我的分享主要分为三个部分第一部分对技术研发人员绩效考核这个事情的难度在哪里第二部分在做绩效考核这个事情上要去做量化的绩效考核以及它的误区第三部分是在马蜂窝实践中所总结出来的一些思考。
绩效考核量化难于上青天
由于程序员工作性质很多时候工作无法进行量化那么对于技术管理者来说做好绩效考核量化就好比上青天。那么想要做好量化应该从哪几个方面出发呢
1、创造性工作
首先我们需要意识到自己所做的工作本质上是创造性工作、脑力劳动。脑力劳动是需要思考的是需要灵感的可是你的个人情绪、工作节奏、团队状况都会影响整个团队的产出你也不知道灵感什么时候能够迸发创造性的工作在互联网领域其实是需要很多的试错试错的成本也是很难预估的。
2、黑盒
技术研发的很多工作成果其实是一个黑盒。我们都知道用一些功能性的黑盒进行测试但你并不知道黑盒后面真正发生了什么。同样是一个列表页过去可能是排序但今天可能变成推荐算法工作量是不可同日而语的。
如果我们想用白盒测试那么将会给成本带来很大的提升。有一个经常发生的现象如果你是用外行考核内行的时候黑盒效应会更加明显。
3、经验量化
经验对互联网行业中的工程师来说作用是非常巨大的。举个例子就像外科手术有经验的大夫一刀下去有问题的组织会给你清理得干干净净并且术后对于病人的生活质量是有很大的保障和提升没有经验的大夫可能会下刀更多也没有清理干净如果要让病人接受这样的手术还不如不动手术这个类比放在代码重构是特别典型的事情。经验这个事情也很复杂因为它很可能是局部的你只是对某个领域有经验而已并且它也是不稳定的可能这一刀还可以下一刀未必行。
4、时间管理
时间管理对于工程师的工作产能来说是非常重要的。很多工程师和设计师每天都会因为各种会议、面试以及需求不断地被打扰大家都身处其中谁催得着急一些那我就优先做谁的工作只有到夜深人静的时候才能做一些自己真正想做的事情。那么不擅长于掌握时间管理的工程师经常会陷入应激式工作的方法而不是统筹式工作的方法。这种多任务的工作一件任务没有完成另外一件任务接踵而来会给心里形成一个巨大的压力本质上是会造成崩溃的并陷入绝望的状态工程师应该都很清楚多任务系统切换起来效率影响也是巨大的。
5、协作
工程师很多时候也不是独自孤立地在工作他需要与产品、设计师、测试、商务人员、销售共同完成互联网作品的呈现。在这个过程中需要彼此间具有同理心互相去理解对方帮助对方弥补思维的缺陷最终完成这件事情。在这个过程中你很难去比较谁的贡献更大谁的工作更多而且这里面还有不少很重要的岗位以及它们还具有年龄的差异。
现在我们看各种发布会时会发现不少 90 后的产品经理已经上位了。相信今天来到本次 GTLC 全球技术领导力峰会北京站的参会者大多还是 80 后、85 后的技术管理者可能有些在场同学已经开始着急如何与 90 后产品经理一块 PK 了这件事情已经发生了如果你一味的忧愁可能会让事情变得更加复杂。
技术工作量化的误区有哪些
1、代码行数大部分朋友都知道在技术工作量化上第一个误区是代码行数。当前我们常常对工程师提出要求——把代码写得精简易读但有些“经验丰富”的工程师仍然很容易地在代码里加入很多没用的东西或者是用工具实现代码行数的增加以此来体现“彰显”工作量。
2、BUG 数量大家会觉得考察 BUG 数量也不是一个好的方法虽然在实践过程中会不断地提出来用 BUG 数量进行考核但当你真正用 BUG 数量考核时通常会形成很不好的引导。因为很可能会出现工作越多BUG 数量就会越多的情况从长期来看这样的引导是无法激励大家爆发出更大的潜力。
3、项目完成时间项目完成时间的考核方法具有一定的迷惑性。我们大多都喜欢把项目提前完成的团队但项目完成时间通常是由项目执行者来决定的。如果用项目完成时间来考核大家我们一定会使用保守估计时间的方式为自己留一段时间缓冲。
4、潜力\u0026gt;产出
2018 年我加入 TGO 鲲鹏会时在一次分享中搜狐的高琦老师高琦搜狐高级技术经理 \u0026amp; TGO 鲲鹏会会员讲解燃尽图时从敏捷的角度看燃尽图是一条倾向于直线的角度如果我们倾向于把项目的预估时间和实际预估时间趋于此用它们作为考核也会很有问题。
总结来看我们希望考核是激发大家更大的工作潜力而不是引导大家回归工作或者是逃避问题。
关于马蜂窝技术工作的绩效考核思考
明白了难度和误区那么这些年里我又产生哪些思考呢
1、关注目标而不是任务
我曾经工作的第一家公司也实施过 KPI但是我觉得是非常失败的。因为它像一场运动我完全预料不到结果就这么过去了。
而在上一家公司我们用到了 O目的G目标S策略M衡量和检测的方法这个方法实施得相当不错其中最核心的部分是 O 和 G 的制定过程再到 S 和 M 的拆解但 OGSM 的方法在互联网圈没有 KPI 和 OKR 这么流行因此大家了解得也不多。
最近一两年马蜂窝事业部也开始尝试使用 OKR 的方式进行绩效考核。因为 OKR 大家都比较了解并且 OKR 的概念已经存在了很长时间现在又不断地被提出来去年起百度也是全面开始转向 OKR。
由此我想到了如何量化我们的绩效指标上相当重要、熟悉的一个话语关注目标而不是任务。我们经常说我发布了什么启动了什么创建了什么上线了什么这些都是任务而不是目标。目标应该是我将某某指标从 X 转变成了 Y只有这样才是目标目标应该是可量化的。
举一个内部的例子给大家分享一下在马蜂窝内部有很多的员工使用的系统如 OA 系统、企业邮箱、代码管理以及各个事业部他们自己运营的系统这些对于员工来说是相当复杂的需要去记住每个系统的密码以及我需要在哪一处登录。为了给大家提供一个更加安全、便捷的登录方式我们计划去打造统一登录的 SCS 系统并且把所有第三方的系统和我们自己研发的系统的登录都要切换到统一的登录系统中。
一开始我们团队认为只要完成系统研发任务就完成了可我们的目标并不是去研发一套 SCS 系统而是要将没有使用 SCS 的系统从 50 个减少为 3 个以此达到安全和便捷的目的但是我们一开始并没有注意从目标出发。在完成研发任务的过程中团队也解决了很多的问题包括一开始没有想到的场景以及思维转化的过程。渐渐地研发统一登录的 SCS 系统变得不是重点了而变成我们要去切换某个系统推进第三方研发这样的转化使得我们的工作成果变得更有实际意义。
马蜂窝对于团队的要求是不光要求你会写代码还需要具备沟通协调的能力以及规范的能力。我们可以看看业务团队或者支持业务团队的研发团队他们的指标需要去确定业务团队的目标就是整个团队的目标业务团队的目标就应该成为支撑这个业务团队和研发团队的主要目标。
有一种声音会说业务团队的目标完成好或者不好有些时候跟研发一点关系都没有这会让我们形成阶段性的短视现象我们更应该从长期来看它是否有更公平和有效的方法。但短期误判也是倒逼我们审视业务团队和目标很重要的方法因为团队是需要长期投资才能看到价值。比如说管理团队我们也需要帮助他们找到一些可量化的目标这个可量化的目标包括系统的稳定性标准、性能维持标准员工满意度标准等。
2、平衡
主要的方法确定了我们也需要加入一些平衡的因素来解决我们实际操作中的困难那么我们该如何平衡呢只关注业务的目标确实会形成短期的现象如团队贡献、考勤但这两个目标都具备一个特点它是一种阶段性的状态它会阶段性的好或者是不好。
如团队贡献你这个月在团队内部做了一个分享你可能就拿到团队贡献你帮助这个团队组织了一次团建你也具备这样的团队贡献。再比如考勤并不是让大家给自己的兄弟们上下班打卡它可以带着主观的因素你可以观察谁经常迟到早退这是你能感受到的主观印象你也会感受到有些人天天为了项目加班到很晚。这个过程你还需要识别有一些同学他是天天加班的是为了混一个晚餐或者是打车费这个鉴别还是比较容易的。
找平衡的过程也是把我们管理者的主观判断落实在客观标准的过程团队中我们都会喜欢在群里积极回答别人的问题乐于给大家做分享的同学他们对团队的氛围贡献是非常有帮助的因此更应该在团队贡献上拿到更多的分数。
有的同学会说把个人成长、学习能力、解决问题的能力这样的因素纳入到绩效考核的指标上来但是我认为这是不妥的。个人成长这个事情很难衡量这个月我看了一本书叫《成长》在书中作者提到他将能力范畴指标与成绩晋升和基础薪资挂钩会显得更有效一些。
3、层级区分
当你跟团队成员设计目标的时候一定要关注他当前所在的层级。初级工程师按时完成工作、写好代码、完成测试以及做好文档的编撰就是他的目标那你要从这个方向上想好怎么给他量化
稍微有一些年限的工程师需要做好架构设计、规避项目的风险那么你可能需要从这些方面给他做好设计
更资深的工程师或者是技术经理位他需要做到判断需求的轻重缓急做好项目的安排以及项目上线后的跟踪和整个状态的反馈。
总之对于越是高级的人员他的绩效考核越是要跟业务 KPI 关联起来当给他设计目标的时一定要想他的目标对他的上级、部门、公司、用户和社会的意义和价值所在。
现在我们能看见有很多工程师他的专业技能已经达到了高级的水平但是在理解上级目标确定自己的目标或者是行动还没跟上。“巨婴”就是指需要哄着才能干活的程序员。比如我们上线一个新的功能大家在上线前也都很努力为了完成任务加班熬夜终于在深夜把这个项目推上线但上线后很多工程师没有对新的数据表现和用户行为做跟踪。现在大家的分工越来越细很多这样的活都是产品经理或者是公司帮助你那么这样的工程师必然沦为螺丝钉。
我们只有不断拓宽自己的眼界提升自己的视野才能使我们不断从初级向高级进化。
4、评估周期
最后一点思考就是对于评估周期的思考。我们都很希望上级能告诉我未来一个季度该做些什么工作。举个例子比如某个团队会支持很多客户的工作但是他只知道我当前有这样的事这个月差不多能干完接下来两个月该干什么还不太确定。这时我给大家的建议是不妨把考核的周期缩短按月来考核。考核的内容包括这个月实际做的工作实际支持的客户的成果等。或者你也可以对下个月的挖掘作为考核指标不超过三个月进行一次考核。在互联网领域里三个月一次考核我认为也是上限当你对未来不是那么确定时不妨缩短考核周期。
总体来看想要通过业务量化研发人员的工作我们首先是完成思维转化这样的转化对那些具有综合能力的研发人员或综合能力比较强的研发人员更有利的对于管理者来说你要思考如何用其他的方法来确保搞钻研的科学家们不会被亏待以此确保你的长期利益和短期利益的平衡最终才能达到长期利益的最大化。
最后我们再回到关注目标这个词如果大家在关注目标实践关注目标这个事情碰到一些困难时我也给大家提一个建议你可以多想想老板都在想什么谢谢大家。
嘉宾介绍张矗马蜂窝技术副总裁TGO 鲲鹏会会员拥有 10 多年的互联网技术和管理经验。2000 年加入新浪网2007 年作为联合创始人参与创建开心网2012 年加入马蜂窝旅游网担任技术副总裁并拥有北京理工大学工学硕士学位。TGO鲲鹏会是极客邦科技旗下高端技术人聚集和交流的组织旨在组建全球最具影响力的科技领导者社交网络线上线下相结合为会员提供专享服务。目前TGO鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800 名60% 为 CTO、技术 VP、技术合伙人。
会员覆盖了 BATJ 等互联网巨头公司技术领导者同时阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀成为 TGO 鲲鹏会荣誉导师。
如果你想和这些优秀的科技领导者们一起前行欢迎参加「GTLC 全球技术领导力峰会 」。
