設計合作制度的目標是使規範化的合作發揮最大的集體效率。
並不是所有的工作都需要壹個標準化的協作系統，對它的需求代表著業務已經足夠成熟或者形成了壹定的規模:需要標準化的協作方式和能力來保證業務工作能夠有把握的完成。
因此，從設計目標來看，壹個協同系統必然需要“分工的設計”和“結果的保證”。
為了解決角色之間相互協作的問題，還需要對協作過程進行管理。近年來管理領域對“精細化管理”的強調，其實是中國企業目前普遍擁有完善的職能團隊，需要開始解決角色之間的沖突。
在國內大規模協作領域，最成熟、最規範的是“軟件開發”，其方法論和實踐極其全面。(妳可以試著把妳的日常做法和上面的模式匹配壹下，看看妳是服務於哪個環節。)
我們還可以從軟件開發方法和實踐的變化中找到反映該領域中日益復雜的協作系統和逐漸演變的證據。
早期的軟件開發模式參考了工業流水線的管理模式，拆分了“需求分析、設計、開發、測試、上線”的線性步驟。
這種方式希望通過在規劃設計階段投入大量的精力，降低後續分工中的管理成本，保證最終成果的質量。
在某個階段，在某個特定場景下，這種模式可以稱得上是相當成功的協作系統，尤其是管理復雜度不高。
然而，隨著市場軟件R&D能力的進步，特別是互聯網公司帶來的沖擊，業務變化對軟件R&D響應的要求越來越高。此時，瀑布式開發仍然可以作為軟件管理的協同系統，但難以解決響應性要求帶來的新問題；
隨著分工復雜性的進壹步加深，甚至有必要在R&D過程的細分中進壹步細化協作體系。
比如現在越來越受關註的“質量內置”這個概念，可以認為是進壹步拆解了原來由某個特定角色(比如QA)負責的質量管理的工作，將特定的任務分配給R&D協作中的各個角色。
這個時候，並不壹定是瀑布不能轉化為具有這些能力的合作系統，而是適應瀑布開發模式的集體很難接受這些觀念和認知上的變化；所以有時候沒必要討論方法論的優劣，因為誰對誰錯不壹定是真的；
環境變了，它面臨的問題也會變；時代要求，新方法必然有更多的解釋力，但也要正視舊方法經過長期改造後對集體各方面的適應性。很多時候，為了塑造真正變革的潮流，往往需要在形式上徹底否定舊勢力。這時候就更需要思考如何用老辦法傳承價值了。)
在傳統的管理方法中，協作系統依賴於“過程&；機制、實踐和組織結構”；比如上面說的大規模創新，通常是通過設立創新機制來固化“優秀實踐”來完成的；這兩年銀行業重新開始建立的“部落制”，就是通過組織架構設計來保證合作制。
在數字化程度高的領域，依靠數字化工具鏈承載協作系統，可以大大提高集體效率；例如，軟件R&D團隊越大，就越需要“Devops工具鏈”的幫助。
兩種方法本質上沒有區別，但由於成本/調整難度的不同，“數字化”手段在企業管理中具有更高的靈活性。
如上所述，當所面臨的問題發生變化時，合作系統中不可避免地會發生摩擦，因此需要調整合作模式。
傳統企業更多的慣性方式是增加/調整流程，因為“流程管理”已經是保證集體協作的重要能力。
問題是，首先，每壹次工藝的改變，無論是時間還是人力都是極大的消耗，成本高，自然頻率下降。
其次，當協作系統落地後，解決很多協作沖突並不需要復雜的流程設計，而是需要高頻、細致的優化。過於復雜的流程設計增加了落地的難度和企業的管理成本。
這些問題是“數字工具”可以更有效發揮作用的方向。通過不斷優化工具，而不是增加額外的流程，可以更頻繁、更高效地解決問題。
例如，我的壹個客戶，團隊正在調整和管理開發過程中每個環節的進度。流程需要產品經理、開發經理、測試經理等角色寫壹份月報，然後項目經理會把幾份周報的內容整合起來。
每個團隊需要提供不同的數據。在這樣壹個小場景中，設計了幾套流程和模板來匹配不同的需求。
系統改造後，這些流程需求壹下子就被釋放了，因為這些協作的沖突本質上源於各個角色對無效工作量增加的反彈。正確的管理手段不是繼續劃分團隊，明確誰該完成工作，而是直接提供協同服務。
用“數字工具”承載協作系統，代表了管理方式的壹種本質進化:以“服務”減少角色間的協作摩擦，而不是通過流程/管理來規範每個角色的行為結果。
從這個角度去理解互聯網公司的工作模式，妳會發現，他們的產品和運營之所以強大，並不是因為組織裏的人更聰明；
而是整個組織都依賴於數字化的產品和機制，即使是輔助職能也是圍繞著相同且明確的目標工作，並能通過叠代異步地、壹點壹點地承擔來自不同角色的貢獻，最終轉化為產品效率。