项目延期半年，我被软件外包坑惨了！

今天场主编译了一篇创业小哥哥的吐槽文，细数创业以来走过的坑。

希望创业/项目中的小伙伴引以为戒，处处避坑

多年前，年轻且天真的我决定与他人一起创业，同时兼顾全职工作。

我负责技术，另一位负责业务。MVP 计划是发布 iOS 和 Android App。

我有些开发经验，但从未开发过 App。从头开始学也不现实，于是打算雇佣外部软件开发人员来构建 App。错误就从这个决定开始。

合作始末

这不是我第一次创业。正是因为有过这种经历，我过度自信了

曾经也雇佣过一位年轻的兼职，算下李每小时收费不到 10 美元。当时，我并没有意识到这一点，人现在在旧金山挣六位数的工资。。。

找他没成，再加上另一位创始人也想请一个更知名的组织来管理我们的前端开发。因此，我们决定就找专业工作室,最终以每小时 25 美元的价格签下了一家。（明显高于同类的自由职业者）

众所周知，软件项目非常容易超支，所以我们协商签订了一份固定价格的合同，并对所有出现的 bug 都“保修”。花了很长一段时间后，我们才敲定合同细节，并在合同里详细描述他们应该构建的每个功能。然后，我们支付了第一笔款项并启动项目。

这里，我们犯下了致命错误！

根据合同协议，这个项目分为三个部分。在完成任何工作之前，我们就要预付 40% 的费用，然后每一部分开发完成时分别再付 30%。但是在我们收到刚完成部分的交付成果之前，由于我们是个初创公司，提前支付了 5 位数的费用，而且在完成下一笔付款之前没有获得任何可交付的内容，所以我们在整个项目期间都被锁定了。

虽然知道会发生这种事，但此时我们仍然相信我们找的机构，况且也没有发现什么危险信号。所以我们计划在整个项目中与他们并肩作战。

事后看来，那是我们做出的最糟糕的技术决定，给了我们的初创公司一个沉重的打击。

技术挑战

按照预期，这款 App 需要具备的一个关键功能是实时聊天。在合同谈判时，他们提出一些 SaaS 方面的建议来简化实时聊天功能的构建——其中之一是 Twilio Chat。

遗憾的是，在开始构建时，就遇到了难题。他们不知道如何在 React Native 中使用 Twilio Chat，尽管是他们最先推荐使用 Twilio Chat 和 React Native。

更糟糕的是，他们并没有坦白，而只是简单地告诉我们“Twilio Chat 不适用于 React Native”。现在，他们想让我们切换到一个完全不同的聊天服务提供商，然后重新开始，而我们需要为此支付额外的费用。

最糟糕的是，他们就没说过真话。Twilio Chat 用在 React Native 中完全没有问题——他们只是不知道怎么做。最终，作为一名没有任何 React Native 开发经验的开发者，我花了很多时间去研究解决方案，并教他们应该怎么做。即使在我向他们做了演示之后，他们仍然需要我给他们提供文档链接，并向他们解释如何使用 Twilio API。

这个决定可能会让项目推迟好几个月，并多花一大笔钱。

在安全上马马虎虎

我希望关于 Twilio 的问题就此结束，但这还没完。

所有 Twilio 聊天信息都属于一个通道，而通道可以标记为“私有”或“公共”。

顾名思义，私有通道属于通道中的特定用户，而公共通道可以“被非会员看到和加入。此外，公共通道及其成员和消息对于给定服务中的每个客户端端点都是可见的。”

显而易见，所有的非公开消息都应该使用私有通道来实现。但惊讶的是，他们都是用的公共通道——这是我在浏览 Twilio 控制台时看到的。

如果我们上线了他们的实现，但凡有一点点开发经验的人，就能够窃听每一个 App 用户的私人谈话。如果我自己没有发现这个问题，开发公司肯定不会安排任何渗透测试人员来发现这些安全问题。

这样的错误已经无法容忍了。更令人震惊的是，他们非但没有为自己的严重疏忽而道歉，还不愿意更改。

Bug 无处不在

我们之所以愿意雇佣开发工作室，而不是个人自由职业者，是因为他们承诺给我们的其他支持。特别是 QA 团队，他们会在向我们展示应用前进行详尽的测试。

任何软件项目都会遇到 Bug，这是不可避免的，所以我们理解他们不能做出任何承诺。但我们相信了他们的话，他们说我们应该只会发现一些极端情况下的 Bug。

后来才发现，这完全是一派胡言。我们从他们那里收到的所有交付满是 Bug。甚至最基本的功能都不能工作——我甚至怀疑，即使他们测试过，他们也不是用真正的手机测试的。

在整整一周的时间里，我和我的联合创始人每天都要花上几个小时，煞费苦心地测试，并记录所有出现的 Bug。

程序只求可运行

举例来说，我们发现的一个 Bug 是，如果用户的联系人超过 50 个，就只有前 50 个会在 App 中显示，其他的都无法访问。事实是，我们的一个 SaaS 集成被分页了，开发人员只实现了获取第一页结果的代码。

因为这个 Bug 只有在一个用户有 51 个联系人时才会被触发，而且我们尚处于私人测试阶段，所以我们过了一段时间才发现这个 Bug。之后，我们向他们做了反馈，问题很快就得到了修复。我们测试了他们的修复结果，似乎一切正常。

但在审查他们的代码变更时，我发现，他们的修复方式是多么的旁门左道。他们没有用一个 while 循环来获取所有的结果页，而只是简单地添加了一个 if 条件来获取第二页的内容。一旦用户的联系人数量超过 100，我们就会再次遇到完全相同的错误。

他们清楚地知道自己在做什么，知道“修复”的局限性，但还是那样做了。如果没有人仔细检查他们的代码，这个 Bug 就会进入生产环境。

没有版本历史

作为一名开发人员，我亲身体会到版本控制历史是多么有用。它可以帮助未来的开发人员了解为什么要做出某些设计决策，特定的功能是如何构建的，以及如何构建其他类似的特性。

出于这个原因，在合同谈判中，我特别坚持最后的交付物应该是一个 Git 存储库。他们欣然同意，并说他们内部也普遍使用 Git。

遗憾的是，在交付源代码的时候，他们只给我们发送了一个压缩文件，其中包含所有源代码和生成的文件。

我提醒他们，根据合同，他们应该给我们一个 Git 存储库。事实上，在他们发送的压缩文件中，我甚至看到了一个“.git”目录——表明他们在开发时确实在用 Git。

第二天，他们很快就给我们发送了一个 Git 存储库，其中只有一次提交，而里面的文件与前一天发送给我们的 zip 文件完全相同。

我抑制着自己的挫败感告诉他们，我们想要整个版本历史，而不只是一次提交，而且还是提交的同一个 zip 文件。他们回答说，他们的 Git 存储库中有一些“敏感信息”，不方便向外人提供。因此，他们不能分享给我们。“合同只规定交付 Git 存储库。但并没有说存储库中应该包含所有的开发提交和历史“。

随意改变规则

在谈判过程中，我们多次提到服务器端 API 还没有完全实现，希望后端开发和前端开发同时进行。

在项目开始时，我会把所有 API 端点提供给他们，其中一些会完全实现。这样，他们就可以使用这几个端点立即开始开发比较简单的特性。当他们完成这些功能时，用于下一批特性的 API 也就完成了。

我们的目标是避免延期，同时开展这两项工作，可以更快地推出我们的 App。这是我们预先明确并反复申明的内容。对方打包票没有问题。

付完钱之后，我们才开始听到一些完全不同的声音。他们直截了当地拒绝开始任何工作，直到整个项目中每一个特性用到的后端都 100% 完成开发并最终确定。

所幸，我们在合同谈判和设计工作上花费了大量时间，到后来几乎已经完成了后端开发。

严重延期

很遗憾，上述所有问题体现到了项目时间表上。原本应该是一个为期 2 个月的项目，最后却用了 7 个月。对我们来说，这是一个重大挫折，因为我们错过了许多潜在的用户，他们决定不再等我们的 App 发布。

现在回想起来，这些延误一点也不奇怪，因为他们缺少技术专家，坚持采用瀑布式方法，并拒绝通过聊天或电话直接沟通。但我怀疑，这还不是问题的全部。

我怀疑，在不同时段，他们有其他觉得更有利可图的项目，并因此降低了我们项目的开发优先级。这也是其开发团队在项目中途出现重大人事变动的原因。

经验教训

面对上面出现的所有问题，我很想说："离岸开发者很糟糕。"但是，这样的结论既狭隘也过于局限。我与来自其他国家的优秀工程师合作过，认为优秀的开发人员只存在于美国，是非常愚蠢的。

我也很想说，永远不要把开发工作外包。如果你的公司像谷歌一样成熟，或者是由风险投资公司资助的初创公司，那么一切都要自己构建，并且使用工资六位数的开发人员！

但是，对于一个创始团队规模不大的自给自足的初创公司来说，使用一些便宜的雇佣兵来帮助你完成 MVP 是有意义的。这是一个可以成功应用于其他场合的方法。

我们不禁会想，既然看到了上面出现的所有问题，那么应该可以通过谈判达成具体的合同条款来预防。

这种做法注定要失败。

有太多的未知因素和太多的主观性，不可能把所有东西都囊括在一个法律文件中。更不用说通过诉讼依法执行合同，这本身就是一个巨大的工程。

归根结底，当你雇用自由职业者或开发工作室时，重要事的只有一件，那就是：如果他们做得不好，你有能力离开他们。我们遇到的所有问题，都是因为我们缺少制衡手段。

更好的方法

合同一结束，我们就与他们断了联系，并大大地松了一口气。我真得感到卸下了一个大包袱。从此之后，我们从根本上改变了与外部开发人员的合作方式：

• 针对我们想要构建的功能，拟定一个顺序列表。
• 找几名开发人员，最好是独立的自由职业者，但如果同意以下流程，开发工作室也没问题。
• 对于每名开发人员，挑选列表中最重要的功能，与他们讨论功能需求、预算和成本。让他们实现那个特性并测试。
• 让一名内部人员审核他们的 PR，测试升级后的 App，并标出有问题的地方。
• 符合要求后，合并并部署该特性，这样，所有创始人 / 用户就可以继续审核该 App，并提供反馈或者根据需要调整。
• 如果我们对他们所做的工作感到满意，就挑选下一个我们希望他们实现的功能，然后再次重复这个过程。
• 如果我们对他们的工作不满意，就解雇他们，并寻找替代者。

我们采用了上面的渐进式方法，摆脱了巨大的预付合同，开发过程就变得非常顺利，非常令人愉快。开发人员与我们相处得更加愉快，也表现出了更大的灵活性，与我们的沟通也更坦诚，并在更短的时间内交付了更好的工作成果。

最重要的是，我们不会长期绑定到一个开发工作室，这使我们摆脱了风险，让我们感到无比安心，也很大一部分减轻了负担。

反过来，我相信开发人员也会喜欢这种灵活性。我们持续合作的内容是双方每周协商一致的事情，他们不会觉得是迫于先前的合同在做事。

如果你避免了我们的错误并雇佣了合适的开发团队，那么“大瀑布项目”是否有可能获得成功？

当然有可能，但是，你真有信心自己不会遇到同样的问题？这一系列的问题让我对敏捷有了新的认识，也理解了敏捷出现的原因。

• 客户合作胜于合同谈判
• 个体和互动胜于流程
• 可运行的软件胜于详细的文档
• 响应变化胜于遵循计划

事实证明，许多开发工作室都拒绝采用这种工作方式，而是坚持使用瀑布法，并签订大额的预付合同。啥也不多说，踩了坑自然就明白了

英文原文：https://software.rajivprab.com/2021/04/26/experiences-working-with-an-outsourced-dev-shop/

编辑整理：养码场（yangmachang0)