MBTI在軟體開發團隊中的應用

2021-06-12 13:46:52 字數 3763 閱讀 4015

人絕不是一種資源。一方面我們不可能因人設崗,另一方面也不能忽略人性的差異。面對問題時,不要總是單純地從人的態度或品德上查詢問題,而是要反思人事安排和流程建設上的不足。奢望乙個人改掉他的缺點,還不足充分發揮他的優點。

mbti將人區分為16類人格特質,我無法斷言是否真得能表達出人的真實一面,畢竟只是統計性的結果。我的思考並不在於它歸類的結果,而在於它的歸類方法。

在團隊合作中,各種各樣的情緒、喜好、偏見一直在影響著我們對於人和事的判斷。我們強調第一印象的重要性,正是因為一旦被貼上標籤,就很難再被甩掉。

在軟體開發團隊中不同的人在不同的活動中會有不同的表現,這一切都是非常自然的。舉個例子,乙個人在維護團隊做得很棒的工程師,被轉到專案團隊後績效一落千丈,公司和個人都在承受巨大的損失。也有人解bug總是引入新問題,顯得**質量低下,但卻能在技術研究上有所突破。

人絕不是一種資源。一方面我們不可能因人設崗,另一方面也不能忽略人性的差異。從人性本善的角度出發,如何理性地觀察和對待我們周圍的人,以求揚長避短?mbti在這方面可以提供很好的借鑑。mbti強調奢望乙個人改掉他的缺點,還不足充分發揮他的優點。雖然我們從小的教育和環境的塑造讓我們趨於選擇被普遍認可的行事方式,這需要我們要有更多的耐心理性的對待其中的不確定性,甚至可能矛盾的表現。

2023年,瑞士精神分析學家榮格(弗洛伊德的學生),第一次提出人格分類的概念。他認為感知和判斷是大腦的兩大基本功能。不同的人,感知傾向不同——有些人更側重直覺,有些更側重實感。同樣,不同的人判斷傾向也不同——有些更傾向理性分析得出結論,有些更側重情感考量,更為感性。同時,這兩大基本功能又受到精力**不同(內向或外向)的影響。近代美國心理學家katherinecook briggs 提出大腦的兩大基本功能還受到生活方式傾向的影響:計畫型和散漫型。

*來自www.apesk.com

根據李濤老師的《專案管理》中提供的mbti的人格維度:

mbti模型的人格維度

人與世界是如何相互影響的

外傾(extrovert)

內傾(introvert)

我們關注的資訊型別

感覺(sensing)

直覺(intuition)

我們是如何做決定的

思考(thinking)

情感(feeling)

我們傾向的生活方式

判斷(judgement)

認知(perception)

我根據自己的學習和理解,總結了各個維度的要點和偏好如下:

它們間組合後的特徵可以檢視一些專業全面的介紹。李濤老師在《專案管理》中特別研究了對於工作影響較大的兩個維度(sn&jp)做了剖析。我在這裡則選擇了除外頃或內傾外的三個維度來分析。如前面所說,我不準備談也沒有能力談出人格組合的特性,而是關注在三個維度中不同傾向在軟體團隊工作中的影響。單獨看乙個維度上的傾向來了解自己和別人是困難的,因為它們總是在相互作用下會產生不同的結果和表現。

通過上面列表對四個維度的介紹,可以歸納出不同維度中不同傾向的以下表現:

感覺(sensing)

關注自己可感知可觀察的細節、喜歡使用和琢磨已知的技能。偏向線性思維,有時很較真,總是被一些不重要的細節牽著走。

直覺(intuition)

關注事物的整體和發展變化趨勢,重視想象力和獨創力,喜歡學習新技能,但容易厭倦。思維活躍,太跳躍有時會讓表現出的效率偏低。

思考(thinking)

重視事物之間的邏輯關係,喜歡通過客觀分析作決定評價。理智、公正。圓通比坦率更重要。在客觀分析後做出決定。有時會表現出古板,缺少衝勁。

情感(feeling)

注重自己及對別人的情感影響,將價值觀作為判定標準,圓通和坦率同樣重要。表達意見時會有保留,並且有時會表現出情緒化,有時則顯得有些謹小慎微。

判斷(judgement)

喜歡做計畫和決定,願意進行管理和控制,希望生活井然有序。重視結果(完成任務),按部就班、有條理、尊重時間期限、喜歡做決定。

認知(perception)

靈活、試圖去理解、適應環境、傾向於留有餘地,喜歡寬鬆自由的生活方式。重視過程、隨資訊的變化不斷調整目標,喜歡有多種選擇,愛做有突破性的事。 有時會表現出執行不到位,不合規矩。

*部分參考了www.apesk.com提供的報告。

有趣的是,同乙個維度的傾向只是表達出行為特徵,基於此仍然會有不同的結果。比如f,同時在關注情感影響,有些人可能會十分情緒化,積極表達自己的看法,有些則趨於保留自己的看法而遷就別人的感受。但可以確定的是f一定是感情豐富且細膩的人。

關於團隊構成,已經有很多見解,比較著名的是外科手術團隊。有些說團隊純粹由同質化且同水準的人來構成的想法,早已被否定了(參考

.  本來有另乙個更接近軟體行業也更權威的文章,可惜忘記了)。從人事管理的角度上也是有梯隊建設、文化建設來確保團隊的健康發展。其實無論哪種團隊形式,都要追求互補和共贏。即使對於軟體開發團隊(沒有包含美工等),也不是純粹以技術來組織團隊。就好比再好的鑽石也要加個箍才能戴在手上。

類似從因崗設人

的角度出發,我們在談論團隊構成時,一定要知道團隊要做什麼,涉及到多少工作期望。我用工作期望或者績效表現,而不是工作專案,是因為不同的人做不同的事得到結果可能會不一樣。如果你清楚了工作上的期望,就會容易找到那個會做對的人,或者找到幫助他去做對的方法或流程。比如關注開發流程是乙個期望,有些公司對工程師在流程上要求很嚴,有些公司則因為處在初創階段,並不太在意是否遵從開發流程(可能根本還沒有流程定義)。

以下是我概括的軟體開發團隊中會涉及的工作期望(不是工作專案):

關注和遵循開發流程

注重和改進工作方法

高質量的**

高質量的設計

新專案或新技術研究開發

**維護

注重且增進團隊和諧的人際關係

組織與協調

分享與討論

自我驅動

結果導向

興趣/成就導向

新人培訓

分析過mbti的各個維度上的思維差異,再結合在團隊工作中的表現所需要的特質,就可以大致幫我們找到合適的人或者為人找到合適的崗。以下分析只代表有明顯傾向的情況之下,對於一些已經受過訓練且有流程保障的情況下,並不一定適用。比如對s和n,就可以用查核表(check list)或者思維導圖的形式加以平衡。這個不在本文的研究範圍內。

比如,如果對開發流程要求很高,比如在一些外包專案和一些特定行業軟體專案中,有嚴格的流程來保證軟體質量。顯然s和j就是比較適合了。因為s注重細節,j講究秩序。如果換作p,一定做不了多久,他無法忍受一板一眼的做事方式和反覆的review流程。要麼嘗試改變流程,要麼就是離開。同樣是s,又會因為在面對問題時不斷被一些細節干擾,會過於執著於自己的經驗和判斷,不一定會帶來好的設計,在面對新的問題時就會引入一些風險。

n和p則因為思維的活躍,可能會考慮到不同的解決方案,常常會在設計或者疑難問題上有所突破,但這不表示他一定會寫出高質量的**。特別是寫一些很平常的**時反而表現不如s和t。

再舉乙個組合的例子。如果s與t相結合,表示在觀察著重於一切實際存在的東西,在決策時又會經過理性的判斷。十足的嚴謹作風,如果是維護質量要求高(如對負作用[side effect]的零容忍)的商業專案自然十分合適。

最後是我結合以往的經驗,為各個不同的表現(對應於期望)做個適配,權做個初始值,日後逐步完善。

人格或許是穩定的,但表現卻可能不同。經過人為的訓練或者有對應的流程建設,是完全可以讓人的優勢充分發揮出來的。前提是我們應當了解到人的差異。面對問題時,不要總是單純地從人的態度或品德上查詢問題,而是要反思人事安排和流程建設上的不足。借助mbti,或許是乙個很好的起點。

軟體開發團隊中的角色

軟體開發團隊中的角色 2007 05 26 23 27 乙個nba球隊場上球員的組成與軟體團隊有相通之處,且作一笑談,不足為證 1號位,控球後衛 pg 他是球場上拿球機會最多 掌握比賽 組織進攻的人,不僅負責把球從後場安全地帶到前場,再把球傳給隊友,給隊友創造得分的機會,助攻是他們的首要工作。控球後...

設計模式 在軟體開發中的應用

論設計模式在軟體開發中的應用 在解決這個論題之前,我們首先要了解設計模式的概念,及其基本的分類。設計模式 這四個字,相信大家在很多地方都會看到,什麼是設計模式呢?乙個設計模式提供一種提煉子系統或軟體系統中的元件的,或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的元件中重複出現的結構,...

設計模式在軟體開發中的應用

首先了解設計模式的概念,及其基本的分類。什麼是設計模式呢?乙個設計模式提供一種提煉子系統或軟體系統中的元件的,或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的元件中重複出現的結構,這種結構解決在一定的背景中的具有一般性的設計問題。設計模式常常劃分成不同的種類,常見的種類有 color...