最近聽到兩件發生在我以前所帶領 PG 團隊的兩件事，讓我想分享軟體開發團隊的心理型賦權。
第一件事情是某位 SA 藉著系統部署之便，常會私自更改 PG 寫好的程式，讓 PG 深感困擾。當 PG 向這位 SA 抱怨時，SA 表示他有能力修改程式碼，但這並不是技術問題，而是牽涉到權責的問題。
也就是當 SA 修改程式而導致系統功能失常時，修正程式缺陷的責任不會落在修改程式的 SA，而是不知道程式被人改掉的 PG。然而，雖然有 PG 向 SA 反映這個問題，但它並沒有真的被重視，而 PG 也不想大動干戈去解決這個問題。
第二件事情是關於共用架構的實作議題，那個架構是同人設計，並在我離開專案時交接給另一位 SA。最近他向我表示和 PG 對架構元件的實作有認知上的分歧，他認為 PG 的想法太堅持，希望由我親自跟 PG 確認正確的實作細節。
目前他已經自己把元件改成某些功能看起來可以實際正常運作，其他 SA 也認為這樣改沒問題，但 PG 以設計不直覺而和 SA 有觀念衝突而僵持不下。同人認為他們爭論的問題根本不是重點，討論的不是設計精神而是堅持問題表相，我提醒 SA 沒有必要管那麼瑣碎的實作細節，建議他尊重 PG 在程式實作上的裁量權。
從這兩件事看待事件背後的意義，同人從領導團隊的五大障礙－也就是喪失信賴、害怕衝突、缺乏承諾、規避責任、忽視成果－等現象思考到軟體開發團隊心理型賦權。在同人先前寫的文章曾經分享過張文隆在《賦權》提到的心理型賦權的觀點：
組織賦權要成功需要外在和內在條件的支持，也就是結構型賦權和心理型賦權。結構型賦權包含 ARIA 四大要素，它讓被賦權者可以順利得到需要的權柄，也就是當責、資源、資訊、權柄。心理型賦權包含 MICS 四大要素，它是被賦權者由內而外產生權力的根源，它也就是意義、影響力、能力、自決。
簡單來說，結構性賦權就是需要讓被賦權者負給當責，並且分派給他足夠的組織資源、以及信任他而提供重要的資訊，來協助他了解狀況並讓他感到受到重視，當然還需要組織授與足夠的權柄來把事情做對與做好。心理型賦權則是被賦權者對工作角色希求，和該角色在信念、價值觀、行為之間有足夠的契合度，而且對自己可以影響組織決策、工作流程，或作業成果有信心；此外，賦權者需要對自己的能耐有自信，而且擁有啟動與調整自己行動與工作流程的自主感。
以張文隆在《賦權》這本書所提到的比喻來說，賦權是賦予團隊力量的一股能量流動，但這股能量為何會停滯而不再流動，以致於團隊因官僚特性顯得僵化，使創意枯竭與乾涸而喪失解決問題的洞見？同人觀察這正是團隊之間喪失信賴，不能信任彼此的合作關係，而只相信英雄主義。
主導能力強的人會以為自己有能力解決問題，就會傾向以自己的能力來解決問題，就沒辦法讓其他人的意見充分表達與溝通，讓缺乏主導能力的人等待別人告訴他要做什麼。
因為團隊成員之間喪失信賴，擔心表達太多意見會受到傷害而害怕衝突。於是成員工作不再浪費時間和精力去思考與溝通，而是聽從主導能力強的人之指示。如此工作沒有依照自己的想法和專業去做，完全只是聽命辦事，自然缺乏承諾來做對事情、及把事情做好。這樣工作的成效不彰也可以很容易規避責任，不在意整體團隊成果而是只重視個人的表現，於是助長英雄主義的盛行而忽視成果。
依同人過去領導這個 PG 團隊的經驗來說，我認為要提昇團隊績效最重要的一件事，是要讓 PG 們感知到工作的歸屬感。也就是工作是屬於他們的：由他們賦予意義、讓他們展現影響力、表現能耐、以及自己作決定來把事情做好。我會讓他們知道自己有能力做好工作，在架構上我儘量讓實作的 PG 參與設計方向的討論，我尊重 PG 的想法，但對該堅持的設計考量原則不會退縮，我不怕衝突，就算針鋒相對也在所不惜。
但在實作上我完全尊重 PG 實作的決定，只要能符合需求和程式開發慣例及規範，我不在乎 PG 是不是用我認為理想方式去實作程式，因為我相信 PG 會比我更知道如何在實務上面對現實，有時候我們期待的理想，只是符合我們的情感需要，對專案不見得會有正面的助益。
以上的經驗讓我體會到讓成員負起工作的當責的重要。當責者會為了把事情做好提出建設性的意見，當團隊各種不同角色為了把事情做好而提出的意見可以充分溝通交流之後，多樣性就會演化出智慧而使團隊更加不凡。成員在過程中提昇能力和自信把事情處理好，無形之中增進團隊整體效能，何須讓人有看不下去而插手介入技術的機會？依我看，讓人插手介入技術的情況會發生，代表團隊問題並不是出在技術，而是團隊的領導出了問題呀。
