一個程式設計師在IBM的開發經驗 (轉)

worldblog發表於2007-12-04
一個程式設計師在IBM的開發經驗 (轉)[@more@]一個員在IBM的開發
 (這條文章已經被閱讀了338次)
 時間:2001年04月12日 11:11 來源:劉韌轉貼

開發組的--

團隊精神

沈宏宇

  總聽到大家在講團隊精神,那麼團隊到底是什麼?
  團隊就是一小群有互補技能,為了一個共同的目標而相互支援的人。

  對於一個團隊來說,最基本的是要有一個清楚的目標。


志同道合
  是什麼原因使大家組成一個團隊?一個目標。對於球隊來說,這個目標是進球得分,從而戰勝對方;對於專案組來說,是在限期內完成專案;對於軟體開發組來說,是保質保量推出產品。
  這樣說似乎很簡單,作為一個軟體開發組長,事實上你是否非常明瞭你的團隊的目標了?比如說,我們組的目標是:

    在2001年9月30日之前按軟體需求書完成 WPX-的開發。

在這個目標裡,有沒有考慮到軟體測試的時間?如果公司預計在十月份進行產品釋出,那麼明確的目標應該是:

    在2001年9月30日之前按軟體需求書完成 WPX-XP 所有的開發與測試。

  作為組長的你已經將這個目標諳熟於心,下一步便是讓每一個組員都明確這個目標。這樣,整個團隊的目標才能統一清晰。


團隊發展
  團隊發展大致分為形成,不滿,解析和行動(Fong,Storming,Norming, Performing)四個階段。
  在形成階段,作為組長,你不僅要讓每個組員都明確團隊目標,而且要讓他們明確自己在實現目標中的職責。

  在團隊發展的過程中,難免會遇到各種各樣的問題。這時候組員相互推卸責任,情緒消極。這就是團隊發展中必經的一個過程,不滿階段。只要在適當的時候將組員引導到積極的解決問題上,便能使團隊更有作為。

  在團隊發展的第三階段,解析階段,組員們達成共同的解決方案。團隊便進入高效的行動階段。

  團隊發展可能在這四個階段之間反覆。明確的目標,相互信任與支援最終能使團隊進入並停留在行動階段。


因才施教(Situational Leadership)
  任何時間,出於任何原因,個人影響另一個人或團體的行為便是領導。領導的一貫方式形成了領導風格。
  領導的行為有兩種:指導和支援。

  指導行為包括:告訴組員做什麼,怎麼做;定義組員的角色;定義組員間的關係;為組員建立目標;為組員作決定等等。這是一種單向的交流方式。

  支援行為包括:表揚和鼓勵組員;開啟雙向交流的渠道;增加組員的責任範圍;增加組員介入設定他們目標的程度等等。這是一種雙向的交流方式。

  在我們的團隊中,按照態度和能力大致可以分為四類人:

成熟度 技能,能力與知識 主動性與信心
R1 沒有 沒有
R2 沒有 有
R3 有 沒有
R4 有 有

  對於這四種成熟度的組員採用相應的領導方式才能最大程度地發揮組員的主觀能動性。




  如圖所示,根據指導和支援行為的多少,領導風格也可以分為四種:
領導風格 指導行為 支援行為
S1: 教導 多 少
S2: 推銷 多 多
S3: 參與 少 多
S4: 委派 少 少


  從圖中還可以看出,對於R1->R4的組員,應相對應地採用S1->S4的領導風格。

  當S剛進入公司作第一個Inte專案時,S既不熟悉, 也不熟悉script,S因此毫無信心 (R1)。組長D讓S作一些已有樣本的程式塊的編碼,並指導他閱讀書籍 (S1)。

  一個月後,S對JSP和有了大致的瞭解,加上S原有的C++和HTML的經驗,S非常有信心能做好工作(R2)。組長D看到S的進步,便將獨立的功能塊交給S去做,並花時間和S討論具體的作法,並對S的程式定時檢查 (Code Review) ,及時發現解決程式中的問題 (S2)。

  經過一段時間的共同努力,S完全掌握了Internet專案前後臺程式設計技巧,有了多個專案的經驗,並透過了UML的培訓,組長D便讓S擔任新專案的設計工作。S毫無作好設計的把握(R3),他將自己的設計想法和D討論,D肯定和支援S的想法,並鼓勵S做好設計(S3)。

  S就這樣成長為優秀的設計師,為公司承接了多個專案 (R4)。這時的S需要更多授權來開展工作 (S4)。

  在評判一個人的成熟度是R1還是R4時,針對給定的任務是很重要的。我們經常看到優秀的程式設計師被提拔為開發組長。對於這位程式設計師來說,他的程式設計水準是R4,而管理水準可能只有R1。在如何管理組員方面,你便要使用S1來對他進行指導了。

  另一原則是, 如果你不確認組員的成熟度,請先試用上一標準。例如,你不確定S是處在R2還是R3,先試用S3;如果S不能勝任,再改為S2。


循循善誘(Coaching)
  循循善誘的指導方式適用於上述的四種領導風格。指導的目標只有一個,就是將組員培養成R4,從而更好地完成工作。
  以下是循循善誘五步曲:

  
儘量讓組員來確立目標。   
發現與建議,讓組員來談問題的背景和他建議的解決方法。
因為你在這方面更有經驗,你可能會發現組員的想法沒有你的好,甚至很可笑。其實,在你解釋組員想法的不可行之處時,你也灌輸了自己的思考方式。適當地分享自己的經驗會起到很好的效果。   
和組員一起制定行動計劃。  
授權組員以完成計劃。  
定時和組員一起審查計劃的情況。
  循循善誘的指導方式的重點在於“問”而不是“答”,“聽”而不是“說”,“授權”而不是“指導”。這更多的體現了你的思想方式,而不僅僅是領導技巧。信任他人是領導的根本。

小組會議
  在小組會議上,你和你的組員們“傳遞”資訊,意見,問題,解決方案,工作計劃等等等等。如果你和你的組員們不能成功和有效地“傳遞”,團隊就沒有戰鬥力。
  在開會前,先要問自己四個問題:

  
會議的目標是什麼?
通常有五種會議:規劃會,傳達資訊會,解決問題會,決議會,建立關係會(如慶功會)。   
邀請哪些人參加?   
你怎樣知道會議是否成功?   
高效會議的基本步驟是什麼?
準時開會,回顧會議議程,控制每個議程的時間,控制討論不要走題,作會議記錄,總結結果並分派工作,準時散會
  我們通常都想避免會議過多的錯誤,但對於你的開發組來說,會議過少也會影響組內的交流。
  在小組會議上,作為組長的你主要是明確會議目標,控制議程。“聽”多於“說”才能開啟雙向交流的渠道。

  出於各種各樣的原因,有些人不願意在會議或公眾場合發言。你可以在會前提醒他,星期五將要在小組會上討論GUI設計的問題,希望能聽到他的方案或想法。


團隊精神
  真正的團隊精神從哪裡來?我們通常最欠缺的是下面兩點:
  
尊重與信任
  你是否尊重與信任每一個組員,相信他們的能力,支援他們的做法?
  你的開發組是否使用Visual Safe 層層地管理程式,以至於剛入門的小S只能看到他自己的那一小塊程式碼?
  你是否願意和組員共享你的設計和程式?
  你是否將所有的都面對走廊以便監視組員們是否在玩遊戲,看私人E?

正所謂“用人不疑,疑人不用”,如果沒有基本的尊重與信任,哪裡來的凝聚力,何謂團隊精神?

如果小S能看到其他人的程式,看到你是怎樣處理相似的問題,這是他最好的提高自己的方法。小S提高的越快,對團隊的貢獻就越大。小S如果能和你共享一個目標,不需要你的監視,小S也會盡力為團隊的目標多做貢獻。

  

鼓勵和支援個人成長
支援組員的自我發展,給他們的發展提供空間,鼓勵開放的交流 。只有支援組員的發展,才能得到組員們的支援,才能提高整個團隊的能力。


  在介紹了團隊的建立的階段,適應不同人的領導方式,循循善誘的指導方式和高效的小組會議後,我們應該體會到所有的技巧背後,更重要的是你的思想方式,是你對他人的信任與尊重。只有在相互信任之上,才能建立一個為了共同的目標奮力進取的團隊。



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-987840/,如需轉載,請註明出處,否則將追究法律責任。

相關文章