寻找 售前解决方案工程师

成都/经验3-5年/本科及以上/售前支持工程师/全职/7-14K

职位诱惑:

大厂背景,全新创业,AI新方向,期权

职位描述:

职位职责:

1.与销售团队合作,利用个人销售资源,积极开拓新客户,为客户提供定制化的技术解决方案;
2.参与制定销售策略,负责为客户提供产品演示、解决方案讲解和技术咨询;
3.参与招标项目,负责技术方案的撰写和呈现,确保方案的专业性和可行性;
4.为客户提供技术支持,解答客户对产品功能和解决方案设计的技术疑问;
5.与产品团队紧密合作,及时反馈客户需求和市场信息,协助完善产品功能和解决方案设计;
6.参与行业会展和技术交流,为公司树立专业形象,扩大市场影响力;
7.在安全行业深耕个人发展,积极拓展行业资源,为公司业务拓展提供支持。

职位要求:

1.本科统招及以上学历;
2.3年以上软件产品相关工作经验,有AI、身份安全、应用安全等领域的解决方案设计经验;
3.具备出色的沟通能力和客户服务意识,能够与客户建立信任和良好的合作关系;
4.熟悉安全软件产品市场和竞争对手,了解行业趋势和客户需求;
5.能够独立分析和解决问题,有较强的学习能力和团队合作精神;
6.具备相关销售资源,有成功的售前技术支持经验,能够为销售团队赢得重要项目和客户;
7.有深耕AI行业的愿望和能力,愿意为公司业务发展做出长期贡献,并愿意接受公司提供的股权激励。

附加信息:

  • 候选人加分项:软件安全

工作地址:

成都武侯区– 天府五街菁蓉汇6幢1楼

联系方式:

邮箱:lishengzhao@cloudjac.com

《ToB的本质》摘录与感触(2)

“定价是需求和供给的交叉点,决定了产品的价值传递方式。”

“对某一企业软件市场规模进行准确评估几乎是一件不可能的事情。这有两个原因:第一,没有可信数据源。第二,破坏性创新的统计价值低。”

“若定价未在官网上标出,那么厂商很可能不是严格意义上的SaaS厂商。定价不以高低论英雄,而应以是否适合产品自身定位分好坏。”

“总结来看,企业软件定价模式需要在这两个要素之间平衡:与价值传递相吻合的灵活性,与客户预期和采购相吻合的惯性。”

“国内市场中目前没有专为企业软件提供定价支撑的工具,关于定价,优惠券,免费试用,大客户折扣,到期提醒,成本红线,价格调整,新定价灰度发布,反馈收集等一系列价格管理能力,均需要厂商自行摸索,业内不仅缺乏共识的最佳实践,自己摸索的效率和效果也都很一般。” ——- 机会?

“定价是组织对市场把控力的整体体现,定价不能凭空猜测。”


“线索交换是值得一提的特殊渠道。这一手段短期成单的可能性不大,但客户画像的真实性近乎100%,是罕见的能够批量直接触达企业软件决策者的营销方式。”

“渠道的作用是“放大”,既放大了优点,也放大了缺陷。”

“回到创业阶段,很多时候销售人员(无论新手还是老手)卖不出产品,是因为核心团队没有想清楚怎么卖,卖给谁,并且产品定位不清,价值不显,无法为销售人员搭建一套可学习,可复用的支撑接口,销售工作自然难以深入。”

“基本的销售方法应由核心团队自行实践,总结清楚,然后再招一两位销售人员,试探是否可以复制。”

“我们应将知识的互通视为企业经营的头等大事,也应将其看作销售管理的底层核心目标。”

“在知识分享不畅的软件团队中会出现“三不”:销售不知道怎么深入讲解;知道如何讲解的人不分享;组织中缺乏鼓励分享的机制或文化。”

“虽然最终成单原因是复杂的,但专业性这一要素是核心产品价值的对外体现,需用最重视的态度反复雕琢。”

“市场负责触达,销售负责转化,,,如果说销售是在“点”上转化,那么市场无疑是在“面”上制造影响,而后者天然就是模糊的。”


“当达到5000万元年收入规模时,单产品的收入增长可能会大幅放缓。为了持续增长,厂商普遍会选择横向扩充新的产品线作为第二,第三增长曲线,组成产品矩阵,联合售卖。”

“然而,多产品线带来了更为复杂的管理问题。”

“多产品线,是以产品侧体系性对抗需求侧体系性零散多变的思路,是以数量对抗未知的暴力哲学。”

“一次只做一件事,一个团队只有一个目标,这是做好任何事情的基础。”

“每一个功能都有它的价值,但也有它的代价,我们经常重视前者而忽视后者。”

“清晰的产品边界是交付标准化的基础,而交付标准化是规模化发展的前提。”

“技术优势是一项隐性优势。若不经过专门的良好包装,在短期市场竞争中,技术优势难以体现出价值。包装的内容需要与客户的需求相契合,并不能凭空捏造。”


“交付是最繁重,成本最高的软件经营环节,交付的成本是不可被规模化摊平的,是企业软件行业难以规模化发展的“罪魁祸首”。”

“我仍建议交付环节由合伙人专门负责。交付工作是处于一线的,需要想办法让销售人员听到最后排的声音,让管理者听到最下方的声音,让产品人员听到现场的声音,整个团队才能动员起来。”

“交付是体系化的最大困难,指望某一部门超水平发挥去解决无疑是白日幻梦。错综复杂的体系化问题,只能由体系化的应对方式去解决。”


“软件本质上是企业经营最佳实践的标准化输出。”

“软件的价值根植于人力成本。人力成本由产业链,行业经济,发展阶段,社会形态综合叠加,共同决定。”

“由于企业软件的价值是企业本身在社会中价值的映射,所以市场经济发展越充分的地区,软件价值的天花板理应越高。”

“软件的最终目标是帮助企业实现其社会价值,从业者也当以此自勉。”

延展阅读:《ToB的本质》摘录与感触(1)

《ToB的本质》摘录与感触(1)

“而国内的企业软件仍重度依赖于售前,交付,沟通,驻场等服务,对这些与客户同协同律的工作的依赖,意味着地区壁垒可能通过企业客户而对软件厂商的经营模式产生间接影响。”——软件只是实现客户定制的工具罢(还不错的工具)?

“换句话说,企业软件行业可能少有颠覆性的新机会,现有大厂可以相对安稳地经营下去,持续享受整个市场水涨船高带来的福利。”——企业软件解决的痛点不够痛?

“销售扩张时优先设立地区线,而后考虑行业线,理应具备最佳的性价比。”

“近10年以来,有多少旧人折戟沉沙,就有多少新人奋勇争先。诸多我尊敬的团队,景仰的前辈,未坚持到日出之刻;多少优秀的产品,精致的服务,徘徊在黎明之前。”——创业维艰呢


“稳定且仍在发展的广阔土壤,较低的门槛,专业的需求以及纷杂的壁垒,这“大,专,低,杂”的因素综合在一起,互相作用,共同构成了行业珊瑚礁状的形态特点。”

“这像是企业软件行业存在的市场壁垒,让大资本与巨头食之无味的同时 ,给无数创业者和管理者以穿越周期,安稳栖身的机会。”——无序意味着机会。

“在社会中的其他科技领域增长乏力时,企业软件行业可能以其特殊的结构,稳定的土壤,庞大的需求,较低的门槛,纷杂的市场壁垒,吸引大量科技和工程领域人才进入耕耘。”

“当一个具备标准功能,标准流程的企业软件产品交付给客户时,会同时发生3件事情:客户的认知需要与软件价值达成一致;企业的流程需要与软件支持的流程对齐;旧有的系统需要与新软件完成对接。”——软件开发结束只完成了一小步。


“软件厂商和投资者如果抛开对低利润,难扩张的重交付模式的厌恶,只从市场整体的利弊出发,不带感情色彩来看,或许会发现:可以(或愿意)提供重交付模式,反而是厂商具有的,符合市场需要的竞争优势。”——优势由交付决定??

“发展不是规划出来的,而必须是实践出来的。”

“定制多,交付重,离业务近,却解决了企业的核心问题。”——服务模型(管家式服务)。

“对老旧系统的兼容问题,属于非功能性质的需求,对技术水平和投入的隐性要求很高,会给企业带来极高的成本,且没有经验的人员很难预估其难度。”——骨头上的肉。

“老系统带来的交付难度可作为衡量企业的信息化阶段和步幅的指标,交付难度越低,企业的信息化成熟度可能就越高。”


“中国企业软件的云化趋势是由中小企业(特别是科技企业 )和新兴企业的快速发展带动的。”

“需求是发展的驱动力和方向,但又天然具有一定的模糊性,盲目性,甚至欺骗性。”

“SaaS只能解决产品成本问题,无法绕过软件产生价值的必要步骤。国内大部分企业缺的并非单纯的产品,而是顾问式的,能落地的解决方案。”——有多少清晰的认知到?

【转】SAAS软件-ToB 破局之道

一篇把中国企业软件真正的困局、现况和我实践的破局之道串起来讲完。

有未知,就有预知。有预知,就有无知。

我们回到现实。中国 SaaS 的基本市场情况,我叫它“捡烟屁股”。

在两三年前,美股 SaaS 还没如此规模的、成批量的爆发,该领域国际资本还未外溢到中国,大部分 ToB 人只能徘徊在中国经济主体之外,捡着中国经济发展的缝隙,寻找客户,像在捡别人抽剩下的烟。

SaaS 产品通用性根植于目标市场中实践和流程的通用性,不能凭空编造而来。

而在中国企业中,由于通用行业范式的缺失,市场竞争机制的不透明、甚至不可控制、无法预测,市场主体的经营管理模式千奇百怪,行业和区域间沟壑纵深。由此得出推论:中国的企业软件模式,必然体现为“主干小、四肢大”的“向日葵模式”

以竞争为核心的市场,天天看的都是对手,打的是情报战。以客户为核心的市场,眼光才能看向客户,打的是服务牌。只有后者,才会行业有长久效益,也才有持久增长的基础。

而对于发展中国家而言,最高效的办法,其实就是最土的办法:抄作业。然而,如果抄个答案,没理解过程,无法推一反三,必然在中国这片迥乎不同的土壤中,无法得以应用。必须把信息拆开揉碎,消化掉,变成自己的养分,并因地制宜地创造最佳方案。这种“既有方案分析、拆解、组合、应用”的思路,和发达国家的“探索创新”模式,对资源、人员、理念的要求完全不同,也不应追求相同。

产品经年累月积累的那剩余 80% 的功能,就只为满足剩余 20% 客户中的一小部分。很多产品能力,我扪心自问,没有信心哪怕 2% 的客户能够使用到,但为了“未来可能出现的需求情况”,仍然会做到主线版本中。这和纯粹做交付和服务比起来,毕竟有产品在,肯定要更好。但距离理想仍然很遥远:这是偷懒的做法,给了自己在“做产品”的虚假预期,得以获取心理慰藉,其实还是在做交付,只是把交付做进了产品。

原文链接:https://mp.weixin.qq.com/s/DltDGK5BCjnwW-n1V2OElQ

读《聊聊‘架构’》— 尚不够架构

内容摘录:

  • 业务和架构,是压在软件从业人员身上的两座大山。页软件从业人员手上却只有一个武器:技术。可是这个武器还时灵时不灵,
  • 业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题,心里面厌恶,却又无法逃避。
  • 架构的目的并非产生一个业务之外新的东西出来,只是为了让业务长得更加高大强壮,服务于更多的人。
  • 做架构的人必须亲自体验业务,感受业务,才可能真正认识业务的个性,真正认识业务所面临的问题。
  • 识别问题这个能力基本上就决定了架构师的水平。
  • 识别了问题的主体,自然而然地就附带了这么多的隐含信息。挖掘出隐含信息,就自然而然能够问出来其他问题了,
  • 架构切分实际就是对利益相关人的利益进行切分或合并,使得每个利益相关人的权责是对等的,每个利益相关人可以为自己的利益负责。
  • 架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。
  • 一个好的架构拆分,会形成一棵树,慢慢会长成一片森林。
  • 架构的目的就是为了增长。
  • 架构师有权力的同时也有其义务,也是权责对等的。架构师要时时把增长放在自己的第一考虑要素,把识别核心生命周期及其主体作为第一思考,这样才能确保权力的合理分配,保证增长的效率。这是真正的架构师和普通人思考的区别。
  • 要知道,工作是否完成由业务人员决定,而不是软件工程师自己。
  • 随着对业务的熟悉,对时间的恐惧才会慢慢地消失。对业务领域理解得越深入,就越知道如何去发现问题,慢慢就成为业务专家了。
  • 形象一点说,业务是硬币,架构和技术是硬币的两面。
  • 要知道开源的只是代码而已,而代码并非软件生命周期的核心。
  • 软件生命周期的核心是代码的运行生命周期和用户访问生命周期,而不是代码的建立生命周期。
  • 很多软件工程师学了大量的算法和计算机基础,然而在工作中发现派不上用场。这是非常正常的,因为这些内容是为了在科学领域做研究准备的。而在业务领域,大多是如何把现有的业务在软件中模拟出来的问题,并没有太多高深的数学问题。
  • 软件的拆分必须要和业务的拆分对应起来,
  • 很多人总是拆不好的原因,就是忽视了业务生命周期的分析。因为软件的核心是模拟业务,而业务代码又是按照业务的生命周期组织的,
  • 大数据其实说的是新的针对大量数据的处理技术,并非“大数据”这个概念表面文字那样是说“数据”本身。
  • 数据库事务只应该存在于和数据库打交道的存储代码中。

 

推荐你去品一品此书。

20210110221948