产品研发中第三方技术服务的管理

​  很多产品在研发过程中会使用到各种各样的第三方技术服务,比如百度地图、腾讯音视频、融云即时通讯、百度AI服务、CA等。这些技术服务以各种形式被集成到产品中,它们有的免费,有的收费。收费技术服务的收费类型也各种各样,有包月的,有包年的,有按流量的,也有按接入终端的。收费模式有固定价格的,有阶梯式的,也有打包套餐的。随着各种SAAS的兴起,为了节省开发成本,同时让产品尽可能缩短生产周期,越来越多的企业在产品开发中选择集成SAAS服务来提升开发效率。在享受第三方技术服务带来的好处同时,很多企业也注意到这些第三方服务也需要被有效管理起来,否则虽然看似缩短了产品开发周期,实则带来了更多的风险和问题。这些问题和风险主要体现在以下多个方面:

 

(1)技术服务选型不准确,导致产品在集成过程中发现很多需求无法通过这些技术服务实现。很多企业都有自己的供应链体系,通过负责供应链的组织来采购第三方技术服务。产品研发部门向供应链提需求,供应链负责找到体系内的供应商进行选型和采购。有些企业选型过程不完备,对产品熟悉参与产品实现的技术人员参与度比较低,第三方各种吹嘘,供应链自身又不熟悉技术服务具体的使用场景只能从名词上感觉好像是可以满足,导致选型的时候不准确,容易选成“感觉差不多”、“价格便宜”、“合作伙伴”的技术服务。

(2)技术服务质量不过关或者存在质量风险,导致产品在集成和发布后存在质量隐患,甚至直接达不到发布质量标准。这个问题比较好理解,比如某产品需要支持10万用户同时在线,在产品的某个AI功能上需要支持2000并发。在采购第三方AI服务环节,供应商吹嘘可以达到5000并发而且报价低廉,采购进来后产研部门发现只能达到1000,供应商倒也不推脱,也承认了自己的不足并且积极的配合整改,最终也达到了5000。到最后发现,原来这家供应商虽然通过了企业的合规拿到了供应商资质,但是AI服务还是它的一个新服务,它其实是想找个白鼠企业帮助它打磨它的技术服务产品。试想,如果这家技术服务商技术能力不过关,合同上又没有什么约束的话,会是什么后果。看得见的质量还好,看不见的呢?比如第三方技术服务的稳定性,隔三差五的给你来个服务中断、延迟。技术服务的质量评估工作在这里就非常重要了。

(3)技术服务安全性不过关,导致产品在安全合规方面达不到一些客户的要求。我曾帮助一个朋友的企业做过一款金融APP的安全测试,测试结果发现这个APP自身的代码都很安全,只有它集成的某个消息推送的第三方服务SDK存在大量的已知安全漏洞。金融行业对APP安全很看中,达不到对应的要求会严格禁止上线,最后不得不替换成另一家相对安全性更好的推送服务。

(4)技术服务使用不当,导致重复计费。有些粗心的技术人员在使用第三方服务的时候,不小心重复调用,导致技术服务流量翻倍,服务费用倍增。此外,有些技术服务是通过建立连接数来判断终端数进行计费,技术人员在实现的时候建立了多个收费连接。

(5)用量评估不准确等导致技术服务费用超高。举个例子:某个产品在研发过程中需要用到某个音视频服务,技术人员将技术服务的要求和需求都提给了供应链进行采购,由于技术人员不了解产品销售和运营的计划,没有很准确给出评估用量。很多技术服务其实是有阶梯式收费模式的,而供应链可以根据服务未来的用量来跟供应商进行议价。如果用量评估不准确,可能会多付出不少技术服务费用。

(6)技术服务商技术能力不过关,技术支持不到位。供应商提供的技术服务往往都是标准服务,产品研发在引入的时候可能需要做一定的定制化。有些定制化是额外收费的,也有些定制化是包含在合同费用里的。费用事小,如果引入后,发现供应商定制化的能力弱,搞不定产品私有化的场景,那问题可就大了。在选型前期如果能跟供应商的技术人员充分交流技术服务的应用场景,充分评估对方的技术实力,那会大大减少后期的这些风险。

(7)技术服务提供商稳定性差,给产品长期运营运维带来风险。前面讲过,这里不赘述了。

(8)技术服务账号信息的管理不到位,威胁信息安全和业务连续性。很多第三方的技术服务注册的时候需要提供注册者信息,比如个别免费的地图API。很多公司管理不到位,这些技术服务账号的注册往往是员工使用个人信息进行注册。一旦员工离职,如果不能及时交接,可能会对业务造成影响。注意,不是说企业一定要用公共的账号来注册,那太狭隘了。这里只是举个例子。

(9)技术服务的费用管理不到位,导致技术服务续费、费用结算、内部费用分摊等出现各种问题。技术服务在被产品集成发布后会随着产品交付到客户现场进入运营运维期,这个时候企业需要保证在客户的产品运营运维期里,技术服务必须稳定不能停。因此需要做到及时续费,同时为了避免出现用户已经过了运营运维期,技术服务还有很多流量没用掉,造成资源浪费。很多时候技术服务在产研阶段是不产生或很少产生费用的(很多技术服务提供商都会提供免费或试用期给你集成),更多的是在交付客户后运营运维过程中产生,因此为了精确核算每个客户交付项目的投入产出(费毛比啊、毛利率啊),往往需要将这些费用拆开分摊到各个交付项目上,这里面就会涉及到很多的财务操作。如果交付项目非常多,那这种操作的复杂度会异常的高,不仅仅涉及到怎么拆的问题,还会涉及到依据什么拆。

(10)技术服务的合同陷阱。前面好像提过,不赘述。

(11)技术服务的合规风险。比如技术服务有没有达到等保要求呀,是不是A国的产品。

上面每一点都可以展开来讲,篇幅有限,都放到后面再说了。为了规避和解决这些问题,我们总结了“第三方技术服务生命周期管理”的概念,类似于有些公司提到的技术管理,从生命周期角度来看怎么安全可靠的引入技术服务并对其管理。

 

请关注

(喜欢请转发,谢谢!)

加入爱测未来qq群,获取更专业的技术知识分享:

274166295  (爱测未来二群)

610934609  (爱测未来三群)

195730410  (爱测未来四群)

更多精彩文章:

谈谈你知道的发布上线(一)

漫谈测试平台—平台建设思路(上)

漫谈测试平台—建设模式探讨

为了干掉jenkins,我们设计了自己的调度模块

移动端H5调试与自动化

官宣!测试嘉年华报名开始了(内有福利)

出来混,是要有干货滴!!!测试嘉年华分享主题放送

Android兼容性测试应该怎么做逼格更高呢?

JVM性能调优

MTP-移动测试平台

性能分析之OS资源饱和度

前端性能监控

来自520的福利----视频直播平台性能测试

前端性能测试平台及应用

震惊性能测试圈的经典案例!!

在airtest中使用ocr反向识别文本内容

数据库性能分析与优化(爱测未来团队内训材料)

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值