如何建立和调整合作制度？
设计合作制度的目标是使规范化的合作发挥最大的集体效率。
并不是所有的工作都需要一个标准化的协作系统，对它的需求代表着业务已经足够成熟或者形成了一定的规模:需要标准化的协作方式和能力来保证业务工作能够有把握的完成。
因此，从设计目标来看，一个协同系统必然需要“分工的设计”和“结果的保证”。
为了解决角色之间相互协作的问题，还需要对协作过程进行管理。近年来管理领域对“精细化管理”的强调，其实是中国企业目前普遍拥有完善的职能团队，需要开始解决角色之间的冲突。
在国内大规模协作领域，最成熟、最规范的是“软件开发”，其方法论和实践极其全面。(你可以试着把你的日常做法和上面的模式匹配一下，看看你是服务于哪个环节。)
我们还可以从软件开发方法和实践的变化中找到反映该领域中日益复杂的协作系统和逐渐演变的证据。
早期的软件开发模式参考了工业流水线的管理模式，拆分了“需求分析、设计、开发、测试、上线”的线性步骤。
这种方式希望通过在规划设计阶段投入大量的精力，降低后续分工中的管理成本，保证最终成果的质量。
在某个阶段，在某个特定场景下，这种模式可以称得上是相当成功的协作系统，尤其是管理复杂度不高。
然而，随着市场软件R&D能力的进步，特别是互联网公司带来的冲击，业务变化对软件R&D响应的要求越来越高。此时，瀑布式开发仍然可以作为软件管理的协同系统，但难以解决响应性要求带来的新问题；
随着分工复杂性的进一步加深，甚至有必要在R&D过程的细分中进一步细化协作体系。
比如现在越来越受关注的“质量内置”这个概念，可以认为是进一步拆解了原来由某个特定角色(比如QA)负责的质量管理的工作，将特定的任务分配给R&D协作中的各个角色。
这个时候，并不一定是瀑布不能转化为具有这些能力的合作系统，而是适应瀑布开发模式的集体很难接受这些观念和认知上的变化；所以有时候没必要讨论方法论的优劣，因为谁对谁错不一定是真的；
环境变了，它面临的问题也会变；时代要求，新方法必然有更多的解释力，但也要正视旧方法经过长期改造后对集体各方面的适应性。很多时候，为了塑造真正变革的潮流，往往需要在形式上彻底否定旧势力。这时候就更需要思考如何用老办法传承价值了。)
在传统的管理方法中，协作系统依赖于“过程&；机制、实践和组织结构”；比如上面说的大规模创新，通常是通过设立创新机制来固化“优秀实践”来完成的；这两年银行业重新开始建立的“部落制”，就是通过组织架构设计来保证合作制。
在数字化程度高的领域，依靠数字化工具链承载协作系统，可以大大提高集体效率；例如，软件R&D团队越大，就越需要“Devops工具链”的帮助。
两种方法本质上没有区别，但由于成本/调整难度的不同，“数字化”手段在企业管理中具有更高的灵活性。
如上所述，当所面临的问题发生变化时，合作系统中不可避免地会发生摩擦，因此需要调整合作模式。
传统企业更多的惯性方式是增加/调整流程，因为“流程管理”已经是保证集体协作的重要能力。
问题是，首先，每一次工艺的改变，无论是时间还是人力都是极大的消耗，成本高，自然频率下降。
其次，当协作系统落地后，解决很多协作冲突并不需要复杂的流程设计，而是需要高频、细致的优化。过于复杂的流程设计增加了落地的难度和企业的管理成本。
这些问题是“数字工具”可以更有效发挥作用的方向。通过不断优化工具，而不是增加额外的流程，可以更频繁、更高效地解决问题。
例如，我的一个客户，团队正在调整和管理开发过程中每个环节的进度。流程需要产品经理、开发经理、测试经理等角色写一份月报，然后项目经理会把几份周报的内容整合起来。
每个团队需要提供不同的数据。在这样一个小场景中，设计了几套流程和模板来匹配不同的需求。
系统改造后，这些流程需求一下子就被释放了，因为这些协作的冲突本质上源于各个角色对无效工作量增加的反弹。正确的管理手段不是继续划分团队，明确谁该完成工作，而是直接提供协同服务。
用“数字工具”承载协作系统，代表了管理方式的一种本质进化:以“服务”减少角色间的协作摩擦，而不是通过流程/管理来规范每个角色的行为结果。
从这个角度去理解互联网公司的工作模式，你会发现，他们的产品和运营之所以强大，并不是因为组织里的人更聪明；
而是整个组织都依赖于数字化的产品和机制，即使是辅助职能也是围绕着相同且明确的目标工作，并能通过迭代异步地、一点一点地承担来自不同角色的贡献，最终转化为产品效率。