技术管理案例课_25_24_技术决策3持续跟进进度执行细节决定成败
你好，我是许建。
今天我们来聊一聊技术决策的执行问题。
我在人才招聘中讲了招聘的时候啊，要追问细节，在进阶心路里呢，提到二线经理要下沉两个汇报级别到一线了解细节。
在危机管理中还提到过，我自己被架空的一个重要原因，就是没有深入到日常的团队运营中去，本质上啊就是没有去了解关键路径的关键细节。
那为什么我一直这么强调细节的这是因为啊我自己经历了好几次教训，追根溯源啊，才发现都是因为忽视了细节，准确的说是对关键路径的关键细节不够重视。
那今天呢我就想跟你聊一聊，就是技术经理如何把控细节，如何通过技术细节交付好业务，培养好人才。
首先我们做完决策就可以了吗？答案是否定的。
我看过一本叫执行的书，里面有这么一句话，这样做，领导当然好了，当然舒服了。
你只需要站在一旁进行一些战略性的思考，用你的愿景目标来激励一下自己的员工。
然后呢，把那些无聊的具体工作交给手下的经理们，我在这里啊要提出的是这种思考问题的方法是错误的，它很有可能给你带来难以估量的危害。
我对这句话深有体会，做决策只是起点，如果止步于此等于空谈，为什么这么说呢？如果我们觉得决策做完了就万事大吉的话，常常会有下面这些后果。
第一呢就是经理自己被架空，哪怕我们通过决策，把工作优先级聚焦到了核心问题，但决策落地最后还是要靠执行的。
如果不能把握关键细节，完整的跟进进度，经理啊就容易把自己架空。
第二个后果呢就是导致业务价值无法按时交付。
有一次啊总部领导质问UX小组半年内没有交付业务价值。
事后啊，我跟UX小组的经理复盘时才发现，我们当时对于关键依赖的解决不及时，人员不够专注。
而且啊起初的设计也过于复杂，得出这三条总结已经是事后诸葛亮了。
第三个后果就是无法解决部下的困难，再远大的目标。
最后还是要靠一步一个脚印的推进技术经理啊，要了解一线的具体困难，采取行动解决，否则会直接影响到自己的领导力。
在这里啊，我想跟你说的是无论是一线技术经理，还是二三线技术经理，尤其是二三线技术经理。
因为会花更多的时间考虑战略、文化等事物，所以更要时常提醒自己去了解关键路径的关键细节。
我们不要把自己架起来。
因为一个项目，一个产品它不是禁止的，在项目和产品的发展过程中会不断的出现问题。
这些问题啊，你不能单方面等着下属自下而上汇报，也应该由上而下去了解。
只有注重了关键的细节，你才能对手上的关键产品和项目有比较全面的了解，才能持续的根据实际情况做后续的技术决策。
技术决策啊不是一次性的买卖，需要为了达成目标，做持续修正的项目，没有交付前就不能放松警惕。
我们知道了执行细节很重要。
那具体怎么才能把握这些细节呢？一般啊在执行过程中，我会同时使用下面三种方式来了解执行情况，来保证执行达到预期效果。
第一个方法呢就是执行负责人要制定可衡量的阶段性目标。
我的经验啊是计划会变，这一点我认可的，但是我不接受。
因为这个理由就不去制定计划。
虽然我们可以理解很多事情，很难估计时间直行制定时间表的话，最后也许就不能交付。
那么很难估计时间的话，目标到底该怎么制定呢？我的方法就是必须定计划，这条是没有商量余地的，但是可以做拆分，直到上级的单元可以很好的做衡量。
如果季度目标不准，就定月度的月度目标不准，我们就每两周一次的sprint目标。
再不行，我们就定每一周的周计划。
第二个方法呢就是做定期的项目评评和和周报。
这里啊为什么要强调定期定期的作用？就是给执行负责人传递一个明确的信号，就是是他的上级技术经理正在持续关注他的进度，愿意及时解决他的实际困难。
同时啊这么做对执行负责人也是一种压力。
每一次到了项目评审和周报的时间点，他都需要给领导和同仁看到进度。
关于项目评审和周报有三点注意事项，第一，我不要听流水账。
所以负责人要对照项目之前定下的阶段性目标来汇报进度。
第二，如果项目进行过程中有阶段性目标达成，或者有值得肯定和表扬的点，我会要求负责人单独注明。
第三，项目中碰到的问题也需要单独标注。
这一条非常重要的我一般会建议执行人用绿黄红三色来对问题分成第色是已经解决的问题。
黄色呢表示，虽然出现的问题，但是执行负责人已经拿出了具体的举措在解决问题了，目前还不需要上级领导介惯，而红色就是表示要求上级领导介入或者提供帮助。
他辩证思维。
一节中我讲到自己的一个思维习惯，就是重要的项目在决过程中要挖掘痛点。
如果没有挖掘到，我就会觉得有潜在问题，然后继续深挖。
同样的呢，在决策执行过程中，我想给你分享我的另一个思维习惯。
如果我在项目评审和周报里只听得到好消息，从来听不到困难和坏消息，我就会给自己提一个醒了这么重要的事情，在执行过程中这么一帆风顺，正常吗？这会直接导致我找一线骨干做deep dive的。
接下来我再说说第三个方法就是不定时的找团队一线骨干做低部大夫。
在日常工作中呢，技术经理要下沉两个汇报级别，去找一线骨干，了解细节。
其实啊我们在做关键项目的执行时更应该如此。
那么具体要怎么做呢？我是带着希望这个项目成功的心去挑刺儿的，我通常会这么去思考。
如果有三个原因造成我这个项目失败是哪三个原因？我现在可以做出什么样的举措，降低失败几率？通过找团队的一线骨干了解细节，我发现自己对项目的了解更加全面，也能尽快的发现实际操作下来经常发生什么样的问题。
下面三类问题是最常见的。
第一个问题呢就是对性能压测和失效性分析，重视程度不够。
我们部门在吃过几次苦头以后，在这一点上已经比较重视了墨菲定律。
在我们部门负责的项目上几乎次次名验。
第二个问题就是对关键依赖过于乐观了。
现在我们部门对于关键依赖我的建议是，如果没有书面承诺交付时间的，就当这个依赖没有搞定，应该找高级别技术主管介入。
还有一类问题啊，就是实现时加带必要功能之外的加分项功能。
在我们部门，目前实际的执行历史看，在技心功能交付前，所有锦上添花的功能都应该全部砍掉。
前面我们说了关键细节如何把握，但细节更多的还是一些关键节点。
在技术决策的执行中，我续跟进还需要一个线性的思维，树立起对决策，对自己的决策，以及对未来如何做预判的认识。
请你跟我回顾一下自己做经历的经历，我们总能轻易举出一系列半途而废的事情。
这些事儿啊都是我们做了决定，但却没有跟进，最后不了了之没有落实。
但问题到底出现在哪里呢？第一种情况就是做了建议，没有跟进。
幸好我专门用了建议这个词儿，而没有使用决定这个词儿。
这是因为啊如果我们都不去跟进确认就不能算做决定。
我给你举个具体的例子来说明吗？我们部门已经多次出现误删操作，因为权限管理太松发生过不应该有权限的人误操作。
结果删除整个测试数据库的情况。
最近一次是因为数据质量问题，系统误删了生产环境流量入口。
幸好啊我们部署了高可用HA防护，它没有出大事儿。
我做复盘的时候想起我虽然一次一次建议要引入保底措施，在删除逻辑，最终加入流量检查保护。
但到目前为止，我只是反复在强调不采取措施的风险。
这个风险啊就是一旦出问题影响业务，会导致打乱我们所有的原定计划，然后全员被迫都要去做系统的可靠性强化工作。
我的部下不是笨蛋，如果没有落实，一定有现实的困难，需要我去了解具体的困难，很有可能落实。
这项工作是需要以牺牲功能开发为代价的。
再联想到，我一直强调说说话，要算数。
也就是说我们部门承诺的功能一定要按时安置交付。
我觉得问题出在自己只是做了建议，却没有持续跟进，不止一次踩了坑还是出问题。
你想要改变一定是艰难的那这个艰难的决定一定是组织一把手来做的。
第二种情况呢就是没有落实标准。
在我们部门最常见的就是出了一个生产事故。
于是在分头上呢，大家都很重视制定出一系列举措问题。
是啊，我们很少会去重视那个生产事。
通通过测试进一步确认我们落实的那些措施的有效性。
也就是在下一次发生类似事故时，我们指定的举措是否真正能够起到作用？比如说我们上个月发生的一件事儿，因为一个bug没有落统的一个超级账号抹掉了整个测试环境监控系统。
这个事故我们花了四个小时才恢复服务。
在复盘会议上，全队成员觉得以后我们可以在二十分钟之内恢复服务，但这个想法没有落实到测试环境中去检验，其实很难立住脚。
所以我明确要求监控组一定要复制一套一模一样的线上系统，再做一遍删除系统后恢复的模拟测试。
要知道我们设想中可以二十分钟完成的线上操作和真的做一遍，验证一下，在二十分钟内能不能恢复是不一样的。
其实啊本质上这类问题都反映了技术经理的重视程度，特别是和经理是否能够持续重视密切相关。
作为技术主管，你选择落实自己做过的决策，为了真的落实，会愿意花时间。
更重要的一点，是你愿意延后，甚至取消你想做的其他事情，来给你自己和你的团队腾出精力，专注落实这项决策。
就算我们已经给关键项目安排了负责人，作为主管经理，我们同样也是执行者。
怎么理解这句话呢？经理啊，不是在项目启动的时候定一下方案，然后安排一下人手，怎着第时听听汇报做做往往和deep dive就够了。
经理啊得为员工办实事。
这就是我说经理也是执行者的意思，我自己在听定期的工作汇报，或者跟一线骨干做deep dive.经常跟团队成员说的话是这样的，领导的工作不单单是给你分配任务，也包括帮你解决你的困难。
领导最不希望看到的就是快到交付了。
你的领导说，因为这样那样的原因，项目不能如期交付。
所以呢如果你觉得有风险需要领导介入，就应该第一时间跟领导沟通。
你要有这个气场，可以给领导安排工作。
在我们一个冲突比较激烈的项目中，我甚至对技术负责人说过这样的话，这个项目如果你搞不定技术实施是你失职。
如果我搞不定，alignment是我无能。
其实这么说就是因为我认为经历本身也是执行者。
关于这个问题，我有三条原则跟你分享。
第一个原则是，如果部下反映的问题，我能够解决的，必须马上解决，不能拖，更不能石沉大海。
第二个原则是这样的，如果部下反映的问题我不能马上解决。
那我需要告诉部下我大概在什么时候可以解决。
第三个原则是，如果我评估下来，我也无能为力，我会告诉部下不能解决的原因。
当然了，这些原则还是要结合实际场景才能体现。
总结一下，就是我们应该把定期的工作汇报困议变成解决问题的现场办公会议，而不是一个给领导单向汇报工作的汇报。
会议作为领导，要给部下反馈和采取后续动作做的好的，不要吝啬表扬。
碰到的问题，领导也是执行者，需要切实解决困难。
我们都知道管理未知是最难的，有时候我们可以预判后面执行，还会有这样那样的问题，但这些问题也是很难事先预料的，这时候应该怎么办呢？我的做法就是早点放到真实环境中去历练，争取尽早暴露问题。
我结合具体的业务案例来说一说吧，我们公司因为要应对购物季的流量高峰，每一年在购物季之前呢都需要流量管理团队加班。
加班的任务就是把数千对负载均衡器上的流量平均分配好。
今年啊因为疫情原因，易备网站流量高峰提前到来，这也导致了问题的加剧。
副总呢给了死命令，要在今年三季度结束前完成这个流量重分配，百分之一百的自动化。
因为这样的情况，我在跟流量管理团队做定期审核的时候，最最关心的问题就是什么时候可以drun,就是线线上模拟运行。
我担心啊自动化没经过试验，存在影响业务稳定进行的风险。
事实上，我们在所有功能都开发好以后，drive around的自动化成功率只有百分之十，强化一个月以后达到百分之七十，再强化一个月后达到百分之八十。
今年年底前，我们需要交付的OS patching也是一样的，公司的安全合规要求越来越高，这对我们全网patching的挑战就越来越大。
十几万台机器的OS patching,从半年一次到一个季度一次，甚至到明年要达到每个月一次。
我们觉得引入独立级算法可以增加升级，并行度加快速度，但真正跑起来呢？应用重启后，也许不能自动恢复到正常速度，但应用同时重启压垮下游服务nose equay.应用升级时，数据重平衡，时间过长，这一系列问题让我们举步维艰。
最后啊我们得出的结论就是早点去战场上历练。
我们只有提前去线上摸爬滚打，才能把十多年来积累的垃圾都暴露出来。
我为一名技术经理。
最后啊还是要回到人才培养上。
我认为重要的关键项目，除了交付业务价值，另一个重要作用就是培养人才。
那具体怎么培养呢？我最近半年最大的收获就是指出关键细节上的差距。
技术主管只有深入一线，了解关键细节，才有可能对于执行这些项目的骨干，提出有建设性的高质量意见。
这些意见对于项目骨干的成长意义重大。
不知道你是否记得我在员工沟通，那一节就提过跟高级别技术骨干不能光谈原则，必须落实到具体的细节。
我之所以能够重新审视我们部门的执行文化并做出改变，这是因为自己的老板指出了我在细节上的差距。
当时我的老板指出，我鸡血很足，但是对部门要求并不高，而且他拿着兄弟部门的团队、业绩、人才梯队，甚至还有对派遣人员的培养计划来做佐证。
如果我领导不拿着具体的细节给我看，恐怕不会有这么大的触动效果。
这么做的好处是，当你给具体的细节的时候，听的人啊其实已经从具体的实力中自己得出了你想要的结论。
这时候你再说出结论，就更容易被听的人接受这个抓细节的思路。
我也应用到了自己培养部下能力的过程中。
比如我跟经理x确定了他今年必须有一个目标，这个目标是培养他左右手到这样的水平，平就没没有，他也能独当一面。
我还找到我们部门的技术骨干，跟他探讨了了。
为什么我们部门的键项目不能能由一名技术干干上一批派派人人员来实施？兄弟弟部门可可首先是细节当做切入点，我们对手下的培养就不是空谈的方向了然。
拿着关关细节节为把控好了，接下尤尤其对项目骨干找到矛盾点，在解决矛盾的过程中提升自己的水平。
好了，接下来我来做一个总结。
今天我跟你讲的技术决策后，对执行细节的掌控是项目成败的关键。
首先我指出了做经理，特别是高级别经理的三个大式，就是整天关注战略层面的宏观问题，听听报告，而忽视对关键项目的关键细节的把控。
然后呢，我给你总结了掌握执行细节的三个方式，分别是设定可衡量的阶段性目标，首期做项目审核和周报，以及不定时跟项目一线的骨干做底部大夫，我们始终要未雨绸缪上问问自己。
如果我这个项目失败了，会是因为什么原因从而及早做出安排？我们要认识到，做技术决策不是一次性的买卖，技术经理必须用发展的眼光做持续跟进。
决策不等于落实。
技术经理可不能就天天报告，你需要及时了解关键情节，使得你能够及时做出调整。
我特别强调了，技术经理应该把工作汇报的会议开展现场办公的会议，我们不可能一次性掌握所有情况，很多事啊还处于未知状态。
我们就很难推演，怎么降低风险。
所以我建议是尽早到逼近真实战场的环境中去历练，毕竟啊实践出真执。
最后啊我们还是回到执行细节，对人才培养问题上的意义。
我自己对部下的要求还不够高，这一点我觉得是我们部门这两年来人才培养上的两大缺陷之一。
意识到这一点，我在今后还会继续提高，通过细节入手，让团队成员变得更强。
我的建议是对我们的骨干要高标准、严要求，而指出他们的问题时，就要拿出具体的细节上的差距，高标准、严要求，甚至是用严厉的语气明确说出来哪个具体的点做的不够好。
这对唤醒人的自我觉悟、提升人的能力帮助很大。
在本节课的最后，我给你留两道思考题。
请结合你的实习经历，分享一个你自己注重执行细节的正面案例或者反面案例。
我们大部门有一个小组，既要维护现有系统，又承诺了新系统的多个子系统的研发。
但是该小组经常需要救火，承诺的时间点也出现不能准时交付的情况。
总部领导跟我谈起这个状况时说，他会给该小组经历更多的压力。
你怎么看待总部领导给更多压力的解决方案呢？欢迎在留言区晒出你的经历和疑问。
如果有所收获，也非常欢迎把这篇文章分享给你的朋友，说不定就能给他带来一些启发。