比起個人的單打獨鬥，團隊合作可以創造更高的效益，但該如何組織高效率的團隊，却往往是令人傷透腦筋的一件事。團隊在組織中是跨越部門的功能性與職位層級的工作小組，它組合了多樣性與一致性兩種特性。團隊多樣性是來自於組織當中不同的部門或功能群組事業單位，而一致性則是基於相同組織具有相同的企業文化及共同目標。 由於這兩項特性，在團隊中是彼此對立但卻又是相輔相成的，因而容易造成管理團隊合作的困難。團隊可以發揮成員能力多樣性的優勢，產生團隊綜效而創造更高的整體效益，但另一方面，團隊的多樣性太高，將會對一致性造成衝擊，使管理者面臨到管理的困難。 團隊多樣性有助於團隊績效，但多樣性很容易使成員之間因為意見分歧，進而產生情緒反應與相互的干擾行為而發生衝突。衝突通常對團隊績效是有損害的，這在團隊發展是需要注意的問題，因此團隊領導者通常需要想辦法增加團隊的一致性，以降低成員之間一旦發生衝突的麻煩。 同人之前在文章〈技術經理的教練角色〉，就曾經提到技術經理不應該為了增加一致性而犧牲多樣性。在那篇文章同人對通達人提出的觀點，表達我的看法。他認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。 同人當時以「必要多樣性法則」來說明如果技術經理的管理彈性不足，他就只能對團隊成員處處設限，以減少團隊的多樣性來降低管理的困難。但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。因為團隊可以視做一個動態系統，這個系統的行為將會由系統最有彈性的部分來掌控。換句話說，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他控制整個系統的困難度。 從「必要多樣性法則」可以理解，如果希望利用團隊創造出更高的效益，多樣性是不可或缺的，否則團隊合作所產生的效益必然會欠缺創造力。這樣的觀念就像自然界生物與社會發展的演進一樣，存在差異性才能促成個體致力於創新與改變，進而促成整體性的發展與成長。 有趣的是，前一陣子同人在《我不要當負翁！教你如何經濟思維》這本書中也看到以經濟學的交易及合作的觀念來解釋團隊多樣性的必要性，也覺得非常有意思。 《我不要當負翁！教你如何經濟思維》提到運用「絕對優勢」和「比較優勢」都可以創造合作的效益。「絕對優勢」可以降低生產的會計成本，而「比較優勢」則是可以降低生產的機會成本。
東方人的含蓄溢於言表，為了維繫人際關係的和諧，通常並不習慣直接說出心裡面的想法，而是喜歡用迂迴轉進的言語模式來溝通，希望對方能夠揣摩自己的心意，了解在言語之外的弦外之音。 當然，如果從言語的暗示當中，聽話者可以聽懂說話者所要表達的意思，有時候可以化解一些尷尬的場面，然而如果聽話者聽不懂、甚至是誤解說話者想要表達的意思，那溝通就會非常的沒有效率。不幸地是，有莫非定律的加持，後者比前者發生的機率然還要大得多，而且容易讓人覺得被操控玩弄而感到的不自在。 溝通不應該玩猜心的遊戲，要別人猜中你的心思，這是很累人的一件事，換做是自己，可能也不見得會猜中對方的心思。有時候，當我們對別人的行為感到失望時，應該用直接的方式表達我們的在意，而不是期待對方想清楚，然後做到符合自己沒有說出來的期待。
聽到同事轉述管理階層的說法，倒是讓我覺得如果管理只要照著做，那問題可就大了。同人這篇文章寫下我對這事件的看法，不過我並不想討論管理階層所制定流程系統的優劣，而是想探討到底對專案管理而言，最重要的事情到底是什麼。
短期來說，高層管理者所不願承擔的壓力加諸在專業人員身上，他們總是無力反抗而必須默默承受。但長期讓專業第一線的工作人員一直承受壓力，而不懂得適時激勵來增加專業人才的士氣，總有一天將會令專案付出慘痛的代價：損失重要的專業人才。因此，對於專案管理者而言，這是值得關切的問題。
在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。
敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但文辭有略為做過一番修飾，可以用來澄清我對測試驅動開發步驟的看法。
對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
測試驅動開發的精神，不應該用一般機械論的觀點來進行工作或任務的化約，而是基於複雜理論的重要觀念；維持穩定與變化的動態平衡，不在於掌握系統核心而在於邊緣，讓變動限定在人們可以掌握的範圍內，這或許才是測試驅動開發最關鍵的精神吧！
技術經理當教練如果對公司是不好的徵兆，問題應該還是出在領導上，誠如同人過去發表過的文章所講的：強將手下無弱兵，但也不會有強將。沒有辦法訓練培養人才的教練，還是因為技術經理不諳教練之道呀！
最新迴響