最近太陽進入同人命宮，也該繼續寫文章在網誌上發表了，不過同人最近碰到了一件事，讓我停下來正在寫作的文章，先來寫一篇分析這個事件時盤的文章。這個時盤是某個人在網路上在人後評斷是非的時盤。
「好產品不一定能賺到錢」並不是一項迷思。其實它告訴我們一項真理：人想要靠開發出好產品而賺到錢，除了需要有能力把產品做出來之外，還需要其它因素的配合；把各種可能的因素加在一起，我們通常會通稱它叫機運。
在今年過農曆年前，看到以前閱讀《溫伯格的軟體管理學（第二卷）：第一級評量》所做的筆記，引發同人想要寫一篇文章探討軟體開發團隊的官僚特性。但由於工作轉換及其它寫作計劃的原因，直到現在才有時間分享我對軟體開發團隊的官僚特性之心得。
最近讀到一篇文章〈不要盲目的 BDD / TDD，我對寫測試的看法〉，看完作者 XDite 反對不論如何都要導入 TDD 的理由，讓同人想提出我對這篇文章的看法。
要認識系統開發的複雜性，這並不是一件很容易的事。不過，忽略它會讓我們和湊熱鬧的外行人一樣，從他人系統失敗的經驗中只能看得到表相；以為這只是犯了離譜的技術或方法論的錯誤。
在公司高層這種態度和形成的公司文化氛圍之下，公司產品最後會變成「把做好的東西丟到牆的那一邊去」就不足為奇了。再加上以西方優越感產生文化的價值批判，在這種情況之下，QA 對產品品質的提昇有多少著力點呢？同事丙的離開做出了最好的回答。
比起個人的單打獨鬥，團隊合作可以創造更高的效益，但該如何組織高效率的團隊，却往往是令人傷透腦筋的一件事。團隊在組織中是跨越部門的功能性與職位層級的工作小組，它組合了多樣性與一致性兩種特性。團隊多樣性是來自於組織當中不同的部門或功能群組事業單位，而一致性則是基於相同組織具有相同的企業文化及共同目標。 由於這兩項特性，在團隊中是彼此對立但卻又是相輔相成的，因而容易造成管理團隊合作的困難。團隊可以發揮成員能力多樣性的優勢，產生團隊綜效而創造更高的整體效益，但另一方面，團隊的多樣性太高，將會對一致性造成衝擊，使管理者面臨到管理的困難。 團隊多樣性有助於團隊績效，但多樣性很容易使成員之間因為意見分歧，進而產生情緒反應與相互的干擾行為而發生衝突。衝突通常對團隊績效是有損害的，這在團隊發展是需要注意的問題，因此團隊領導者通常需要想辦法增加團隊的一致性，以降低成員之間一旦發生衝突的麻煩。 同人之前在文章〈技術經理的教練角色〉，就曾經提到技術經理不應該為了增加一致性而犧牲多樣性。在那篇文章同人對通達人提出的觀點，表達我的看法。他認為在保有多樣性的同時，也必須注意—致性。因為一致性是合作的基礎，就像足球隊隊員們都須熟練基本技巧「控球」和「傳球」，才能在實際比賽中透過一系列交互傳球得分。 同人當時以「必要多樣性法則」來說明如果技術經理的管理彈性不足，他就只能對團隊成員處處設限，以減少團隊的多樣性來降低管理的困難。但如此一來也等於抑制成員的創意，常會使得問題的解決更加困難。因為團隊可以視做一個動態系統，這個系統的行為將會由系統最有彈性的部分來掌控。換句話說，如果技術經理的彈性不足，那麼團隊的多樣性將會造成他控制整個系統的困難度。 從「必要多樣性法則」可以理解，如果希望利用團隊創造出更高的效益，多樣性是不可或缺的，否則團隊合作所產生的效益必然會欠缺創造力。這樣的觀念就像自然界生物與社會發展的演進一樣，存在差異性才能促成個體致力於創新與改變，進而促成整體性的發展與成長。 有趣的是，前一陣子同人在《我不要當負翁！教你如何經濟思維》這本書中也看到以經濟學的交易及合作的觀念來解釋團隊多樣性的必要性，也覺得非常有意思。 《我不要當負翁！教你如何經濟思維》提到運用「絕對優勢」和「比較優勢」都可以創造合作的效益。「絕對優勢」可以降低生產的會計成本，而「比較優勢」則是可以降低生產的機會成本。
聽到同事轉述管理階層的說法，倒是讓我覺得如果管理只要照著做，那問題可就大了。同人這篇文章寫下我對這事件的看法，不過我並不想討論管理階層所制定流程系統的優劣，而是想探討到底對專案管理而言，最重要的事情到底是什麼。
短期來說，高層管理者所不願承擔的壓力加諸在專業人員身上，他們總是無力反抗而必須默默承受。但長期讓專業第一線的工作人員一直承受壓力，而不懂得適時激勵來增加專業人才的士氣，總有一天將會令專案付出慘痛的代價：損失重要的專業人才。因此，對於專案管理者而言，這是值得關切的問題。
在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。
最新迴響