甲方,你们愿意被乙方侮辱吗?

本文探讨了乙方在服务甲方时可能存在的问题,如找错客户、过度承诺和缺乏自信。指出问题主要源于乙方销售和售前能力不足,而非甲方本身。建议乙方应正确理解甲方需求,提供合适的产品和服务,保持自信并建立平等合作关系,以实现双赢。
部署运行你感兴趣的模型镜像

作为账号的第一篇文章,本来想写写其他内容,但是鉴于今天一个聊天,一群乙方在讨论云计算服务中甲方Baba的各种行为,我决定还是以这一篇作为开篇。

事情是这样的,几个乙方凑在一起调侃甲方,主要表达的是甲方其实不太懂,也不需要懂行的乙方,只需要听话的乙方,不需要能给甲方团队带来价值的产品,只需要能够按照甲方需要执行的乙方项目,听上去在乙方眼里甲方就是什么也不懂就喜欢瞎指挥的傻子,只有伺候好了,才能把钱收到。

然后真相是这样的吗?

先说结论:我认为事实上甲方不是这样子的,造成这种认知的情况有很多,其实更多是乙方的销售或者售前不行,这个原因占比可能会较高。

具体有非常多的情况,我试图列举一些:

找了错误的甲方,霸王硬上弓

任何产品的销售都建立在正确的客户身上,即你的产品要对最终用户产生价值,如果找了错误的甲方,即便是通过一些商务手段成功让客户上钩了,但是随着项目或者产品的真正交付,问题还是会凸显出来。

我们听过一个说法,梳子卖给和尚,牛X的销售也许能做到,但你架不住和尚需要的梳子并不是标准版的梳子,你得为和尚定制开发....最终你获得了一个真正满足某个和尚需求的梳子,然后开始和尚行业复制...

再举个例子,比如前几年大吹特吹的所谓中台项目,感觉什么客户都要来一套中台,但事实上一些信号化水平本身就很差的甲方不懂被忽悠了,加上本身在甲方所在领域知识欠缺的乙方,最终导致了一个超级错配,很多所谓中台项目在这个情况下就不了了之。

这个是甲方的问题吗?

不,这就是乙方将甲方不需要的东西强行卖给甲方,卖拐把人忽悠瘸了,事实上当甲方反应过来,自然拐杖就不要了

  • 乙方正确的做法:

不要盲目推广,找到正确的客户。

业务能力不过关,导致过度承诺

云计算时代的产品,或者更广义的云时代的各种解决方案,既然能成为解决方案了,他就一定能解决客户的问题,但事实上不可能存在一款产品能搞100%满足客户当下的某个需求,或者说就是为了客户某个需求而设计的。往往好的产品或者解决方案有很强的灵活性。

但在这个前提条件下,就出现了,当销售以及售前或者架构师(说实话绝大多数的云架构师有点侮辱了架构师这个叫法),本身技术能力以及业务能力不过关,为了争取甲方的认可,并且有可能在没有理解甲方真正的需求情况下,盲目的将甲方的友善建议理解为需求,毫无保留的传递给后端,当后端团队质疑的时候,轻松的说一句:甲方baba的要求。屎盆子疯狂往甲方头上扣,关键当甲方所谓的需求满足时,甲方发现自己的那个建议不周到,于是提出了另一个想法,可以想象的是,乙方一定会diss甲方又变更需求。

最终问题一定能被解决,然后你能想象最终的交付物是怎么样一个怪物吗?

  • 乙方正确的做法:

真正了解甲方需求,并完成对需求的产品化工程化设计,而不是简单的听从甲方的建议。

面对甲方不自信,无法给甲方信心

我相信,任何一个甲方都不会喜欢与自己接触的乙方的销售或者售前是不自信的,事实上很多时候甲方最初对于产品或者项目的判断是来自于最简单的对于面前的这个乙方的代表的认可度,不管是谈吐,专业度,还是自信的态度,都很重要。

今天任何一个甲方选择一个产品的前提肯定是乙方能给出更好的解决方案,我很难想象如果乙方表现出那种(哥,什么都听你的)的这种态度的乙方代表会让甲方舒服。甲方需要的是乙方的专业度,乙方对于甲方采用乙方方案后所带来的价值的信心,如果乙方本身表现不出对自己的信心,又何谈让甲方放心呢??

  • 乙方正确的做法:

如果你的方案真的对甲方有帮助,自信是最起码的。

所以,乙方首先得把问题往自己身上找,作为乙方肯定不能要求甲方,但是我们唯一可以做得就是要求自己,更多的从自己身上找问题,如果能够提供更好的产品,更好的服务,甚至更好的与甲方进行沟通,我相信这才是解决问题之道。

把很多问题推给甲方,甚至是中国的甲方,看似合理的背后,恰恰是自身的不作为、规避责任,这种心态才是真正的在侮辱甲方。

另外一个事实是,当产品力不足的时候,甲方可能把乙方认定为一种人力服务,这又是另外的故事了。

当然如果你是甲方的负责人,遇到乙方采取:不作判断,轻易被忽悠;瞎出主意,乱提建议;心态错误,仗势欺人。那最终项目落地失败也怨不得别人,最终你只会选择错误的乙方,错误的产品和错误的方案。

其实任何一个云时代的产品,无论是IaaS,PaaS,SaaS都不是一锤子买卖,对于甲乙双方以及相关的团队来说,都是一起成长的好伙伴,大家本身就需要建立在一种平等的合作关系之上,往往只有这种心态,最终才能结出胜利的果实,否则只能开出恶之花。

最后疑问

文章中所有配图都是乙方羞辱甲方的,身为甲方的你,是不是接受这种羞辱呢? 

您可能感兴趣的与本文相关的镜像

AutoGPT

AutoGPT

AI应用

AutoGPT于2023年3月30日由游戏公司Significant Gravitas Ltd.的创始人Toran Bruce Richards发布,AutoGPT是一个AI agent(智能体),也是开源的应用程序,结合了GPT-4和GPT-3.5技术,给定自然语言的目标,它将尝试通过将其分解成子任务,并在自动循环中使用互联网和其他工具来实现这一目标

内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值