美文网首页JavaJava 程序员
技术人不应该仅仅盯着技术,还要有业务的深度

技术人不应该仅仅盯着技术,还要有业务的深度

作者: 马小莫QAQ | 来源:发表于2022-08-24 17:01 被阅读0次

当我做为一个比较大的项目的主程之后,我萌生了一个想法,我要当一个项目的牵头人。为什么会这么想呢?

从之前的一篇文章中提到,层级。你得清楚在你当前这个层级的上一层是什么样子,它需要什么能力,这个过程也需要去探索出来的。我认为主程是高级开发的一个进阶版,它需要把控项目的质量,资源分配,项目进度,这些都是高开(我定义为coding方向的高级开发)所不具备的。

那么牵头人或者负责人,对于主程来讲,又有哪些是主程不具备的能力或者要求呢?我觉得对整个业务的思考,这包括业务模块的定位,业务的规模,业务的可行性

主程更多是站在完成业务需求的角度去执行,但是负责人应该站在业务角度进行技术类思考。

研发层级 任务 具备能力
coding高级开发 保证任务完成✅,代码质量 代码、技术上能力
主程 保证项目的质量、进步 资源把控能力
负责人 关注需求背后业务难点,业务前景 思考能力、深入一线业务,对整体业务熟悉程度

项目负责人的尝试


全局观

首先我负责的是对账相关的业务,我们从负责人的角度来看,或者把它当一场生意来看,首先我需要清楚这个业务定位是什么,也就是这个生意做的是啥业务,有没有竞争对手,清楚大环境。

对账按常规属于财务模块,但是由于内部一些问题,财务不管,那么现在就很清晰了,接管了财务的对账,这个是狭义上的对账,广义上的包括第三方接口调用量也可以对账,比如说之前我一个shein的同学跟我讲,它们的短信功能被蹭流量了,损失了很多钱,后面通过对账找到问题的。广义上的对账,只要有加就有减,这里就看业务价值了。

其次,业务的前景,它说能解决的问题有多大?

比如说一个个业务方都说他自己的业务很多困难,很多需求,它们衡量标准是什么?可能是工作量,可能是业务量,可能是供应商数量,就是我们需要摸清这个生意有多大的前景,决定了业务的价值。比如说做的业务只服务一小部分的客户,那意义比较少。所以这里还有一个是推进过程的覆盖率的问题。

最后是可行性,可以从大到小,也可以从小到大,这个具体场景具体抉择。怎么理解这句话呢?

从大到小,从占比大头的入手,比如说某个供应商占到总销售额很高的比例,那么我只要把它解决了,意味着基本把业务做下来了。有些领导会觉得需要覆盖率,但是我的想法跟考试一样,我拿到我应该拿的60分,比起一个个去拿5分,10分已经强很多了。当然不能算优秀,只能说业务已经有雏形。

从小到大,我觉得是没有把握的情况下,先从简单的入手,从量上去覆盖业务,当然最大的那块骨头也最难啃了。

我觉得这是两个思路,需要从具体情况去分析。

细节观

  1. 有一方面是关于需求背后的业务价值思考,可能是业务难点,可能是之前业务不足导致的缺陷。

当然这里我也要聊几句,并不是什么需求都去纠结背后价值,东西总有主次之分,人的精力真的是有限。需要清楚哪些是主要业务

鱼和熊掌不可兼得

  1. 有头有尾,之前我面试大厂的时候,经常听到一个词:量化

有头有尾,怎么理解呢?就是做完项目需要跟进项目的推广情况,收集问题,然后作为下一次解决的切入点。

就是你做这个项目它的价值体现在哪里,又有多少?这个多少指标是什么,需要量化。比如说有500个供应商需要接入,现在只接入10家,这个价值覆盖率可以算出来。

  1. 需要去深入业务发现问题

作为程序员常常为了完成需求,其实还站得不够高,正常的情况是站在业务的角度,用技术去解决业务难题。

在架构组我们也有讨论过技术跟业务的关系,聊聊我的想法:站在架构组角度,一定是技术重要,它的价值在哪里,降本提效。体现在规范上面,基础架构上面,让程序井井有条,即使随着业务发展也可以扩展,不会加大研发的重复开发成本。

如果站在项目角度,绝大多数是业务是大头,技术只是驱动、赋能作用。只有当业务做起来了,技术才有用武之地,不可能说我一个简单的功能,你直接搬上一个非常牛逼的技术方案吧,这属于过度设计了。

所以我的思考:要想技术有所深造,必须把业务搞大,才能谈技术上更高的追求。(这是站在负责人角度)如果作为研发角度,你可以无限过度设计,然后吹多牛逼,当然也可以,但是本篇是站在负责人角度来阐释。

举个很现实的例子,我上家公司用户数上千万,这么大的用户量,催生了业务需求,促进技术快速发展

项目负责人往上的层级?


那就是多个项目或者一个bg的负责人,他需要对公司业务有更深的认识,然后炮制之前项目负责人的思路之后,还需要对各个项目之后的关系有清晰的理解,对整个大环境有所理解。

说白了,一屋不扫何以扫天下

它不是简单几个项目之间的叠加,可能会有覆盖,这时需要梳理出它们的关系,协调好资源,比如说哪个项目是重点,资源需要往哪里倾斜。我发现有些大项目仿佛大家没有思考好,一会说这是一个紧急需求,大家赶紧做,做完发现没人用,好家伙。或者说做到快上线前,把方案干掉,说行不通。还有些就是现在说紧急项目,过段时间又不紧急了。

一方面哦,是对定位没有想好,做的大项目究竟服务的是啥,会不会跟其他项目有所冲突。另外一方面是前景没有想好,这大项目有多大的前景,这代表你能玩多大,怎么玩。然后是可行性,我一期做10%,二期做20%,还是说一次性的项目,做完即废。这个很考验上上上层大佬的能力。

当然我还没到那个层次,经验微薄,就不展开吹牛皮了。

时间不早了,洗个澡,出来支个摊位卖炒饭,有人跟我卖炒饭的吗~

作者:大鸡腿同学
链接:https://juejin.cn/post/7134721214869684237
来源:稀土掘金

相关文章

  • 技术人不应该仅仅盯着技术,还要有业务的深度

    当我做为一个比较大的项目的主程之后,我萌生了一个想法,我要当一个项目的牵头人。为什么会这么想呢? 从之前的一篇文章...

  • 框架和平台

    框架针对单一的技术问题,一般与业务场景无关,与技术场景相关。框架开发时不应该关联业务,也不应该有特定的假设,使用约...

  • CTO 必须具备 5 项关键能力

    CTO 必须具备 5 项关键能力:技术能力、业务能力、架构能力、产品能力以及管理能力。 技术能力 技术能力包括深度...

  • 不仅仅要钻研技术

    技术优先,但不要仅仅钻研技术! 要有商业头脑! 用自己的头脑抓住商机,赚钱! 用技术创造价值,赚钱! 不要死学技术...

  • 软件需求全景图

    1. 业务驱动需求思想 要做好软件需求工作,业务驱动需求思想是核心,不应该从技术视角展开,技术视角关注的是“方案级...

  • 技术含量

    自己太纠结于技术含量了,其实作为技术人员,快速实现业务本身就是很有技术含量的东西 即使是一个CRUD业务系统也要有...

  • 代码版本方案:Trunk Based,Git Flow,Aone

    技术永远是服务于业务,其实没太大必要仅仅为了技术镀金,而选择高大上的方案。用最简单的技术完成实际业务,四两拨千斤,...

  • 技术/业务/产品

    技术与业务相爱相杀 技术支撑业务 业务倒逼技术进步 技术有时候也满足不了业务,业务必须妥协 技术有时候引领业务 最...

  • 业务是灵魂

    技术是为业务服务的, 不懂业务也做不好技术, 技术只是工具, 业务才是灵魂。

  • 对于如何来理解审查指南所提到的“公知常识”?

    公知常识是本领域技术人员所知晓的普通技术知识,其不仅仅指技术手段本身,还包括技术手段与其在技术方案中所解决的技术问...

网友评论

    本文标题:技术人不应该仅仅盯着技术,还要有业务的深度

    本文链接:https://www.haomeiwen.com/subject/vvdogrtx.html