从客制化到产品化:ToB软件公司在经济寒冬中的生存指南

👆

点击蓝字 关注我们

 前言 

经济的冬天蕴藏着企业软件的春天

a11f285411ac662bd942e5ff11542804.png

在近两年的市场低迷中,"寒气"已经渗透至每个个体和企业,企业软件圈也是哀嚎一片,大家都处在一个不得不卷的痛苦状态。虽然大部分人不乐观,但我认为经济寒冬反而可能催生出更多ToB产品,为什么?

第一点,在预算紧缩的大环境下,传统的项目制开发模式变得难以为继,客户给的钱可能覆盖不了企业的成本,项目做一个亏一个。这迫使软件公司不得不转向产品模式,通过降低单价和增加销量来分摊成本,只有这样才能够存活下去。

第二点,最近我跟一个行业资深专家朋友聊天,共同的感觉是最近好像大家开始都做ToB了,大家一边说着ToB没前途,一边却又纷纷“下海”,为什么?这位专家朋友非常有见地,他的观点是,与ToC市场的两三个头部赢家通吃的竞争格局不一样,ToB的市场广阔且需求多样化,而且非常长尾,能够容纳更多的企业生存和发展

第三点,以往ToB的一大竞争对手其实是甲方的内部软件,以前经济环境好,大家都预算充足,人多钱多,企业往往倾向于自主开发软件。但在经济寒冬中,大家会重新评估并认识到其实采购外部成熟的软件可能成本更低,不再执着于自研工具

因此我认为,经济的冬天蕴藏着企业软件的春天,最冷的时候反而可能是中国ToB软件产品的起点。外部的客观环境倒逼着大家必须聚焦产品化战略,优化成本结构,按照产品化的路线去变革、去建设。

01

ToB软件公司的生存困境

寻找ToB软件公司的破局之路之前,我们先来分析大家在这个市场里面对的困境是什么。

在传统的项目制模式下,ToB软件公司常常面临招采周期长、客户需求高度个性化、公有云接受度低等问题。这些问题导致开发成本居高不下,产品难以形成规模效应,从而严重制约了公司的持续发展和市场竞争力。

1

招标采购周期长

ToB软件公司的销售过程通常涉及复杂且冗长的招标采购流程。与ToC市场的个人客户快速决策不同,ToB市场的采购决策通常需要经过多层次的审批和严格的合规检查。这不仅延长了销售周期,也增加了销售成本,长时间的招标采购周期意味着公司必须具备足够的资金和资源来支持长时间的运营。这对许多中小型ToB软件公司带来了巨大的财务压力。

2

客户需求千差万别

ToB市场的客户需求往往具有高度的定制化特点。每个客户的业务流程、管理规范和技术要求都可能有所不同,这使得标准化产品难以满足所有客户的需求。

为了获取客户,大家通常不得不提供高度定制化的解决方案。这不仅增加了产品开发的复杂性和成本,还可能导致后续产品维护和升级困难。

3

客户倾向私有部署

尽管云计算技术已经成为一种趋势,但许多ToB市场的客户仍然对公有云持保留态度,尤其是涉及敏感数据和严格合规要求的行业,如金融、医疗和国央企机构等。

这意味着ToB软件公司必须投入大量资源来开发和维护私有部署解决方案,需要具备强大的本地化部署能力和完善的技术支持体系,以满足客户对私有部署的需求。

4

“面粉比面包贵”

近年来中国互联网行业的高速发展推动了软件开发人员薪酬的快速增长,但在研发成本大幅增长的同时,市场和客户对于ToB软件的付费意愿却没有明显提升,再叠加私有化部署和定制化开发的重投入,导致软件产品的销售收入很难完全覆盖研发成本,或者利润非常薄。

02

在困境中寻找生存之路

从冗长的招标采购周期,到客户需求的高度定制化,再到对私有部署的高要求和研发成本的压力,面对这些挑战,ToB软件公司必须具备卓越的产品管理能力和灵活的技术解决方案,才能够找到自己的生存之路。

这里我们也提一下最近的流量密码——IPD,随着飞书、钉钉等相继发布IPD解决方案,引起了业界广泛讨论,仿佛IPD是万能灵药,照着干就能成功。

我们不否认IPD理念的优越性,但是IPD适用于硬件开发或软硬结合的复杂系统开发场景,适合超大型企业管理。所以不建议国内的ToB软件公司盲目学习照抄,而是思考和寻找更轻量、更适合自身情况的管理方式。

汲取客户及行业的经验与教训,结合多年来对Agilean自研工具产品——知微的管理方式探索,我们总结出了ToB产品的9大主要管理策略或实践,并认为做好这9件事,能够大大增加软件公司在这个冬天活下去的概率。

3a572a16907e39ad1a16b4197256af09.png

(图1:ToB产品9大主要实践)

1

组织:产品为主、项目为辅的组织结构

组织结构应服务于组织战略。作为一个以产品为中心的软件公司,组织结构上也应该是以产品为中心的。结合Adapt方法论,我们认为应该在产品线下设立虚拟的产品部落,作为面向产品能力建设的作战单元。

产品团队的人员都应该归属于产品部落,但可以临时派出去客户现场做项目交付,也就是说项目组是产品部落的派出形式,但是在项目交付的过程中依然是以产品为轴心,涉及客户需求到产品需求的评估转化依然应该由产品部落的核心角色成员进行把关。

2

角色:建立产品化“铁四角”职责体系

在产品化转型过程中,我们建议构建项目经理、解决方案专家、产品经理、产品架构师的“铁四角”职责体系。

产品经理:负责分析、评估、细化客户需求,取舍产品做什么

产品架构师:作为一个技术角色,主要负责评估怎么做,需要在需求实现设计过程中去判断和决策,客户所需要的功能应该做成扩展功能还是一个标品功能,或者是否用插件的形式来满足客户。

项目经理:这个角色大家都比较理解,主要需要负责跟客户去沟通和控制范围,让项目能够交付成功。

解决方案专家:比较特别的是我们在这里增加了解决方案专家的角色,主要负责在接收到客户的需要后进行转化,就像一个“翻译”,将客户的问题和产品的能力进行连接,对外可以引导客户,对内可以帮产品统归同类型的产品需求。因此这个角色有点像更高级别的产品经理,在能力上既要非常懂产品,也需要懂市场和客户并且有较强的沟通技巧。

通过“铁四角”职责体系,可以确保从业务需求的梳理到产品架构的守护,从项目交付到解决方案的引导,每个环节都有明确的责任主体。

3

需求:建立两层需求管理体系

在做产品的时候,需求的输入来源可能是多方面的,因此先建立业务需求这一层,相当于产品对外的接口,用来承接客户原始的诉求,以及承担着评估分析做不做、怎么做的需求转化过程,也就是解决方案专家、产品经理和产品架构师核心要做的事情。

业务需求需要被分析、拆解或合并、设计,然后才能转化成下一级的产品需求,流入研发团队。

通过业务需求-产品需求这两层需求体系管控,能够让产品团队有更多产品化方面的思考,这样才能维持产品的单一主干。

4

架构:核心稳定、灵活扩展的技术架构

每次一谈及产品化,许多人会提出疑问:如果产品坚持主干开发和管理的模式,那如何满足不同客户的需求呢?关键就在于构建一个既灵活又稳固的软件产品架构,这一架构不仅要有坚实的基础,还必须具备高度的适应性和扩展性。

如图2所示,首先,软件产品应建立在一套稳定且功能完备的基础架构之上,这包括产品的核心功能,它们是产品价值主张的基石。其次,围绕基础功能,发展出配置层、插件层、对接层和数据公开层,它们共同构成一个柔性的能力层,像保护罩一样包裹着产品的核心功能,使得产品能够灵活地化解、适应和满足不同客户的独特需求。

07cf8956e92d5719c4c569fd84144789.png

(图2:产品化软件架构图)

这种设计不仅保护了产品的核心主干,避免了频繁的修改和客户分支,也提高了产品的可维护性和可扩展性。这种设计与平衡是实现产品化的关键。

5

底座:适合B端私有部署的技术底座

SaaS模式其实为ToB软件提供了一种灵活、高效的交付方式,它通过云端平台向客户提供软件应用,从而简化了软件的部署、维护和升级流程。

但不幸的是,这种模式在国内并没有得到广泛的认可和采纳,国内许多企业出于数据安全、隐私保护和定制化需求的考虑,更倾向于选择私有部署的解决方案。

所以在这种环境里做产品,必须审慎选择技术底座,以适应国内客户的特定需求,提供更高的数据安全性和更灵活的定制选项,降低软件的安装、部署和运维的成本。

6

单线:建立主干开发分支管理模式

首先需要说明的是,这里我们说的主干开发分支管理模式(OneTrack),是偏向于管理上的单主干,不是代码的单主干。

单主干管理的核心策略是不在老版本上做新功能,因为维护多版本同时活跃的成本极高,一旦同时加功能,难度非常大,产品的架构管控会变得非常困难。

单主干管理模式的实现既需要产品研发团队的坚持,还需要销售和商务人员在面对客户时也能够坚守得住,因此这也是个一把手工程。

7

质量:基于接口测试的质量守护体系

产品质量与成本控制紧密相连,同为产品开发过程中两个关键的考量因素。如果产品不是单主干管理模式,要想在维护多个版本的同时保障产品质量,会迅速增加成本并带来复杂性。

例如,如果一个功能需要在多个版本上进行维护,那么相应的测试案例也可能需要为每个不同环境编写多套,这不仅增加了测试的难度,也给质量管理带来了巨大挑战。在这种模式下要想管得好必然需要付出极大的成本,导致公司的成本模型失控。

因此在产品化转型的过程中,坚守OneTrack开发模式,建立基于接口测试的质量守护体系,不仅能够提升产品质量,还能够实现成本效益和维护简便性的双重目标。

8

节奏:建立产品双周版本发布机制

小步快跑也是产品化的一个重要能力。建立产品双周版本发布机制,这种敏捷的开发节奏可以加速产品能力迭代,通过小批量、快速的发布,及时发现问题、解决问题,以避免出现较大的质量缺陷。也可以及时地从客户那里获得反馈,并将这些反馈转化为产品改进的动力,积小胜为大胜。这样的节奏策略一方面可以控制整个产品开发的成本,同时也能够降低客户的风险。

9

透明:产品管理全流程线上化平台

最后一点是建立产品管理全流程线上化平台,实现产品规划、版本计划、需求交付的端到端管理,将产研团队的协同进行可视化,同时透明产品部落的长期能力建设情况和短期项目的交付情况,在提升管理透明度、加强团队协作的同时,透明资源与成本,优化决策过程。

这里打个小广告,我们的自研工具知微,是一个非常灵活、配置能力非常强悍的线上化管理平台,可以帮助软件公司实现产品全流程管理,支持产品研发端到端管理,拥有灵活的需求管理体系和精细的研发成本管理能力。感兴趣的朋友欢迎与我们交流。

03

写在最后

企业软件公司的产品化是一场深刻的变革,我们结合自身经验与思考,提供了一些破局和可能可以帮助ToB产品在现在的大环境下“苟住”的方式,以作参考。

我们深知,以上9点要全部做到是非常困难的,毕竟每家公司都有自己的生存背景和特点,这需要企业和产品管理者拥有极大的决心和极强的定力,因此读者可以取长补短,按需借鉴。

如果大家能够因本文有所感悟的话,可以从现在开始参考做出一些改变,希望这些改变能够让大家比之前的自己活得更好一些、更久一些。

END

本文贡献者:

吴穹、熊小龙、尹学罡、王海浪

d76a0f5d32f23bb3d0ca68bdb6d4b1fe.gif

分享

d8391eedd512480cb8277084443c6ea8.gif

收藏

551aaf22e6150f6e8cbd1af2a03f16c0.gif

在看

94859f769fbdbbe3516b09bb0173ba25.gif

点赞

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值