在国内程序员就要重点关注业务么

领导确实没说错，往上走就是要定义好做一件事对业务发展带来多少价值。不然就是刷简历。
比如你说的部署要停机，往上层走就要分析部署停机原先要损失多少业务价值，改完之后带来多少业务价值。投入了多少资源，性价比是怎么体现的。
只关注技术？不是不可以，前提是你有个好的老大

与国内外无关，与是不是程序员无关

做业务+技术路线也是个发展路线，不过我理解这句话意思应该是在汇报里面体现业务价值，例如如下修改。

1. 通过建设开放平台，实现内部开发对接流程均在开发平台实现，使得开发间提高沟通效率且对接方式有据可查。本平台上线至今已经实现 XXX 个需求全线上对接，上线后需求上线周期平均缩短 X 天（ XX %），根据团队平均时薪 XXX 元计算上线至今已节约成本 XXX 万元，预计随着开发进一步熟悉开放平台，预计 2023 年度需求上线周期平均较 2022 年平台上线前缩短 X 天（ XX %），每年可节省成本 XXXX 万元。
2. 通过实现 K8S 平台云原生改造，增加平台承载力，推进 DevOps 建设。当前云原生版本相较于原有单体版本资源占用下降 XX% ，承载峰值流量能力上升 XX%，同时支持动态扩缩容可以根据当前业务情况动态增减，从而避免手工预测流量的不准确性，降低公有云采购成本 XX%。通过 K8S 改造实现部署环境与开发环境完全一致，进一步加强开发自测有效性，实现测试团队发现 Bug 率降低 X% ，根据历史数据推算可降低因 Bug 带来的经济损失 XX 万元。同时由于开发自测的有效性，因此测试团队本年度无需根据需求数量增长而新增测试人员，可进一步降低人员成本 XX 万元。

如果上述数据大多数都比较好看，都写到晋级述职里面，那绝对不会被批 "没有呈现业务价值" 。
如果上述绝大多数的数据都 <= 0 ，那么在目前的经济形势下就不是考虑公司业务发展的问题了，那就是考虑下家怎么找的问题了。

@sampeng
@laozhoubuluo
回复一下二位大佬，关于数据呈现，我的述职中确实有呈现，但没有细致到钱，毕竟我也接触不到那个层面，没法核算成本。

我一直都在强调业务的重要性，特别是在国内这种情况更是这样
现在技术门槛已经很低了，网上资料一大把，开源项目一大堆，不管是在校生还是跨专业自学，很容易获取一手资料
而某个对业务的理解真是要项目喂的，没有时间的积累真就不行，不是随便招个应届生就能搞定的
要说技术做到极致，也是不可替代。但是性价比没有专精业务的人高
当然缺点也是有的，那就是和你专精的领域强绑定，选中赛道很关键

你没有明白你领导的意思
在国内 99%以上的公司是业务为导向也就是业务赚钱养技术，所以业务老大为第一话语权，一切都要为业务盈利让路。

做技术改造大多数是改善技术自身的痛苦和为了以后的长远发展这点没错，但你技术人员的薪资是是靠业务盈利负担的，假如你做一件需要动用极大的资源（研发工资*工期时间+可能还要招人+目前现有需求暂缓或延迟）又没有利于业务部门的事人家凭什么同意你去做呢。。。

这件事本质上你是最大利益方但是你要让业务觉得他们很赚，你获得的利益是顺带的，主要是业务方可以立刻获得很大收益，哪怕你画点饼说中长期还有更多收益，他们不懂技术更多听你吹，你只要把你说的实现了有没有那么多收益是后面再说了，之要你做好了能上线你能立即获得的收益=项目经验+简历篇幅+技术分享内容+以后的谈资+年终绩效评分+年终奖+你领导对你的赞许和信任+后期因为一些费力不讨好的需求跟业务方讨价还价的资本（别人解决不了的是你过去刷个脸就解决了）+ 你领导的年终评分和年终奖增幅+领导在一段时间内的重点汇报内容，你的领导也知道没你不行你很重要，你猜他会不会让你优先上裁员名单？

本来是你最大收益你要说成为别人做的，他要是同意你做他现在很赚以后很赚将来也很赚，利益捆绑了人家才能挺你，你的项目有产出业务方多赚钱人家也多拿年终，以后工作中有了信任都好谈一些，有点 bug 小故障都好说。

举个例子
“老板这个项目要云原生改造跟上技术潮流，需要 80 人天，对技术架构提升很大很有作用很牛逼”
老板第一句就是问你，不做会怎么样？ 80 人天看起来夸张实际可能只多不少 因为在老板层面要考虑前后端 /运维 /架构 /测试的人员成本 +现阶段购买的测试服务器以及以后每个月都要负担增幅的运营服务器成本+信任你带来的失败成本（做一半做不下去）

“老板这个项目做好以后后续上线发布预期可以降低出事故时的影响范围同时方便扩容，如果之前有这个架构那么之前的事故可以减少多少损失，如果以后业务做大了再转向会付出更大的成本，现在做的时机是最好的，短期收益可以如何如何，如果再晚启动可能会影响 XXX ，可能其他系统再优化改造会需要更多工期估计 XXX 人天。”

假如你是你领导怎么跟老板说能让他支持你的项目，项目做了你会亏吗

@luomao 算不到钱可以算（开发 /测试 /产品）人天，懂的管理人员能自动换算成钱，但是数据没有换成钱直观好看就是了。
核心是让管理人员看到技术改造投资物超所值，毕竟即使您直属领导能看懂技术价值，但再往上走很多领导不一定有这么敏锐的技术视角能把技术价值直接转换成业务价值，这就需要您在述职报告里面帮他转换一下，不管是省钱还是省人天。

数据呈现不一定就是钱。例如 1 ，可以对比前后内部开发的沟通效率提高了多少（节省了多少时间）。2 可以比较改造前后部署的停机时间差多少。

全世界都差不多，纯技术线很难升官发财。

单就 OP 这个案例而言：
1. OP 的改造没什么问题，关注业务不多也没什么问题、毕竟之前职级可能也还没高到必须关注业务；
2. 除非是对技术需求非常非常硬的高精尖领域，但 OP 描述的这种不算，所以如果想继续向上、不管去哪家公司、多关注业务更好
3. 如果 OP 这次改造再等等，等你们原系统经常出点问题、比如需求迭代快导致停服次数多所以停服权重影响变大，或者量增加了导致原服务撑不住了天天 warning ，然后领导们老板们意识到了技术的重要性需要技术搞定（其实和 1 是一个道理，就是需要技术硬的时候），到时候你再改造、解决这些问题并且晋级述职主要讲解这些技术相关的，老板们就不会这么烦人了。

简单点说，3 就是需要天时地利人和类似的、好钢得使到刀刃上，技术再好没遇到好机会也白费，反倒会被资本家恶心

@lesismal @darkengine @laozhoubuluo @8355 @arthas2234
我还是回复一下大家吧，可能信息还不是那么全面
1. 关于大家比较在意的数据层面，我在述职中有所体现，譬如开放平台中我大概列了接入前后双方的人力成本，以及用到开放平台后每个小项目的项目周期大致减少了多少，孵化了多少个项目落地，还有一份完整的用户调查报告（收集接入开放平台的同事的反馈）
2. 开放平台我表面写的是解决内部的事情，实质上是解决了公司一些私有化产品部署赚钱的问题，具体赚多少我确实没法体现，我只知道每次大概百万级别。
3. 开放平台的产品到开发都是我一个人在搞，因为公司已经把能裁的都裁了，我是经历了三波还留下的人，这东西的业务涉及内部多个系统，除了我和我的 leader 没人懂涉及到的所有业务，所以我觉得我不能被定义为关注业务不多。

开发可以更关注开发工作，然后呢。

这不是傻嘛...我就做个 slb 负载均衡多部署几台不就得了，才多少成本。改造微服务上 k8s 得投入多少，这不是大炮打蚊子嘛，别自己技术玩爽了欺负领导不懂啊

因为晋级述职的下一职位涉及到业务方向制定吧。
技术要点到处都是，肯定以业务作为基础权重，然后规划技术路线，毕竟公司选的是对公司贡献大的，向上级汇报是汇报业务成果，不是向下输出技术总结。
纯技术输出报告另外开讲座呗。

@across 了解了，大概明白一些问题了。技术讲座确实没有在公司层面组织，都是小组分享

@hhjswf 成本确实有点高，断断续续花了几个月搞完

在国外更要关注业务
infra 直接用 aws 全家桶，snowflake 这种

放在之前，我会陪你吐槽。放在目前，我觉得领导说得对。你把接口可用性从 99%提升到 99.99%，和你把公司订单量提升，我觉得后者更重要。而且，说实话，后者更难。前者可量化，后者无法量化和预估。前者找个技术合适的人就行，后者找到合适的人，相对前者更难，各项成本投入更加不可控。

> 但上级的意思是我这里面都是一些技术上的，没有呈现业务价值

说白了就是不信任你做得这些东西能带来价值，这时候就需要引用材料了
搜集点新闻：
"xx 开放平台系统，节省了 yy 人力成本，效率提成 zz%"
"xx 公司使用 k8s ，成本缩减了 yy"
...
角度可以从项目中使用到的技术出发
国外的就翻译给他，给上 sauce
还是不信的话，那只能马屁嗯拍了

意思很明白了， 你没有给公司创造价值。

1. 你做的东西帮公司赚了多少钱。
2. 你做的东西帮公司少亏了多少钱。
3. 你做的东西帮公司估值提高了多少。