參與大型軟體專案的管理常常會面臨任務分工與協同合作的問題，這些問題常常會很複雜，充滿了許多不確定的因素。因此，有關於「如何分工與合作才能讓專案的進行更順利」的這類議題，對於專案管理者而言，就是非常重要的課題。
最近，我從同事的 MSN 的暱稱中看到一段文字：「合作分工與分工合作，那一個比較好？」。我覺得很好奇，於是在 MSN 上問他認為這兩者有何不同。他提道：
這兩者有很大的不同喲，分工合作是分工後再合作，合作分工是合作後再分工。分工後再合作會有個大問題，就是分工後的每一個單位，沒有整合的觀念。而合作後分工則是則是先有完整的構架，再分單位，分別執行。
同事舉了一個我倆都參與過的專案，說明分工合作的容易發生的缺失，他認為分工前要先確認整體結構清楚，才能開始分工，彼此單位間介面才會清楚，不會缺東漏西，再來疊床架屋。因此，他認為合作分工比較好，最好團隊成員能夠在一開始先一起工作再決定如何分工。
同人覺得同事談的是很有趣的整合議題，同事則認為分工合作與合作分工是有意思的中文造字。不過，我進一步思考到合作分工在實際操作上有可能會遇到一些限制，於是我探詢同事的看法，提出了一個問題：
那有沒有需要先分工才能合作的情況呢？
同事提到分工合作或合作分工是一種工作的方式，他認為所有事都是可以在這兩種方式中擇一處理。顯然他誤會了我想要表達的意思了，我向他解釋，提出這個問題並非要質疑他的看法，而是對他的觀點感到好奇，假設合作分工是比較好的做法，那對於各種不同專案的複雜問題，合作分工有沒有可能會遇到要先分工才有辦法合作的情形，如果有，那要怎麼處理呢？這才是我真正想要探索的問題。
朋友後來跑去開會，而我們的對話也沒有繼續進行。我其實很認同任務在分工前要先對問題有全面而整體的了解，並發展出流程或方法的架構。因為在未了解問題就開始進行分工，表面上儘早動工，雖然看起來有助於專案的工作績效，但缺少事先對整合考量的規劃，卻很容易在後續的整合過程中發生問題，例如各單位彼此的介面常常因為沒有事先溝通清楚，因而導致專案整體產出無法有效整合。
因此，在理想情況下，專案團隊事先針對整合的議題詳加規劃是合理的，把任務分工的各單位之間的介面定義清楚，並針對問題發展出合適的流程與方法。這樣就可以讓一切都能朝向專案目標，並依計劃按各單位的職掌層層負責，分別執行，因而發揮團隊整合綜效。
但對於複雜性及困難度高的專案開發，這樣的想法，有時卻無法真正貫徹進行。其最主要的原因是面對專案時程與成本等限制，不大可能有足夠的時間來確認出清楚的架構，而且面對專案的情勢常常改變，要等到一切都確定無誤再開始分工執行任務，其實是不切實際的。
所以在實務上，常常只能先針對明確及重要的問題先發展出簡單而大致可用的架構，先依此架構來做分工，然後再過程中視資訊的精細度逐步改善及修正整體架構。如此一來，往往會需要先簡單地分工再合作，然後再依合作的成果來修正下次分工的架構。
換言之，分工合作與合作分工常常是需要交互運用的，這是因為專案的現實而做的調整。所以對同事認為工作方式不是合作分工就是分工合作的說法，我認為不全然是這樣，對於不確定因素大的專案，其實這兩者的界限會是模糊的。
此外，堅持依切確而清楚的架構去做任務分工，也很容易會碰到目標與過程混淆的風險。在合作分工的情形下，是假設其架構是固定而不會輕易改變的，因此各單位只要專注在自己的任務上就可以了，不用去理會架構是否合適的問題。然而，一旦專案情勢改變，如果沒有人注意到架構已經不適用了，就很容易發生為專案的努力無法連接到專案目標，因為大家常常只會關心到行動本身，而忘了去審視行動背後的假設與信念。
總之，合作分工講求的是穩定，而分工合作講求的是彈性，專案的任務分工與協同合作往往是求取這兩者的平衡點。當我們考量到彈性時，不要忽略了過度的差異性會破壞整體合作的一致性，另一方面，當我們考量到穩定時，也必須質疑專案行動與目標背後的假設與信念。因此，合作分工與分工合作，到底那一個比較好，這其實不是可以用簡單的選擇就可以得到答案的吧。
Powered by ScribeFire.
