本篇要回答的问题：当分工跨越组织边界，传统外包、开源（众包）、云服务（服务外包）各自的本质与适用性是什么？一个企业该如何选择跨组织协同方式？
前几讲谈的分工大多局限在企业内部、甚至同一团队内。本讲把视野放大到跨组织的分工与协作——这是任何企业都无法回避的社会生态问题。
外包及其理想模型
外包 = 把软件全部或部分模块的实现职能交给外部团队。但软件外包成功率非常低，有其必然性：
| 失败原因 | 说明 |
|---|---|
| 任务表达模糊，易扯皮 | 能把需求边界、产品原型、业务流程说清的甲方，本身工程水平不低且少见；产品外包多见于不懂技术的甲方 |
| 交付代码质量低，维护代价高 | 软件工程要长久运行，但接包方质量参差，遇上 “搬砖” 概率高；有良好设计能力的团队多不甘长期做外包 |
| 交接困难，知识传承效率低 | 即使结果理想，交接也极难，故往往只能找同一拨人做二期三期 |
理想模型：外包实现，而非外包需求。 专业甲方自己做需求分析与系统概要设计，把每个模块的业务范畴与接口细化作为外包边界：
| 角色 | 在理想外包中承担 |
|---|---|
| 甲方（只留架构师团队） | 需求分析、概要设计、定义模块规格与接口、规定数据库、规定单元测试案例、验收 |
| 接包方 | 模块详细设计的实现部分（核心是数据结构设计 / 表结构）、按规格交付 |
关键判断：这个 “假想实验” 揭示——平常项目进度无法达预期，无他，团队缺乏优秀架构师而已。把架构核心（模块规格 / 接口）牢牢把控，执行风险就基本消除。还剩最后一个风险：怎么证明架构分解是对的、模块不会拼不起来？答案在 “32 讲”——系统设计产出要有源代码原型，关键模块 mock，把关键 UserStory 串一遍以验证正确性。
开源与众包
开源是第二类外包，以众包形态出现：让全社会程序员共同完成一个业务系统。
| 维度 | 要点 |
|---|---|
| 优势 | 热门开源项目迭代惊人，撬动资源极大 |
| 风险 | 没人关注的开源项目迭代速度无保障，最终可能还得靠自己团队 |
| 本质 | 开源是一种商业选择，需持续经营：宣传、自己迭代、为它拉客户 |
| 适用范围 | 注定只能做大众市场 / 基础设施：语言、操作系统、基础库、框架、浏览器、网关、中间件等 |
关键判断：开源的另一种无形资产是——它让全球程序员、全球科技企业养成了一模一样的工程习惯，使无数企业的协同方法与业务流高度相似。这正呼应了 “团队的共识管理”：协作工作流的共识是团队效率的最大基础。
云计算与服务外包
把三类外包按 “是否对结果负责” 划分：
| 形态 | 交付物 | 是否对结果负责 |
|---|---|---|
| 传统外包 | 源代码 | 否（验收交货后用得好不好是甲方的事） |
| 开源（众包） | 源代码 | 否（完全免责，可买商业支持来分担责任） |
| 云服务（服务外包） | 服务（24 小时跨组织服务） | 是，有 SLA 承诺 |
云计算从协同角度看不过是一种新的交付方式：从源代码交付变为服务交付。其释放的生产力惊人：
| 云服务优势 | 说明 |
|---|---|
| 对结果负责 | 有 SLA，出问题由云方自己解决，无需业务方介入，极大降低耦合，各司其职 |
| 简化业务系统 | 让业务方专注真正的核心竞争力构建 |
外包方式的选择
七牛自成立以来的原则：
非核心竞争力相关的、能外包的尽可能外包；外包选择上，优先云服务，次选开源，最后才考虑传统外包。
这句话也有模糊处，需要厘清：
| 模糊点 | 更合理的解读 |
|---|---|
| 何为 “核心竞争力相关” | 不要 “技术化”（以为核心模块就是核心竞争力），而要用业务视角：与服务客户的业务流越相关，越不能外包，要自己迭代建立竞争优势 |
| 开源引入是否随意 | 不可随意引用！开源引入属 “基础架构” 选择，是架构师团队的职责，要有正规评估流程 |
补充：商业软件形态接近传统外包，但因有明确业务边界，品质通常远高于外包（除非定制过重而退化为传统外包）。
总结
跨组织协同有传统外包、开源（众包）、云服务（服务外包）、商业软件（产品外包）等形态。核心差异在于是否对结果负责（云服务负责，外包与开源不负责）。选择逻辑统一为：非核心竞争力尽量外包，优先云服务、次选开源、最后传统外包；而 “核心竞争力” 应以业务流相关性而非技术相关性来判断。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 外包实现 ≠ 外包需求 | 甲方留架构师团队做设计、定接口、验收，接包方只做实现 |
| 众包（开源） | 让全社会程序员共建系统，是需持续经营的商业选择，只适合大众 / 基础设施 |
| 服务外包（云服务） | 从源代码交付变服务交付，对结果负责、有 SLA |
| 核心竞争力判断 | 业务视角：越靠近服务客户的业务流越不能外包 |
一句话速记
跨组织分工就一句话：非核心的尽量甩出去，先云服务（它对结果负责）、再开源、最后才传统外包；而 “核心” 看的是离客户业务流多近，不是技术上多核心。
几条值得记住的判断
- 外包要外包实现而非外包需求——这反向证明了架构师团队的价值。
- 开源是商业选择，要持续经营，且引入需架构师正规评估，不能随手 import。
- 云服务对结果负责，是降低组织间耦合、让业务方专注核心的未来方向。
思考题
回到你的企业：你们现在自己造的轮子里，有多少其实可以用云服务替代？判断 “哪些不能外包” 时，你是按 “技术上是不是核心模块” 还是按 “离客户业务流有多近” 来划线的？
