24 | 技术决策(3):持续跟进进度,执行细节决定成败
该思维导图由 AI 生成,仅供参考
做完决策就可以了吗?
- 深入了解
- 翻译
- 解释
- 总结
本文强调了技术经理在决策执行中的关键作用,以及如何把握关键细节来确保执行达到预期效果。作者指出,决策只是起点,而持续跟进和关注关键细节才能确保项目顺利交付。文章提出了三种方式来把握执行细节:制定可衡量的阶段性目标、定期的项目评审和周报、以及不定时地找团队一线骨干做深入了解。此外,作者还强调了持续跟进的注意事项,包括线性思维、对决策和自身角色的认识等。这些方法和注意事项有助于技术经理在执行决策时更好地把握关键细节,确保项目顺利进行。文章还强调了技术经理作为执行者的重要性,需要持续重视并解决困难,同时提倡早期暴露问题,通过实践历练来应对未知挑战。整体而言,本文提供了实用的技术管理经验,强调了决策执行的重要性和技术经理的关键作用。
《技术管理案例课》,新⼈⾸单¥59
全部留言(5)
- 最新
- 精选
- Weehua问题1,我最开始带团队的时候,团队只有两个人,当时在做第一个项目的时候,我并没有去review细节,而且甩手掌柜,项目很重要,是我们部门的第一个对外合作项目,两周开发时间。后来到了第二周的时候,一个小伙伴私底下告诉我另一个小伙伴的代码质量很差,感觉不能被信任,处于对结果的保证,我们沟通下来是他把另一个人的工作也都做了,加班做了!最后成功交付,但几乎90%的工作都是他自己搞定的!后来想想,我最为技术领导,这么点工作都没有跟踪到细节,而且是工期过了一半才发现,还是下属反馈的!确实不知道当时我在干啥!吸取经验教训,半年以后,团队大了,人多项目多了,我对于新人或者重要的项目重要的功能,全部抽空review,发现问题及时反馈及时让下属解决,这才保证了项目质量。 问题2,我感觉给更多的压力不一定能解决问题!除非上级认为经理没把事情做好是因为没有认识到事情的严重性,给更多压力可以逼经理重视问题的严重性,想办法去解决!如果问题的原因是没有抓住重点,其实给予一些指导可能会更有效果!
作者回复: 问题一, 我觉得你做的很好了。到了二线经理以后,我现在能做到的是review 项目,但是我后来发现这样不够,我还得去看看customer support. 这些我还是可以覆盖的,代码层次,我会让一线的人给我看他们的测试用例。但是我已经很少坐下来很仔细的跟大家一起做code review 了,这一点是个遗憾,除非我能进一步优化时间管理,比如一些效率不高的会议就不要去了。我装了一个rescue time 的app. 问题二:对的,我觉得大家要知道自己的部下不是傻子,一定有具体的困难,二三线领导应该切实解决下属的困难。
2020-10-242 - 此方彼方Francis“如果我在项目评审和周报里只听到好消息,从来听不到困难和坏消息,我就会给自己提一个醒:这么重要的事情,在执行过程中这么一帆风顺正常吗?” 类似的,在开发一个复杂功能的迭代中,如果bug数量比较少,我也会在心里反问自己一句:代码质量真的这么高?
作者回复: 能量守恒,要么就是你真的花了大力气在事前的Test Coverage , CICD 上面。肯定不会无缘无故就形势一片大好。
2020-10-201 - Ke严厉 - 看人的吧。皮猴子需要严厉,本身很谦卑open mind的人你不需要严厉他也能听进去。
作者回复: 骨干级别都不低,皮猴子很少,人要真诚,话要到位。我觉得大多数时间客客气气的,也不能总是客客气气的。但这不是“术”,不是技巧,没有刻意为之。
2022-01-03 - 我能走多远说一下个人执行细节的案例吧! 上家公司没有完善的项目管理流程,导致项目交付质量差,体现在开发因方案频繁变更导致交付延期;代码review过程中提出新的解决方案要求开发重新修改;交付项目没有自测报告及影响点;项目上线后没有和测试对齐等等。 我做的几个项目都是严格按照项目交付流程,设计分析会拉上技术经理及相关模块责任人一起分析方案的优劣点及影响性,一些设计细节也都会带上;避免了代码review阶段的返工。有详细的自我测试报告及功能修改点影响性;发布后及时和测试对齐。版本海外上线后到目前为止未出现bug。
作者回复: 怎么理解 发布后及时和测试对齐 这句话?
2020-10-24 - Bug? Feature!持续跟进进度,细节决定成败!2020-11-08