- From:
- idevlab
- Date:
- Subject:
Make It Happen
当组织本身成为工程对象
以前做软件，我们设计模块、组织数据、处理依赖，让一个系统按照预期工作。
后来，我们开始把开发交给 Agent。再后来，连任务拆分、执行协调和交付检查，也开始交给 Agent。在《写程序，越来越像治理一个组织》里，我记录了这种工作重心的变化。iDevLab Blog
现在，我觉得这不只是程序员越来越像管理者。
更准确地说，是工程的对象正在扩大：我们不仅在构建软件，也开始构建生产软件的组织。
我们希望实现某个目标，于是组合能力、建立联系、提供环境，让它运行；观察结果，再修改其中的结构。
我想把这种工作方式称为组织工程。
它最终要回答的问题很简单：怎样让一件值得发生的事情，真正发生？
一、把组织放进设计范围
组织工程的起点，是不再把组织当成一个已经给定的工作环境。
有哪些执行者，怎样分工，信息经过哪里，谁能作出什么决定，这些都可以进入设计范围。制度只是其中一部分；工具、知识、运行环境、资源配置和反馈，同样影响组织能够做成什么。
例如，我们要改善一个产品的首次使用体验。
这不一定意味着先建立产品、设计、开发、测试四个岗位。我们可以先把完整问题交给一个工作单元，让它调查障碍、提出方案、完成实验。出现值得并行的问题，再增加执行者；需要特定能力，再引入专业支持。
组合的依据，是工作需要怎样发生，而不是我们熟悉哪些职位。
如果两个执行者不断交换背景，也许应该把工作合在一起。如果一种能力被反复需要，就值得单独建设。如果一个决策总在等待远处的批准，就要检查信息和权限是否放错了地方。
这里的工程工作，不只是让每个执行者更强，而是改变它们之间的关系。
有时增加能力，有时减少交接，有时改变谁能看到什么信息。组织的表现，来自这些要素共同运行的结果。
二、设计条件，而不是写满步骤
把组织做成工程对象，并不意味着把所有活动预先编成工作流。
恰恰相反，我们需要区分：哪些东西应该稳定，哪些应该留给执行过程中的判断。
在《Plan 和 Task 的消亡》里，我已经尝试区分模型自己的做事方法，与组织必须保存的承诺、状态和授权。前者可以随着能力变化，后者不能靠模型临场记住。iDevLab Blog
放到组织层面也是一样。
我需要让它知道目标、现场事实、可用资源和边界，也需要让它接触真实产物、获得反馈。但调查顺序、任务拆分、执行者数量，未必都应该由我提前规定。
我们设计的不是每一个决定，而是让合理决定能够不断产生的条件。
协调本身也可以成为一种能力，被授权、调用和替换。人不必亲自安排每个 Agent，也不必亲自设计每一支临时团队。
不过，委托协调不等于交出全部控制。组织必须能够把无法自行解决的取舍带回来，说明背景、选项和影响，让人的判断真正进入后续行动。
这种系统既不是完全固定的流水线，也不是完全自由的群聊。它有稳定的边界，又能根据现场改变工作方式。
三、运行组织，也改进组织
组织工程需要同时面对两个结果。
一个是当前的事情有没有做成；另一个是，完成这件事之后，我们是否获得了更好的生产能力。
假设某次发布依赖人工反复追问才完成。把版本发出去，解决了眼前的问题；但还需要检查，为什么进展不能自行接续，为什么异常没有被发现，为什么必须由人补上那一步。
下一次改动的对象，可能不再是产品代码，而是信息入口、交接关系、验证方式或资源配置。
我希望组织因此形成两种持续活动：一边完成工作，一边根据工作暴露的问题改善自己。
这种改善也可以由 Agent 提议和实施，但不能只凭它说“优化了”。需要比较真实结果：等待有没有减少，错误有没有降低，投入是否值得，是否引入了新的问题。
组织结构不是一份需要永久遵守的答案，而是一组需要在运行中检验的设计。
与此同时，组织必须保留连续性。《MCP 跑偏了》里，我强调过，执行节点可以按需创建，状态、权限和产物不能跟着节点一起消失。组织也一样：执行者可以更换，业务积累必须留下。iDevLab Blog
我们才能在已有能力上修改，而不是每次重新开始。
四、Mini CTO 是起点，不是终点
当程序员开始这样工作，他确实越来越像一个 Mini CTO。
他不再只贡献自己的开发劳动，而是在一个范围内配置技术能力、组织生产、判断取舍，并对结果负责。
但 CTO 仍然是一个技术领域的比喻。
当这套能力扩展到研究、产品、设计、内容和运营，一个人面对的问题就不只是怎样实现，而是做什么、为什么做、投入多少，以及怎样判断它是否成立。
Mini CEO 或许更接近一些。
不过，我真正想表达的，不是每个人都会获得管理头衔，而是：
组织生产能力，有机会成为每个知识工作者都能够直接运用的能力。
一个人可以从自己熟悉的领域出发，调用其他专业能力，推动一件完整的事情。他仍然可以深入某项技艺，但不必因为无法亲手完成其他环节，就止步于一个局部岗位。
也不必每个人都从头搭建一家公司。已经形成的能力，可以共享、调用和重新组合。一个人所拥有的，不一定是一支固定队伍，而可能是构建和连接工作组织的能力。
因此，Mini CTO、Mini CEO 都只是帮助理解这场变化的暂时说法。更重要的，是个人与生产能力之间的关系改变了。
五、合作也会成为新的设计空间
当两个人合作时，他们带来的可能不再只是时间、知识和技能，还包括各自已经建立起来的生产能力。
这意味着，合作需要考虑的也不只是“你做前半段，我做后半段”。
哪些能力可以共享？哪些工作可以交给对方的系统？共同事实如何保持一致？遇到冲突由谁判断？怎样确认彼此的承诺已经实现？
这些关系本身，也可以成为工程对象。
未来它们会形成怎样的公司、团队或合作网络，我现在无法预测。可能出现新的边界，也可能继续保留许多已有形式。组织能否组合，还要受到成本、信任、权限和现实责任的约束。
但我们可以先把建立这种合作的能力做出来，而不必提前规定它最后长成什么样。
软件工程是目前的起点，不是最终边界。更多主要通过电脑完成的工作，都可以尝试进入这个设计空间，只是验证方式与自主程度各不相同。
Make It Happen，也不等于追求无人参与。有些判断值得人深入介入，有些工作适合确定性的程序，有些变化需要 Agent 自主处理。
工程的目的，是找到能让事情成立的组合，而不是证明某一种组合永远正确。
过去，我们在组织里做工程。
现在，我们开始对组织本身做工程。
未来，一个人能够推动多大的事情，或许将越来越取决于：他能否构建、连接和持续改善一套让事情发生的能力。
我们交付的不只是一个结果，也是一种能够继续创造结果的组织。