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





最新迴響