






在进行同城配送系统的开发工作期间, 大家千万不要仅仅把目光锁定在那一份报价单上面。我亲眼见过许许多多的老板, 在一开始进行合作洽谈的时候就会急着去压价砍价, 结果等到系统正式上线之后, 就出现了各种各样的需要重新整改和返工的问题, 导致最终实际花费的资金数额反而比原来多出了两倍以上。
最容易被大家忽略掉的环节, 其实是关于路径算法的问题。你是不是实际去进行过配送工作相关的尝试呢? 当有一百个订单都堆积在了晚上的高峰时段, 如果调度程序里面的逻辑没有被正确地编写出来, 那么骑手就有可能在一天之内多跑上三十公里的距离, 这样一来所花费的油钱就变得完全没有意义了, 全部都白白的烧掉了。
这一部分的工作内容并不是通过简单地套用某种现有的模板就已经可以完全搞定的, 而是需要根据你所经营城市里面的交通管理规定、以及单行道路线的具体分布情况, 去做相应的实际调整动作。
订单拆合规则也不能显得模棱两可, 如果一个用户在同一个订单里选中了来自三家不同店铺的商品, 系统究竟是把它们合并处理还是分开处理? 万一配送时间超过了约定范围, 赔偿金额应当按照什么标准进行计算?

要是这些核心的业务规则在开发项目启动以前没有制定得清清楚楚明明白白的话, 等到项目后期再去修改相关逻辑的时候, 所付出的努力和时间成本会比从零开始重新编写整个代码还要艰难得多。
小型的商户, 大概需要三到四周的时间才能上线。但是, 那就是最简单的那种版本了。它基本上就只是一个接订单和派单的框架而已。如果真的要去做多商户的功能、实时的调度功能。还要加上骑手端的界面、商户端的管理界面以及整个系统的管理后台。
根据两个月起步这个情况来看, 这是很常见的一种常态表现。大家不要被那种号称一周就能交付完事儿的宣传广告给哄骗了。在大多数情况下, 这种做法很大概率是拿已经开源的项目来修改一下就直接用了。到了后期维护的阶段, 会存在非常多令人头疼的问题和隐患。
我常常建议还是先花费一周的时间把核心的流程给跑通, 绝对不要从一开始就把各种功能都堆积上去, 这样省下来的时间是足够你多进行三轮测试的, 这远比再多增加一个页面要更有用。
