合作分工與分工合作

參與大型軟體專案的管理常常會面臨任務分工協同合作的問題,這些問題常常會很複雜,充滿了許多不確定的因素。因此,有關於「如何分工與合作才能讓專案的進行更順利」的這類議題,對於專案管理者而言,就是非常重要的課題。

最近,我從同事的 MSN 的暱稱中看到一段文字:「合作分工與分工合作,那一個比較好?」。我覺得很好奇,於是在 MSN 上問他認為這兩者有何不同。他提道:

這兩者有很大的不同喲,分工合作是分工後再合作,合作分工是合作後再分工。分工後再合作會有個大問題,就是分工後的每一個單位,沒有整合的觀念。而合作後分工則是則是先有完整的構架,再分單位,分別執行。

同事舉了一個我倆都參與過的專案,說明分工合作的容易發生的缺失,他認為分工前要先確認整體結構清楚,才能開始分工,彼此單位間介面才會清楚,不會缺東漏西,再來疊床架屋。因此,他認為合作分工比較好,最好團隊成員能夠在一開始先一起工作再決定如何分工。

同人覺得同事談的是很有趣的整合議題,同事則認為分工合作與合作分工是有意思的中文造字。不過,我進一步思考到合作分工在實際操作上有可能會遇到一些限制,於是我探詢同事的看法,提出了一個問題:

那有沒有需要先分工才能合作的情況呢?

同事提到分工合作或合作分工是一種工作的方式,他認為所有事都是可以在這兩種方式中擇一處理。顯然他誤會了我想要表達的意思了,我向他解釋,提出這個問題並非要質疑他的看法,而是對他的觀點感到好奇,假設合作分工是比較好的做法,那對於各種不同專案的複雜問題,合作分工有沒有可能會遇到要先分工才有辦法合作的情形,如果有,那要怎麼處理呢?這才是我真正想要探索的問題。

朋友後來跑去開會,而我們的對話也沒有繼續進行。我其實很認同任務在分工前要先對問題有全面而整體的了解,並發展出流程或方法的架構。因為在未了解問題就開始進行分工,表面上儘早動工,雖然看起來有助於專案的工作績效,但缺少事先對整合考量的規劃,卻很容易在後續的整合過程中發生問題,例如各單位彼此的介面常常因為沒有事先溝通清楚,因而導致專案整體產出無法有效整合。

因此,在理想情況下,專案團隊事先針對整合的議題詳加規劃是合理的,把任務分工的各單位之間的介面定義清楚,並針對問題發展出合適的流程與方法。這樣就可以讓一切都能朝向專案目標,並依計劃按各單位的職掌層層負責,分別執行,因而發揮團隊整合綜效。

但對於複雜性及困難度高的專案開發,這樣的想法,有時卻無法真正貫徹進行。其最主要的原因是面對專案時程與成本等限制,不大可能有足夠的時間來確認出清楚的架構,而且面對專案的情勢常常改變,要等到一切都確定無誤再開始分工執行任務,其實是不切實際的。

所以在實務上,常常只能先針對明確及重要的問題先發展出簡單而大致可用的架構,先依此架構來做分工,然後再過程中視資訊的精細度逐步改善及修正整體架構。如此一來,往往會需要先簡單地分工再合作,然後再依合作的成果來修正下次分工的架構。

換言之,分工合作與合作分工常常是需要交互運用的,這是因為專案的現實而做的調整。所以對同事認為工作方式不是合作分工就是分工合作的說法,我認為不全然是這樣,對於不確定因素大的專案,其實這兩者的界限會是模糊的。

此外,堅持依切確而清楚的架構去做任務分工,也很容易會碰到目標與過程混淆的風險。在合作分工的情形下,是假設其架構是固定而不會輕易改變的,因此各單位只要專注在自己的任務上就可以了,不用去理會架構是否合適的問題。然而,一旦專案情勢改變,如果沒有人注意到架構已經不適用了,就很容易發生為專案的努力無法連接到專案目標,因為大家常常只會關心到行動本身,而忘了去審視行動背後的假設與信念。

總之,合作分工講求的是穩定,而分工合作講求的是彈性,專案的任務分工與協同合作往往是求取這兩者的平衡點。當我們考量到彈性時,不要忽略了過度的差異性會破壞整體合作的一致性,另一方面,當我們考量到穩定時,也必須質疑專案行動與目標背後的假設與信念。因此,合作分工與分工合作,到底那一個比較好,這其實不是可以用簡單的選擇就可以得到答案的吧。

Powered by ScribeFire.

Please follow and like us:
分類: 專案團隊, 專案規劃, 溝通, 生活感觸, 知識管理, 開發流程。這篇內容的永久連結

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。