https://blog.cpdd.fyi/tags/%E5%A4%96%E5%8C%85/Recent content in 外包 on Zampo BlogHugozh-cnFri, 29 May 2026 17:31:00 +0800https://blog.cpdd.fyi/posts/i-thought-coding-was-the-job/Fri, 29 May 2026 17:31:00 +0800https://blog.cpdd.fyi/posts/i-thought-coding-was-the-job/<p>第一次接外包的时候，我以为只要把功能写完，钱就该到账。</p> <p>页面能打开，按钮能点，数据能存，接口也没报错。按我当时的理解，这活已经结束了。客户那边却开始问：为什么这个地方和一开始说的不一样？为什么今天不能先给我看一版？如果后面我还要加几个字段，是不是也包括在里面？</p> <p>我那时很烦。</p> <p>心里想的是：你又没说清楚，我怎么知道。</p> <p>后来想想，问题恰恰在这里。客户没说清楚，我也没问清楚。我们都以为对方懂，最后谁都不懂。</p> <p><img src="https://blog.cpdd.fyi/images/i-thought-coding-was-the-job/cover.svg" alt="程序员工作的另一面"></p> <p>那次以后，我才慢慢意识到一件有点残酷的事：写代码只是程序员工作的可见部分。真正决定一个人靠不靠谱的，往往是代码之外那一大块。</p> <p>代码是入场券，信任才是长期饭票。</p> <h2 id="外包教我的第一课功能能跑不等于事情做完">外包教我的第一课：功能能跑，不等于事情做完</h2> <p>接外包最容易给人一种错觉：需求来了，报价谈好，开干，交付。</p> <p>听起来很像写作业。题目摆在那里，答案写出来就行。</p> <p>但真实世界不是这样。</p> <p>真实世界里，需求经常是半成品。客户说“做一个后台”，你脑子里出现的是权限、表单、列表、导出、日志；客户脑子里可能只有“我想让员工少用 Excel”。你以为他要的是系统，他要的其实是省事。</p> <p>你如果不问清楚，后面每一步都会变成账。</p> <p>“这个也要收费吗？”</p> <p>“不是说后台都包括吗？”</p> <p>“能不能先做简单点，后面再改？”</p> <p>这些话听多了，新手程序员很容易觉得对方不专业。可再往后干几年，你会发现，客户不专业才是常态。让不专业的人把需求说得能被实现，本来就是工作的一部分。</p> <p>这不是让程序员去当销售，也不是让你跪着服务甲方。</p> <p>它只是在提醒你：如果一件事最后要由你交付，那你就不能只管代码怎么写。你还得管这件事在别人脑子里长什么样。</p> <p>我后来给自己定过一个很土的规则：开工前，一定要问三个问题。</p> <p>这个功能做完后，谁每天会用？</p> <p>什么情况算完成？</p> <p>如果中途要改，怎么重新算时间和范围？</p> <p>这三个问题听起来不高级，却能挡掉很多后面的崩溃。</p> <p>很多争吵不是因为代码差，而是因为一开始没人把“完成”两个字说清楚。</p> <h2 id="计划赶不上变化不是例外是日常">计划赶不上变化，不是例外，是日常</h2> <p>第二个坑，是我曾经特别相信计划。</p> <p>我会把功能拆得很细，登录两天，列表一天，导出半天，部署半天。排完以后看着还挺漂亮，像是真的掌控了项目。</p> <p>然后变化就来了。</p> <p>客户临时说，导出格式要按他们财务习惯来。产品说，这个字段先别做，换一个更紧急的。测试说，线上老数据有脏值，接口一跑就炸。老板说，客户下周一要演示，能不能提前给一个能看的版本。</p> <p>你会发现，计划不是没用，但计划不是护身符。</p> <p>计划最大的作用，不是证明你一定能按时做完，而是当变化发生时，你知道自己在牺牲什么。</p> <p>新手最容易犯的错，是变化一来就闷头改。别人说加一个字段，你加；别人说页面换一下，你换；别人说“顺手”再做个筛选，你也做。最后时间爆了，锅还在你身上。</p> <p>因为在别人眼里，你一直没说不行。</p> <p>程序员最难学的一句话，不是“不做”，而是“做可以，但要换掉什么”。</p> <p>这句话比发脾气有用，也比硬扛靠谱。</p> <p>你可以说：这个需求能做，但会挤掉原来周五上线的导出功能。你也可以说：如果只是演示，我可以先做假数据版本；如果要真实可用，就要多一天处理权限和异常。</p> <p>这不是推脱。</p> <p>这是让所有人一起面对代价。</p> <p>工程里没有免费的“顺手”。只是有人提前讲清楚，或者有人最后熬夜还债。</p> <p>更麻烦的是，很多程序员以为沉默是一种稳妥。</p> <p>需求没想清楚，先不说；时间有风险，先不说；方案里有坑，先不说。等到问题真的爆出来，再拿一句“我早就觉得这里不太对”给自己找台阶。</p> <p>但在协作里，晚说和没说差不多。你心里知道，不代表团队知道；你觉得明显，不代表别人也看见了。</p> <h2 id="进公司以后代码反而没那么自由了">进公司以后，代码反而没那么自由了</h2> <p>从外包进公司后，我一开始还松了一口气。</p> <p>终于不用每天和客户来回扯了。公司里有产品，有测试，有项目经理，需求应该会清楚一点吧？</p> <p>很快我就发现，想多了。</p> <p>公司里的复杂度不一定比外包低，只是换了一种样子。外包是你直接面对客户，公司里是你隔着产品、运营、老板、业务方、历史系统、KPI 和一堆没人敢删的老逻辑。</p> <p>评审会上，真正难的经常不是“这个功能怎么写”。</p> <p>真正难的是：为什么要这样写？为什么不是另一个方案？为什么你说要两周？如果只给三天，你能砍到什么程度？如果这次不做，会有什么后果？</p> <p>这些问题刚开始听起来像找茬。</p> <p>可它们其实在问同一件事：你知不知道自己在做什么。</p> <p>只会写代码的人，到了这里会很难受。因为他准备了一堆实现细节，却没有准备解释。他知道用什么表、什么缓存、什么队列，却说不清楚为什么这个需求不能顺手改，为什么这个接口不能直接复用，为什么一个看起来很小的按钮会牵到权限、审计和历史数据。</p> <p>评审会问的不是你会不会做，而是你知不知道自己在做什么。</p> <p>一个靠谱的工程师，交出去的不只是方案，还有边界感。</p> <p>哪些地方确定，哪些地方不确定；哪些地方能快，哪些地方快不了；哪些风险可以晚点处理，哪些风险现在不说后面一定会炸。</p> <p>这才是公司协作里真正值钱的部分。</p> <p>代码写得好，当然重要。不然你连上桌的资格都没有。</p> <p>但只会写代码，就像一个厨师只会切菜，不会看菜单、不懂出餐节奏、也不管客人什么时候到。刀工再好，也撑不起一家店。</p> <h2 id="学日语给我的第二个视角">学日语给我的第二个视角</h2> <p>后来学日语，我反而更能理解这件事。</p> <p>语言学习很容易让人误会。你背了很多单词，学了很多语法，刷了很多题，就以为自己会用了。可真到对话里，问题不是你知不知道某个词，而是你能不能在合适的场合，说出合适的话。</p> <p>同一句中文，翻成日语有很多说法。直接、委婉、客气、疏离、亲近，语气差一点，关系就变了。</p> <p>工作里也是这样。</p> <p>你说“这个做不了”，和你说“如果按现在这个范围做，风险会比较大，我建议先把 A 做完，B 放到下一期”，表达的是同一件事，听起来却完全不同。</p>