接了个印度客户的单子，沟通成本比开发成本还高，但学到了一课

返回 🍼 经验分享

接了个印度客户的单子，沟通成本比开发成本还高，但学到了一课

n65814788 0

2026-06-17 10:15 · 9 次浏览 · 0 条评论 · 0 cool

上个月接了个印度客户的App外包，报价时低估了沟通成本，做完一算，开发时间40%，沟通时间35%，返工时间25%。亏是亏了，但学到了一课，分享给独立开发的朋友。

客户背景

印度一家做物流的小公司，想做个司机端App，功能不复杂：接单、导航、签收、上传回单。我报了3周，想着这种CRUD活，以前做过类似的，复制改改就行。

第一个坑：需求理解偏差

客户说"司机要能看到所有待接订单"。我理解的是列表页，按距离排序。客户实际要的是地图模式，订单以气泡形式显示在地图上，点击气泡看详情。

这个差异在需求文档里没写清楚，客户以为"所有待接订单"默认就是地图模式，因为印度司机普遍文化程度不高，看列表费劲。我在中国做惯了列表页，没往地图方向想。

发现这个问题时，已经开发了5天，列表页做完了。返工3天，地图集成+气泡交互+详情弹窗。

第二个坑：网络环境假设

我做惯了国内项目，默认4G/5G覆盖，网络稳定。印度很多地方2G信号，网络断断续续。客户没说，我也没问。

上线测试时，司机上传回单照片，一张3MB，2G网络下传不动，超时失败。我加了断点续传、图片压缩、离线缓存，又返工4天。

第三个坑：支付方式

客户说"支持UPI支付"。我以为集成个UPI SDK就行，结果发现印度UPI有十几家银行接口，每家SDK不一样，而且有些银行要求本地服务器做签名验证，不能纯客户端处理。

最后折中方案：集成Google Pay和PhonePe两个主流渠道，覆盖80%用户。剩下20%走货到付款。客户勉强接受，但明显不满意。

第四个坑：时区和节假日

印度有多个时区，但客户没提，我默认UTC+5:30。结果客户公司在德里（UTC+5:30），司机有在加尔各答（UTC+5:30，但日出日落时间差一小时），还有在东北部用缅甸时间的。

更坑的是节假日，印度节日多且各邦不一样，排灯节全国放假，但其他节日各邦自己定。调度算法里"工作日"逻辑全要重写，加了时区和节假日配置表。
沟通成本怎么来的
 
时差：印度时间比中国晚2.5小时，我上午10点他们早上7:30，能重叠的沟通窗口只有下午3-6点（印度中午12:30-下午3:30）
 
英语：客户技术负责人英语还行，但业务负责人口音重，视频会议经常pardon三遍
 
需求确认：每次确认要邮件+即时通讯双通道，邮件留痕，即时通讯澄清细节，缺一不可。

学到的一课

接海外单，报价前必须问清楚：

1、用户画像：文化程度、设备情况、网络环境、使用场景

2、支付和合规：本地支付方式、数据存储要求、隐私法规

3、时区和节假日：多时区？节假日怎么算？

4、沟通机制：时差重叠窗口、确认方式、变更流程

这些问题在需求文档里通常不会写，但直接影响架构设计和开发成本。我现在接海外单，报价前先发一份"项目信息确认清单"给客户，填完再评估。

清单里有20多个问题，看着繁琐，但能筛掉一半不靠谱的客户，也能让靠谱的客户更重视需求定义。

现在的状态

印度客户后续维护还在做，但按小时计费了，不再固定报价。又接了个东南亚客户的单，这次先发了清单，沟通顺畅很多，目前进度正常。

海外单单价高，但隐性成本高。不是不能做，是得把成本算清楚。

原创

0 cool

暂无评论，来说两句吧

登录后评论

系统版块

兴趣版块全部

接了个印度客户的单子，沟通成本比开发成本还高，但学到了一课

评论 (0)

系统版块

兴趣版块 全部

接了个印度客户的单子，沟通成本比开发成本还高，但学到了一课

评论 (0)

兴趣版块全部