jim yeh on 二月 12th, 2007

喲哪桑學長在〈顧客永遠是對的.所以我是對的!?〉中提到了軟體文化的獨裁政體的恐怖-恐怖的不是獨裁者的不夠英明,而是沒有人知道獨裁者不夠英明

這段話剛好讓我想到我之前寫過的〈容忍異端的文化〉,在組織中,如果有獨裁者存在,他自然不能允許別人有和他不同的意見,一旦發生,就會想盡辦法打壓對方。然而,獨裁者不會承認他是獨裁者,他會用一些冠冕堂皇的理由來包裝他的打壓理由,正如喲哪桑學長所言,那個產品經理以客戶的代言人自居,因此他可以順理成章的取得正當性,而這種正當性可以讓他為所欲為。

依據弗洛姆理論,在民主社會中,人們有逃避自由的傾向,因為他們對要為自己行為負責任會感到焦慮,於是甘願把主導權交出去,重新去依賴及屈從他人。而逃避自由分為三種行為機制來表現-集權主義反社會行為及自動從眾

所以對一個以軟體開發為主要任務的專案團隊而言,一個沒有辦法接納團隊成員有不一樣想法的人,就會形成一個無法容忍異端的文化,而在這個文化之下,主導者建立集權主義,「保護」他的子民,而他的子民只要能放棄自我的理想自動從眾,就可以在這集權中心好好地安身立命,然而對於領導中心不滿的人,則會藉由反社會行為來表達不滿,甚至極端者會有不乏毁滅性的行為。不管是那一種角色,其出發點都是在藉由依賴、屈從他人來抒解無助的感受,但把心理的焦慮壓抑下來,並卻沒有真的解決問題呀!不能容忍異端的組織是很難會有創新發生的。

專案團隊要完成專案目標,需要的是互賴而不是依賴。這裡的「互賴」一詞,出自於柯維的《與成功有約》,柯維將成長分為三個層次,分別為依賴、獨立、互賴,他認為唯有先成為獨立的人,才能達到互賴的境界,互賴最重要的基礎是互信,其次則是要有自知之明,能夠清楚的了解自己的優缺點,發掘並欣賞同伴的優點,才有辦法維持這種關係。因此,當產品經理要求工程師做出他所認的為客戶需求時,是以依賴對方為出發點,因為雙方並沒有建立互信的基礎,就不會有良性的溝通,出了事情只會相互怪罪對方,這樣的習慣一旦成形,大家缺乏自我反省的能力,更不會有自知之明的。

針對喲哪桑學長的觀點:「軟體開發是不是也能去掉中間人,讓開發人員與顧客、用戶之間有著不同以往的關係。兩方不是互相仇視,顧客能獲得對他們有價值的軟體,而開發人員也能因為自己的作品而獲得應有的榮譽。」,我認同應該讓開發人員與顧客、用戶之間有著不同的關係,然而我卻懷疑「去中間化」真的能解決問題。節省了中間人的溝通障礙,但卻會造成開發過程的機會成本的損失,別忘了團隊綜效的產生是要有效整合不同角色,而不是著重個別突出的表現;而且開發人員和顧客溝通通常比跟公司內部的其它需求提供者溝通還困難,因為不同組織,彼此的目標、想法及價值觀也會有很大的差異,更不用說開發人員與使用者身處不同世界的因素了。

所以我認為,問題出在溝通就應該加強溝通非簡化溝通。喲哪桑學長所說的從軟體文化的改變與典範的轉移雖然是重點,但在這之前,或許可以思考如何塑造整個組織的溝通與化解對立的文化,才能促使開發過程演進的良性循環,把著眼點從期待英雄主義式的「你應該」轉移到以團隊合作的著眼點的「我們必須」時,我們會看到團隊的共同問題並且用詞會相互尊重,沒有受到攻擊的情緒反應就不會說「這件事,我絕對是對的,你應該要照辦!」,針對那個產品經理,或許我會說「我不認為您是錯的,可是在開發過程中遇到問題,這個問題我們必須要解決,我們知道客戶的需求您最清楚,所以我們是不是可以來一起討論?」。有效地溝通,就不需要獨裁者,善於溝通的領導者懂得這個道理,forcing 其實是最下下策的衝突解決對策呀!



     

8 Responses to “建立互賴的軟體開發團隊”

  1. Jonathan 說道:

    謝謝你又一次評論我的文章, 這篇文章其實也是我滿喜歡的一篇, 至少比談高鐵或CMMI喜歡多了.

    你的引用, 讓我想到, 該在過年時把ithome的文章搬家了. 晚一點再寫比較完整的回應, 要先去開會了!

  2. Kage 說道:

    請問此篇文章是否可以引用?

  3. jim yeh 說道:

    引用沒問題,本網誌採用CC條款授權,請按照相關規定來引用本網誌文章。

  4. [...] 這件事也讓我想到,前幾天有網友問到我的文章是否可以引用,我回應說我的網誌是採用 CC 授權條款,所以引用必須按照其規定來為之,我也好奇在網路上有沒有人引用該篇文章,於是 Google 一下,沒想到,結果竟令我大吃一驚! [...]

  5. [...] 當甲乙雙方的利害關係是不相容的,那麼就會有一方會想辦法增加資訊不對稱的現象,而另一方則想辦法減少資訊不對稱的現象,請參看下面的系統思考圖。由圖中可以發現,資訊不對稱的現象不可能會被消除,而且我們更可以推想得知,雙方鬥法的結果,引發衝突是必然的結果,差別只在於是否浮上枱面。 因此,建立互賴的軟體開發團隊,與甲方資訊部門維持良好合作關係,雙贏思維是必要的。換句話說,對於利益不相容的現象,雙方開誠布公,彼此尊重並建立共同目標,才是問題解決之道。然而,對喲哪桑說的「階級制度」,我們該如何自處呢?其實,有沒有發現階級制度的迷思在於我們被巧妙的壞人故事所誤導,除了主導我們的故事外,更重要的是面對衝突,增加我們的問題解決能力。 [...]

  6. [...] 後來,我想到一句話:「羅馬不是一天造成的」,可以用來描寫我在發展軟體架構上的感想;不過,最近考古學家發現,羅馬很有可能是一天造成的,我想那麼高的工作效率,除了帝王專制的力量之外,古羅馬人大概掌握了我們所不知道的關鍵能力。然而,開發軟體與建造城市終究不一樣,在軟體設計的領域上,獨裁政體會阻礙創新思考,掌握關鍵的技能也是無法速成的,因此,成熟的架構其實也不是一蹴可幾的呀。 [...]

  7. [...] 筆者常看到許多具有優秀人才的團隊,常常無法發揮整體效能,其主要的原因多半是團隊缺乏創新的文化。尤其位於組織高階的管理者或自視甚高的顧問經常以為他們所主導的流程有必然成功的原因,無法容忍別人有不一樣的意見,於是破壞了團隊的創新文化與創意思考。 [...]

  8. [...] 管理人員常常用兩種說法來否認技術人員提供對問題的回饋,第一種說法是「它和技術無關」(It’s not about the technology)、另一種說法則是「我是客戶的代言人,客戶永遠是對的,所以我一定是對的」。但這些說法的最主要的迷思是解決問題的複雜性需要團隊具備「多樣性」的特性,而非刻意降低多樣性。因此只從業務需求的角度不見得可以看到解決問題的關鍵本質,反而從技術的另類思考可以讓人發現從業務觀點看不到的更為有用的新概念。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">