养车优选--产品技术方案建议

养车优选--产品技术方案建议

需求概述

相对于传统电商，该项目有3个差异点：

1. 存在以主播明星为载体的商品推荐和内容输出，需要设计出将人、商品、内容三者相结合的产品页面和交互体验
2. 汽车后是相对独立业务场景，该业务场景与传统零售电商存在差异，需要深入该业务场景开发适配该业务场景的功能
3. 用户进入到小程序是基于内容触发（暂定），存在一定的冲动性而非沉浸性，因此需要缩短用户成交周期，诱导用户裂变分享

方案1:有赞、微盟、微店

• 价格：6888-13888 / 年

• 适合业务模型：

  • 有现成的客户渠道，仅需要一套线上契约和电子支付的商品订单系统完成交易闭环
  • 需要采用团购、优惠券、砍价等常规电商交易手段促使用户在已有的渠道内成单
  • 零售（拎袋产品）、教育、美业（对于这三个行业有较为深入的场景化解决方案）的升级

• 特点及优势：

  • 已开放的功能，基本没有bug，服务大量客户，稳定性好
  • 价格便宜
  • 维护成本低

• 需要评估的劣势：

  • 基本可以放弃自定义开发和自定义的产品需求
  • 无法在系统层面上招募下层代理商或经销商，不得应用较为激进的商业规则和玩法
  • 需要放弃信息技术的知识产权及商业价值

• 综合评价：

  • 对于现有商业模式和产品功能建议主要考量这两点
    • 使用该方案需要基本放弃明星主播这一板块，没有独立的板块展示主播和该主播推荐的好物，因为该功能目前不是电商系统的主流功能，因此没有提供
    • 深入的行业场景的相关功能需要放弃，例如教育场景和零售场景是不同的，教育场景下有特定的功能需求，有赞在教育场景下的一些功能做得还是很好的，目前汽车后的场景没有专项解决方案

方案2:技术合伙人

• 基本概念：互联网产品开发需要产品设计、美术、程序、测试、运维等多个职能位置的人共同协同完成，是个深度依赖人力的行业，因此成本构成可以相对简单的换算成【人天】，即多少人花多少天的人工成本

• 5%技术合伙人股权 + 初期基础开发费用（小于等于10万，具体需要深入服务场景确认功能细节才能相对准确计算出人工成本）+每月维护费用（常规6000/月，含服务器费用，修复bug，上线当月活动，功能优化，不含美术，如有大规模功能调整和大型异业联动单月成本会大幅上升）

• 适合业务模型：

  • 业务依赖于技术产品进行变现，且技术方案与常规方案存在差异，或随业务变化而不断变化
  • 对自有知识产权带来的商业价值存在一定程度上的依赖
  • 初期资金或行业资源不足以组建成熟的技术团队或团队缺失懂产品懂技术的人

• 特点及优势：

  • 相对于纯粹的外包，成本更低或更透明，更有持续性
  • 相对于购买SaaS，有自有知识产权和可调整业务的空间

• 需要评估的劣势：

  • 总体成本会比购买SaaS多很多
  • 是否有必要引入技术合伙人

• 综合评价：

  • 最重要的还是评估业务对产品技术的依赖度，这个拿我的个人经历的case举几个例子
    • 星网锐捷，这不说了，大型科技公司
    • 中瑞，转型影院服务商，大量服务基于SaaS，可以简单理解为电影行业的微店，深度依赖技术
    • 蛙哈，儿童影像App，创新型产品，行业没有类似的解决方案，没有可选择的服务商，且深度依赖于用户活跃度和温度，产品随时调整，入不敷出天生ToVC模式，只能自己干
    • 社交电商，因为涉及分销和各级代理，处于监管领域的边缘，几大服务商都不敢在此过于越界，不同团队玩法差异极大，独立开发和租用的都有
    • 教育培训，服务商有深入行业的解决方案，直接买现成的

方案3:外包开发

• 价格：预估15万（具体需要深入核对需求，确认产品细节，该金额仅为初步预估参考）

• 适合业务模型:

  • 有成熟的产品销售渠道，需要通过线上系统将渠道进行规整，或用户沉淀依赖于线上
  • 产品销售依赖于线上系统，且产品销售方式或传播方式有别于竞争对手，且深度依赖于某些差异化的功能，而该差异化功能无成熟的服务提供商
  • 团队存在深度了解产品且略懂开发的成员，可以与外部合作团队同频沟通

• 特点及优势：

  • 可以快速建立并扩大己方差异化竞争点
  • 可以构建己方产品及技术壁垒，将成熟的想法和商业化方式快速落地

• 需要评估的劣势：

  • 需求不明确的情况下，将导致大量扯皮事件的发生，因此需求对接人极为关键
  • 双方合作建立在标的金额的大前提下，为了商业利益会尽可能地控制成本，从而影响产品质量、用户体验

• 综合评价：

  • 外包失败的案例非常多，失败结果不外乎三种，
    • 1是甲方拖欠款项乙方不堪重负系统崩溃
    • 2是乙方压缩成本交付bug具多外观老土体验糟糕的产品甲方投资打水飘
    • 3是双方就产品功能改来改去，改到双方都吐血两败俱伤，项目搁置。
  • 还是举例说明下，清香姐的外包开发算是相对成功的，因为多年的感情与互信，不存在1和2的问题，更为重要的是，清香姐了解大的业务方向，但不了解技术开发，因此她从不下场过问产品和开发细节，从不提问题也从不指责抱怨；
  • 她团队中有非常非常了解自家产品服务的伙伴，且之前遭遇过外包开发失败，交过学费，因此深度了解技术开发的周期、成本、质量和应急解决方案，因此在协同开发的过程中能够互相理解，且使用相同的语言符号，主开发方向没有进行过大的调整，这非常的重要。
  • 外包开发要成功，前提是互信+明确的需求