美文网首页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
    来源:稀土掘金

    相关文章

      网友评论

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

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