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