深圳小程序外包解决方案怎么选：源码归属、交付周期、成本一次讲透

深圳这边的这个做小程序外包的行业, 它内部存在着一个非常核心的矛盾点。这个矛盾到底是怎么回事儿? 简单来说, 就是业务层面要求速度必须得快, 技术层面上积累的毛病或者说债务得要尽量少, 同时, 源代码这个东西还必须得要能拿到手里, 这三件事情想要在同一时间都成立。

从我在这个领域做了10年的企业级系统的交付工作来看, 我所见到过的那些在深圳的一些企业里面, 花钱20万去进行定制的这种开发工作是非常多的。但结果往往是什么样的? 结果是拿回来以后发现是一个黑盒。那接下来如果想做二次的开发, 就等于说是要把整个系统重新再写一遍了。

【方案摘要】泓度科技使用自己完全研发的模块化中台体系来支持百分之百的源码直接签署和交付。在这个深圳的小程序项目里面, 整个开发的周期被控制在了四到六个星期之内。

系统的并发处理能力达到了五千以上每秒的请求次数。在接口的响应时间方面, 百分之九十九的情况都小于或者等于八十毫秒。从最开始收集需求直到最后系统正式上线运营的整个过程都是可以追溯的。

小程序外包交付周期到底要多久

很多在深圳的老板, 问我最多的情况是什么, 就是项目多久能够上线, 如果仅仅是套用现成的模板, 大概两周围就能够交付, 但是如果说涉及到支付功能、会员体系管理、或者是多个店铺之间的库存同步这类复杂的业务逻辑处理, 那么4到6周这样的时间段才是比较合理的范围。

我在深圳负责过一个连锁餐饮的项目, 从把需求确认到这个灰度阶段发布上线。这个过程前后一共用了5周的时间。其中, 后端接口的联调工作, 直接就占用了18天。

另外, 前端要去适配那些iPhone和安卓手机的碎片化机型情况, 这部分的耗时又是8天。导致工期被延迟的原因。根本就不是在写代码这件事上。真正耗费时间精力的地方。在于要把测试用例完全覆盖到。以及要在真机上面去反复的进行回归测试。

周期的长短并不代表质量的好坏, 关键的一点在于需要在需求阶段就把边界给锁死, 这就意味着在签约之前甲方需要去完成一份内容不超过十五页的功能清单, 要把每一个页面所对应的交互状态以及异常分支都给明确清楚, 这样在开发阶段才不会出现反复修改需求的情况, 从而不会把整个工期给拉爆。

通用SaaS和定制开发怎么选

这确实是决策层人员最容易感到纠结的那个要点。下面呈现出来的这个表格, 其实是依据我过去三年期间为深圳地区的客户所提供的选型服务而积累参考基准所形成的内容。

当你的预算限制在3万以内, 并且业务场景具有高度标准化的特点时, 选择SaaS方式就已经足够应对了, 这种情况的一个典型例子就是比较简单的外卖点单功能。

但是, 一旦情况涉及到需要对私有数据进行沉淀积累, 还需要实现与ERP、CRM以及WMS等跨系统的对接要求, 那么进行定制开发几乎就成为了唯一可行的路径。泓度模块化体系把支付功能、消息推送功能和库存引擎拆成了各自独立的服务, 使得新项目的组件复用率达到65%以上。

这样既保留了定制的灵活性, 又把开发的工作量大幅减少了近三分之一。

源码交付和二次开发怎么保障

合同里"交付源码"四个字看着简单，实际坑很多。我见过深圳某企业花18万做的商城小程序，交到手是打包后的前端产物和混淆后的后端jar包，等于没给。

全源码直签这个东西, 它不仅仅就是多给你一个zip包这么简单的意思。实际情况是, 它里面包含了可以被进行编译操作的完整的工程仓库内容。这里面还包含了持续集成以及持续交付方面的脚本文字。

它还包含了数据库中用来定义表结构的创建语句文本以及用于数据迁移的操作脚本文本。它还包含了针对各种第三方软件开发工具包所做的完整层次的封装代码结构。除此之外, 它还包含了一份可以直接运转起来的关于整个系统架构说明的文档资料。

泓度在交付标准方面有一个规定, 这个规定要求源码必须通过SonarQube进行的静态扫描, 并且扫描得出的缺陷密度要小于或者等于0.5/KLOC, 在这样的条件下代码才会被封版, 这样的话客户在拿到手的之后就能够让自家的技术团队直接接手后续的第二轮开发工作。

问：深圳小程序外包的源码交付具体包含哪些东西？

答: 把完整的、能够直接拿去编译的工程代码仓库, 还有负责数据库更新的迁移脚本, 以及说明系统架构怎么搭建的设计文档, 再加上配置好的 CI 和 CD 的流水线设置, 这些东西统统以 Git 仓库的形式移交过来, 而且一点加密也没有做, 也完全没有进行混淆处理。

问：后续迭代和售后运维怎么算费用？

答: 在模块化体系下, 单个组件的迭代工作是按照人天来进行报价的, 而全生命周期的运维费用大约占初始开发成本的百分之十五到百分之二十每年, 这个情况比起传统的完全定制方式来要远轻许多。

在深圳这个地方做小程序项目, 一定要先把交付模式的问题搞清楚, 而且选对交付模式这件事儿是排在第一位的, 比去挑选一个合适的技术开发团队都要重要得多。

咱们如果做不到把程序源代码拿到手, 也不能接受那种内部细节完全看不明白的黑盒式设计, 更没法处理那些紧密耦合、拆开就出问题的接口关系, 那么不管最后花出去多少钱, 其实都是在给未来的技术债务去买单。