技术领导力实战笔记
TGO鲲鹏会
100位CTO的真知灼见
立即订阅
14777 人已学习
课程目录
已完结 268 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 卓越的团队,必然有一个卓越的领导者
免费
第1讲 | 你的能力模型决定你的职位
第2讲 | 七位CTO纵论技术领导者核心能力
第3讲 | CEO实话实说:我需要这样的CTO
第4讲 | 技术领导者不等于技术管理者
大咖对话 | 从几个工程师到2000+个工程师的技术团队成长秘诀
第5讲 | CTO的三重境界
第6讲 | 像CEO一样思考
第7讲 | 要制定技术战略,先看清局面
第8讲 | 技术领导力就是“成事”的能力
大咖对话 | 未来技术负责人与首席增长官将如何协作?
第9讲 | CTO是商业思维和技术思维交汇的那个点
第10讲 | 创业公司CTO的认知升级
第11讲 | 最合适的技术才是最有价值的技术
第12讲 | 谈谈CTO在商业战略中的定位
大咖问答 | 打造自己的个人品牌,你也可以
第13讲 | 把脉高效执行的关键要素
第14讲 | 从零开始搭建轻量级研发团队
第15讲 | 定制高效研发流程
第16讲 | 培养中层团队的管理认知
大咖问答 | 发现下一个小米,不是只能靠运气
第17讲 | 团队成长要靠技巧和体系
第18讲 | 做到这四点,团队必定飞速成长
第19讲 | 将企业打造成一所终身大学
第20讲 | 论团队管理与共同升级
大咖对话 | 技术人真正需要的是升维思考
第21讲 | 绩效管理的目标不仅仅是绩效考核
第22讲 | 验证研发团队价值的绩效考核机制
第23讲 | 产品技术团队OKR使用法则
第24讲 | 996、987,程序员加班文化你怎么看?
大咖对话 | 技术管理者应该向优秀的体育教练学习
第25讲 | 建立有效的员工淘汰机制
第26讲 | 让细节的“病毒”感染你的团队
第27讲 | 如何在不同组织文化下推行技术管理
第28讲 | 业务高速增长期的团队管理:“知轻重、重绸缪、调缓急”
大咖对话 | 让团队成员持续的enjoy
第29讲 | 被80%的人误解的工程师文化
第30讲 | 关于工程师文化的六个问题
第31讲 | 五位技术领导者的文化构建实战
第32讲 | 文化是管理的那只无形之手
大咖对话 | 创业就是把自己过去的经验快速的产品化
第33讲 | 选对的人,做正确的事情
第34讲 | 打好技术团队搭建的基础
第35讲 | 做个合格的技术岗位面试官
第36讲 | “高潜力人才”的内部培养
大咖对话 | 如何高效管理8000+规模的技术团队
第37讲 | 技术创业该如何选择赛道
第38讲 | CTO要掌握的产品哲学:理性与人性的权衡
第39讲 | 从客户价值谈技术创新
第40讲 | 技术人投身创业公司之前,应当考虑些什么?
大咖对话 | 技术人创业前衡量自我的3P3C模型
第41讲 | 技术人创业前要问自己的六个问题
第42讲 | 团队激励之分配好你的奖金
第43讲 | 通过积分考核提升技术团队的绩效
第44讲 | 空降技术高管的“择业七计”
大咖对话 | 如何打造自我驱动型的技术团队?
第45讲 | 选好人生下一站——CTO空降上篇
第46讲 | 走出“至暗时刻”——CTO空降下篇
第47讲 | 空降领导者平稳落地要做的四道题(上)
第48讲 | 空降领导者平稳落地要做的四道题(下)
大咖对话 | 管理者是首席铲屎官?
第49讲 | 打造高效的研发组织架构:高效研发流程那些事(一)
第50讲 | 你的研发流程符合你的组织架构吗?谈高效研发流程那些事(二)
第51讲 | 聊聊研发流程管理中的那些坑:高效研发流程那些事(三)
第52讲 | 数据如何驱动研发高效运转?谈高效研发流程那些事(四)
大咖对话 | 对人才的长期投资是人才体系打造的根本
第53讲 | 如何打造高效且敏捷的组织文化?谈高效研发流程那些亊(五)
第54讲 | 打造高速运转的迭代机器:现代研发流程体系打造(一)
第55讲 | 用机器打造迭代机器:现代研发流程体系打造(二)
第56讲 | 有了敏捷开发,那交付期限去哪儿了?
大咖对话 | 项目成功的秘诀——技术产品双头负责制
第57讲 | 敏捷中的期限之殇,软件业该怎么做?
第58讲 | 如何打造个人技术品牌?
第59讲 | 技术演讲,有章可循
第60讲 | 正确对待技术演讲中的失误
大咖对话 | 不可替代的Java:生态与程序员是两道护城河
第61讲 | 刘俊强:技术最高决策者应该关注技术细节吗?
第62讲 | 张溪梦:技术领袖需要具备的商业价值思维
第63讲 | 未来组织形态带来的领导力挑战
第64讲 | 如何判断业务价值的高低
大咖对话 | 池建强:做产品不要执着于打造爆款
第65讲 | 如何打造高效的分布式团队?
第66讲 | 如何打造有活力、持续创新的研发团队?
第67讲 | 如何打造独属自己的工程师文化?
第68讲 | 如何打造一个自组织团队?
大咖对话 | 童剑:用合伙人管理结构打造完美团队
第69讲 | 茹炳晟:QE团队向工程效能团队转型的实践之路
第70讲 | 王昊:技术、产品、管理的不同视角
第71讲 | 王昊:什么样的人适合考虑管理角色
第72讲 | 创业公司如何招到合适的人才
大咖对话 | 以产生价值判断工程师贡献——读者留言精选
第73讲 | 用数据来分析管理员工
第74讲 | 为什么给了高工资,依然留不住核心员工?
第75讲 | 刘俊强:一本正经教你如何毁掉一场技术演讲
第76讲 | 内部技术会议的价值
大咖对话 | 韩军:CTO转型CEO如何转变思路
第77讲 | 陈晨:谈谈Instagram文化和文化背后的故事
第78讲 | 陈晨:团队重组过程中踩过的坑
第79讲 | 程军:从0到1打造高效技术团队的方法论
第80讲 | 马晋:技术Leader的持续成长
技术领导力实战笔记
登录|注册

第91讲 | 程军:打造高效技术团队之做事

贝壳研发总监、TGO会员程军 2018-09-20
你好,我是贝壳研发总监、TGO 会员程军。从我多年的实践来看,打造高效技术团队的关键就是招人和做事。
上一篇,我跟你分享了招人的那些事,包括招聘渠道和识人两个大方向。
其中,招聘渠道的关键是把人才需求分类,并根据不同的分类使用不同的招聘渠道,这样会获得更好的效果。而识人可以从知识、经验、能力、动力这四个模块出发,使用 STAR 法则、动力适配图等理论结合实践,快速提高自己的识人能力,找到合心意的人才。
众所周知,招人的核心原因是为了做事,所以,我今天就继续跟大家聊聊做事这个话题。

一、和业务心在一起

在我看来,团队必须要有一个共同的目标、可迭代的协作流程,以及统一的评价机制。
我之前在饿了么负责产品和研发落地,在实际执行中,我会先和业务负责人沟通好彼此做事的方法和节奏,最主要的是先确定下一个月的业务目标,然后产品和研发团队这边好确定产品的目标。
我们每个月都会集中过一次下个月计划落地的产品功能,如果业务方 OK,产品经理就会提前准备 PRD,这样至少可以让团队提前了解下个月的规划,研发和测试团队也能提前准备,有一个缓冲,应了那句古话“兵马未动粮草先行”。
如果碰到紧急需求,我们做法是紧急需求不需要排期,可以按约定砍掉一些 P0 需求。如果出现 P0 需求也砍不掉的情况,只能从灵活的组织能力出发,刚开始我们会从其他部门临时抽调人,后来的做法升级为在自己的团队中成立机动团队,这些人就是我们团队的特种兵,指哪打哪。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术领导力实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(1)

  • duan
            说到研发具有业务思维(我这里称为产品心吧),我曾经简单的将研发经理分为三个级别:三流的研发经理是产品经理说啥做啥;二流的研发经理是经常跟产品经理撕逼(经常说这那不行);一流的研发经理是和产品一心。
            研发要具有一颗产品的心,研发的价值如果不能体现在产品并作用在用户上,那有啥意义?如何具有产品心?1,首先最基本的,必须具有责任心,这是前提,质量出了问题,第一时间修复,要不将对用户公司造成影响损失。研发的功能/产品就是研发的娃,娃出了问题,亲爹不及时管?2,产品在需求评审的时候一定要注意说明我们为啥要做这个,要达成的目标(我想像一下,如当说到到一个功能能带来多少订单,多少转化,多少钱。。。的气候,产品是兴奋和激动的,研发测试也是激动的,大家都想跃跃欲试。),当功能上线一段时间/结束的时候,产品也要及时反馈结果数据,有问题要反思分析,是产品方案出了问题,还是质量出了问题,好的成绩大家一起分享庆祝。3,确定目标后,实现的方式有很多,产品不是神,提出的方式也不一定是最好的,大家同时也都是用户,从用户的角度,也可以去感受产品设计的好坏,及时提出自己的意见,作为合格产品肯定会认真听取大家的意见,并对各种意见取舍做出合理的解释。4,如果研发没有产品目标,只想完成任务了事,那质量肯定是一般的,过程中的困难都变成借口。当研发认可目标后,把被动变成主动,为了目标去想各种好的实现,想办法去更好的解决过程中遇到的问题,每克服一个困难都是值得和兴奋的。
            产品也需要有一颗研发的心,1,技术团队都有自己的天花板,方案的可行性和不同的方案的实现成本是不一样的,不要想当然认为什么都能做,多长时间能做好,方案和时间一定要和研发一起讨论确定。2,研发在考虑实现功能的时候还需要考虑性能,可用性,架构的优化等非产品的直接功能,这些都需要额外的时间,这些是长远的好处,如果不考虑,后面系统跪了,每天救火,得不偿失,系统设计不合理,后面响应需求越来越慢,这也是产品非常不想看到的,针对这个问题,需要延长需求完成时间或者专门的人优化或者每个迭代专门留有一定时间做技术优化,这都是逃不掉的成本和代价,看你怎么取舍。
             产品和研发需要同心,产品和研发是一条船上的人,大家是队友,不是敌人,只有同心协力船才能更快更好的驶向美好的远方。经常看到听到产品和研发撕逼,甚至干起来,我想其中有一点是各自缺了对方的那那颗心。还有一点就是需求变更,产品不是神,肯定有不合理的地方肯定会出现,这点产品首先要反思并和研发团队好好沟通,研发也需要多理解支持,大家都是为了更好的产品,大家最终目标是一致的,有些变更是被上级强加的或者其他原因等,团队可以考虑变更优先级,或者团队加班解决或者其他方式,总之这类问题要趋于收敛可控。
    2018-10-09
    4
收起评论
1
返回
顶部