一個程式設計師在IBM的開發經驗 (轉)
一個程式設計師在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也會盡力為團隊的目標多做貢獻。
鼓勵和支援個人成長
支援組員的自我發展,給他們的發展提供空間,鼓勵開放的交流 。只有支援組員的發展,才能得到組員們的支援,才能提高整個團隊的能力。
在介紹了團隊的建立的階段,適應不同人的領導方式,循循善誘的指導方式和高效的小組會議後,我們應該體會到所有的技巧背後,更重要的是你的思想方式,是你對他人的信任與尊重。只有在相互信任之上,才能建立一個為了共同的目標奮力進取的團隊。
(這條文章已經被閱讀了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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 扎心!一個3年經驗的程式設計師經驗之談!程式設計師
- 程式設計師的管理經驗程式設計師
- 一個有40年編碼經驗的老外程式設計師的職業經驗程式設計師
- 三年開發程式設計師的職場經驗談程式設計師
- 10個程式設計好習慣:優秀程式設計師的經驗分享程式設計師
- 十年開發的程式設計師,總結出了這些開發經驗程式設計師
- windows程式設計師開發linux程式的頭一個月Windows程式設計師Linux
- 12年經驗老程式設計師5次轉型程式設計師
- 程式設計師面試經驗程式設計師面試
- 一個程式設計師如何轉型做產品經理呢?程式設計師
- 採訪一個 10 歲的程式設計師,他在 30 萬開發者群裡教程式設計程式設計師
- 一個 Angular 程式設計師兩年多的遠端辦公經驗分享Angular程式設計師
- 程式設計師筆記(知識)管理的一點經驗程式設計師筆記
- 一到五年Java開發經驗的程式設計師如何達到年薪40W?Java程式設計師
- 一個 1年工作經驗的 PHP 程式設計師是如何被面試官虐的?PHP程式設計師面試
- 程式設計師體驗——我在 RightCapital 的工作程式設計師API
- NPDP|程式設計師轉產品經理好轉嗎?程式設計師
- 以前的程式設計師,現在的程式設計師程式設計師
- 一個程式設計師經歷的7小時全身麻醉程式設計師
- 程式設計師,如何從開發轉型做架構師?程式設計師架構
- 小白必看——一位八年程式設計師的工作經驗程式設計師
- 程式設計師前世今生 (6年PHP 開發的經歷)程式設計師PHP
- 一個在成都7年的程式設計師2022總結程式設計師
- 有經驗的程式設計師應該如何提升自己程式設計師
- 一個老程式設計師的程式設計之路,寫給年輕的程式設計師們程式設計師
- 一個程式設計師工作經歷和成長感悟程式設計師
- 給程式設計師的幾點程式設計經驗----《編寫高質量程式碼》程式設計師
- 不會填坑的程式設計師不是一個好程式設計師!程式設計師
- PHP 程式設計師轉 Go 語言的經歷分享PHP程式設計師Go
- 2018,一個轉行程式設計師的成長 | 掘金年度徵文行程程式設計師
- 開發小程式的一些小經驗
- 【轉發】為什麼說程式設計師是一個極度勞累的工作?程式設計師
- 現在的你,是開發工程師、程式設計師還是碼農?工程師程式設計師
- 硬體程式設計師和軟體開發程式設計師相比,哪一個就業發展前景比較好呢?程式設計師就業
- 程式設計師校招筆試經驗小分享程式設計師筆試
- 大廠面試:一個四年多經驗程式設計師的BAT面經(位元組、阿里、騰訊)面試程式設計師BAT阿里
- 第一個想取代程式設計師的AI程式設計師,失敗了?程式設計師AI
- 在HR眼中,一個合格的前端程式設計師是怎樣的?前端程式設計師
- 程式設計師被高薪聘用的13個開發技能!get!程式設計師高薪