協作=各司其職+各盡其能

相信很多人看過《奪寶奇兵》三部曲，估計也有不少人看過它的花絮。花絮的片長比正片還要長，第一次我記得看了很長時間纔看完。花絮採用記錄的方式詳細描述了三部曲的製作過程，涵蓋了視覺效果，影響效果，特技製作等等多個方面。
製作花絮花了很多時間採訪各個方面的頭頭們，描述了他們所承擔的職責，以及在製作過程中所遇到的困難，克服困難所採用的手段。當然也少不了斯皮爾伯格對製作的詳細描繪。在我看來，這是一部團隊協作的Live Tutorial。我把他推薦給了很多朋友，建議PM或是Team Leader好好看看。
很多時候我都會脫離或者是逃離IT領域去找辦法解決我所遇到的問題。這些問題多數集中在人的認識上，更確切的說是分歧上。誇張地說，在這個領域沒有哪一種說法是絕對錯誤的，似乎是完全對立的兩面能夠共存。電影中的英雄快刀斬亂麻的解決煩惱異常的問題永遠只能出現在電影中。而我採用得最多的方法都是折中。這種折中並不是充當和事佬，在爭論雙方說都退一步絕對是工作失職。
在一個項目（中等規模，成員14人）剛開始的時候我就遇到了一個難題：項目組成員對於採用XP還是RUP爭論不休。那個時候我還不太瞭解XP，相對來說RUP瞭解得多一點。多數成員都有至少兩年以上的經驗，雙方各執一詞，互不相讓。我仔細觀察了之後發現堅持RUP的都在以前的項目中有應用經驗，而堅持XP的都沒有Real World經驗，只是他們有過類似於Hello World的瞭解，但似乎他們熱情更高一些。如何說服大家並取得一致對我來說簡直太難了。我後來想了一個非常折中的辦法--三問法。
由於對RUP瞭解多一些，我傾向於RUP，但沒有表露。召集大家開會時，討論了這樣三個問題：
1，採用軟件過程是爲了什麼？----增進交流促進協作
2，XP和RUP各自的優劣。----前者強調生產力，後者強調連續性
3，對於我們的適用性。----不管本身對或錯，我們需要對我們有用的
討論之後意見就比較一致，需要合適的文檔，採用RUP，但要改進爲適合我們的方法。相對來說取得了不錯的成效，到項目結束時我總結出了所謂的“三問法”。從這以後，考慮問題的時候我都會問上三個問題，被戲稱爲三條。
選擇了軟件過程，其實就基本確定了參與者的職責。UP（不是RUP）在這一點上做得很好，詳細描述了參與角色的職責，強調團隊內的分工。社會的發展導致分工的必然，軟件過程也在經歷這種演進而且在不斷細化。非常直觀的角色是開發團隊中的幾類角色，包括美工，頁面編輯，程序員，質保，DBA，SA，BA等等。每一個人的職責都很明確。這就是各司其職，我是不希望程序員去做DBA的事情的（所以我採用iBatis而非Hibernate）。
俗話說“冤有頭，債有主”，團隊開發中這一點尤其重要。最怕的就是任務不明確，出了問題找不到責任人。沒有問題與問題都比較容易解決永遠是不可企及的妄想。
雖然有了很好的分工，但如果某個傢伙吊兒郎當出不了活，那也是一件令人惱火的事情。曾經一個傢伙非常開心的允諾3天改寫一段C代碼並且符合我們新的框架結果花了三個星期，幸好不是主幹類工作項。造成影響波及範圍不大，否則我的劣跡史上又要添加一筆。
很多時候，若一個工作項的時間超過3周，往後的時間內進展如何都只能聽天由命。我遇到的是這樣的，那個時候每個人手上都有一個新的工作項，非常激發他的熱情，同時也導致他想絕情地拋棄尚未完成的工作項。
每一次，我都黔驢技窮般告誡大家自己的職責必須儘自己最大努力完成，至少不要帶給自己痛苦。因爲，我的原則是，任何一個工作項都只由一個人負責，除非他離職。這多少帶有一些強制性，也不是非常科學，但這是出於無奈。後來我從開始就說要儘自己最大努力，也儘量把單項工作劃分在3周以內（好難），試圖提高大家的積極性，但好像收效不大，現在仍然很苦悶這一點。
其實，各盡所能是需要我們所有參與者自己施壓的。每個人都應該有一個奮鬥的目標，這些目標應該是自己制定自己完成的。工作上接受到的一些任務很大可能與這些目標有衝突，但工作畢竟是不可拋棄的，至少對於大多數人是這樣，最主要的就在於解決這種矛盾關係。嘿嘿，永遠要抓住主要矛盾。

路漫漫其修遠兮，吾將上下而求索。