程序员承接远程项目指南

筛需求的标准只有一条：对方能不能把要什么说清楚。开工前必须拿到三样东西，缺一样就先补，别急着报价。

第一样是功能范围，用列表写清要做哪些页面、哪些接口、哪些角色，并明确写出不包含什么。第二样是验收标准，把每条功能变成可以勾选的判定句，比如下单后三秒内收到通知。第三样是预算区间，哪怕只是个范围也行，它决定了方案该做到什么颗粒度。三样齐了，报价才有依据。

如果对方只给一句话需求，主动帮他整理。把你理解到的内容写成一页文字发回去确认，这一步既是筛选也是展示：愿意逐条确认的需求方，后面基本不会失控；不愿意确认的，早点知道也好。整理这一页通常只要二十分钟，却是整个项目里性价比最高的二十分钟，写完顺手请对方回一句确认收到。

扯皮几乎都发生在验收环节，而根源在开工前。验收标准要写成可勾选的条目，每条都能用是或否回答，不要用体验流畅、界面美观这类无法判定的说法。

修改范围同样要落成数字。常见做法是写明含两轮整体修改，单轮修改在多少个工作日内提出有效，超出部分按约定单价另计。把这句话写进去，比事后据理力争管用得多，也让需求方更容易一次性把意见收齐。

交付内容也值得单列一段：交付的是源码还是部署好的服务、包不包含部署文档、需不需要培训、质保期多久。版本上可以直接采用语义化版本的约定，用主版本、次版本、修订号区分不兼容改动、新增功能与缺陷修复，双方对着版本号就知道这次交付动了什么，追加需求时也有清晰的起点可以对照，不必再翻聊天记录。

单次成交最贵的成本是获取信任。同一个需求方第二次找你时，筛选、比价、试探这些环节全部省掉，所以长期合作的实际时薪往往远高于新客。

沉淀方式有三个。一是把每次交付整理成可展示的案例，写清背景、你负责的部分、用到的技术与结果。二是把重复用到的模块抽成自己的脚手架，第二次做同类项目时工期能明显压缩。三是交付后主动跟进一次使用情况，很多追加需求就是在这次跟进里出现的。

全球开发者的经验分布也说明了这件事的价值：专业经验 4 年以内的占 32.8%，5 至 9 年占 25.1%，10 至 19 年占 25.9%，20 年以上占 16.2%。人数集中在前十年，能不能被反复找上门，比资历更能拉开差距。

GitHub 上已有超过一亿名开发者，公开可查的作品和提交记录是最容易被验证的凭证。把技能主页、案例和关键词订阅在 WUJIEE 上一起配好，让匹配的远程职位与远程项目主动找上门，比每天刷列表高效得多。