物流软件开发
物流软件所建模的物理世界并不配合。扫码枪会掉线，司机会开进隧道，而一个包裹无论系统知不知道它在哪儿，它都实实在在存在着。那些假定网络稳定、数据整洁的系统，恰恰会在它们本该发挥作用的条件下失效。我们设计物流系统时，是围绕断续与纠错来设计的，而不是围绕一切顺利的那条路径。
我们做什么
工作跨越仓库现场、运输途中，以及把两者串起来的报表体系。
- 仓储与库存系统，包括手持设备与可离线使用的界面。
- 运输与路线规划，以及面向司机的应用。
- 全程追踪，其事件历史能够承受乱序抵达的更新。
- 与承运商、海关、ERP 及客户门户的集成。
为断续的网络连接做设计
任何在仓库或车辆中使用的东西都会掉线。这是一项设计输入，而不是一次故障；把它当成故障来对待，正是这类系统不断累积人工绕行方案的原因。
- 离线优先的数据采集，先排队暂存，等网络恢复后再同步。
- 冲突解决规则事先定好，而不是临场发挥。
- 事件模型能容忍更新迟到或乱序抵达。
- 界面要能单手操作、戴着手套操作、在光线不好时也能操作。
当数据与现实对不上时
在物流领域，这种情况迟早一定会发生。真正的问题在于：系统是让这个差异可见、可纠正，还是把它藏起来直到客户打电话来。我们会把对账与纠错路径连同审计轨迹一并做进系统，让「修正现实」成为一项常规操作，而不是一次数据库改数。
常见问题
- 你们能对接承运商系统吗？
- 可以。承运商集成是这类工作的常规组成部分，而它们的怪癖——状态词汇不统一、Webhook 延迟、事件乱序——恰恰是设计必须吸收掉的东西。
- 你们为司机和仓库人员开发移动应用吗？
- 开发，并且在环境需要时具备离线能力。这里的真实场景可用性比多数软件都更要紧：冻僵的手、手套和糟糕的照明，都是实打实的设计约束。
- 你们能在我们现有的 WMS 或 TMS 上工作吗？
- 通常可以。替换一套还在正常运转的仓储或运输系统干扰很大，也很少是最省钱的路径。我们更常做的是扩展和集成正在运行的系统。