技术管理案例课
许健
eBay 基础架构工程研发总监
21440 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 28 讲
技术管理案例课
15
15
1.0x
00:00/00:00
登录|注册

24 | 技术决策(3):持续跟进进度,执行细节决定成败

思考题
通过关键细节做人员选育
持续跟进的注意事项
关键细节如何把握?
做完决策就可以了吗?
技术决策的执行问题

该思维导图由 AI 生成,仅供参考

你好,我是许健。今天我们来聊一聊技术决策的执行问题。
我在人才招聘中讲了招聘的时候要追问细节,在进阶心路里提到二线经理要下沉两个汇报级别到一线了解细节,在危机管理中还提到过我自己被架空的一个重要原因是没有深入到日常的团队运营中去,本质上就是没有去了解关键路径的关键细节。
为什么我一直这么强调细节呢?因为我自己经历了好几次教训,追根溯源才发现都是因为忽视了细节,准确地说是对关键路径的关键细节不够重视。
今天我想跟你聊的就是技术经理如何把控细节,如何通过技术细节交付好业务,培养好人才。

做完决策就可以了吗?

首先,我们做完决策就可以了吗?答案是否定的。
我看过一本叫《执行》的书,里面有这样一段话:“这样做领导当然舒服喽,你只需要站在一旁,进行一些战略性的思考,用你的愿景目标来激励自己的员工,而把那些无聊的具体工作交给手下的经理们。我在这里要提出的是,这种思考问题的方法是错误的,它很可能给你带来难以估量的危害。”
我对这句话深有体会。做决策只是起点,如果止步于此,等于空谈,为什么这么说呢?如果我们觉得决策做完了就万事大吉,那么常常就会有这样的后果:
第一,是经理自己被架空。哪怕我们通过决策把工作优先级聚焦到了核心问题,但决策落地最后还是要靠执行的。如果不能把握关键细节,完整地跟进进度,经理就容易把自己架空。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文强调了技术经理在决策执行中的关键作用,以及如何把握关键细节来确保执行达到预期效果。作者指出,决策只是起点,而持续跟进和关注关键细节才能确保项目顺利交付。文章提出了三种方式来把握执行细节:制定可衡量的阶段性目标、定期的项目评审和周报、以及不定时地找团队一线骨干做深入了解。此外,作者还强调了持续跟进的注意事项,包括线性思维、对决策和自身角色的认识等。这些方法和注意事项有助于技术经理在执行决策时更好地把握关键细节,确保项目顺利进行。文章还强调了技术经理作为执行者的重要性,需要持续重视并解决困难,同时提倡早期暴露问题,通过实践历练来应对未知挑战。整体而言,本文提供了实用的技术管理经验,强调了决策执行的重要性和技术经理的关键作用。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《技术管理案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(5)

  • 最新
  • 精选
  • Weehua
    问题1,我最开始带团队的时候,团队只有两个人,当时在做第一个项目的时候,我并没有去review细节,而且甩手掌柜,项目很重要,是我们部门的第一个对外合作项目,两周开发时间。后来到了第二周的时候,一个小伙伴私底下告诉我另一个小伙伴的代码质量很差,感觉不能被信任,处于对结果的保证,我们沟通下来是他把另一个人的工作也都做了,加班做了!最后成功交付,但几乎90%的工作都是他自己搞定的!后来想想,我最为技术领导,这么点工作都没有跟踪到细节,而且是工期过了一半才发现,还是下属反馈的!确实不知道当时我在干啥!吸取经验教训,半年以后,团队大了,人多项目多了,我对于新人或者重要的项目重要的功能,全部抽空review,发现问题及时反馈及时让下属解决,这才保证了项目质量。 问题2,我感觉给更多的压力不一定能解决问题!除非上级认为经理没把事情做好是因为没有认识到事情的严重性,给更多压力可以逼经理重视问题的严重性,想办法去解决!如果问题的原因是没有抓住重点,其实给予一些指导可能会更有效果!

    作者回复: 问题一, 我觉得你做的很好了。到了二线经理以后,我现在能做到的是review 项目,但是我后来发现这样不够,我还得去看看customer support. 这些我还是可以覆盖的,代码层次,我会让一线的人给我看他们的测试用例。但是我已经很少坐下来很仔细的跟大家一起做code review 了,这一点是个遗憾,除非我能进一步优化时间管理,比如一些效率不高的会议就不要去了。我装了一个rescue time 的app. 问题二:对的,我觉得大家要知道自己的部下不是傻子,一定有具体的困难,二三线领导应该切实解决下属的困难。

    2020-10-24
    2
  • 此方彼方Francis
    “如果我在项目评审和周报里只听到好消息,从来听不到困难和坏消息,我就会给自己提一个醒:这么重要的事情,在执行过程中这么一帆风顺正常吗?” 类似的,在开发一个复杂功能的迭代中,如果bug数量比较少,我也会在心里反问自己一句:代码质量真的这么高?

    作者回复: 能量守恒,要么就是你真的花了大力气在事前的Test Coverage , CICD 上面。肯定不会无缘无故就形势一片大好。

    2020-10-20
    1
  • Ke
    严厉 - 看人的吧。皮猴子需要严厉,本身很谦卑open mind的人你不需要严厉他也能听进去。

    作者回复: 骨干级别都不低,皮猴子很少,人要真诚,话要到位。我觉得大多数时间客客气气的,也不能总是客客气气的。但这不是“术”,不是技巧,没有刻意为之。

    2022-01-03
  • 我能走多远
    说一下个人执行细节的案例吧! 上家公司没有完善的项目管理流程,导致项目交付质量差,体现在开发因方案频繁变更导致交付延期;代码review过程中提出新的解决方案要求开发重新修改;交付项目没有自测报告及影响点;项目上线后没有和测试对齐等等。 我做的几个项目都是严格按照项目交付流程,设计分析会拉上技术经理及相关模块责任人一起分析方案的优劣点及影响性,一些设计细节也都会带上;避免了代码review阶段的返工。有详细的自我测试报告及功能修改点影响性;发布后及时和测试对齐。版本海外上线后到目前为止未出现bug。

    作者回复: 怎么理解 发布后及时和测试对齐 这句话?

    2020-10-24
  • Bug? Feature!
    持续跟进进度,细节决定成败!
    2020-11-08
收起评论
显示
设置
留言
5
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部