일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 카프카 성능
- 머신러닝
- FCM
- 슬랙 파일업로드 제한
- 웹보안
- 스카우터
- 해킹
- 코어/컨텍스트
- firebase
- Scouter
- 슬랙 파일업로드
- 알림무시
- 이미지 푸시
- Slack Rate Limit
- Tuckman
- Spark
- kafka
- n-gram
- bag of words
- Scale Cube
- 스케일 큐브
- Core/Context
- 카프카
- Slack Limit
- Slack File Upload
- Rate Limit
- 슬랙
- 팀 발달 모델
- 파이어베이스
- 자연어처리 #konlpy #형태소분석
- Today
- Total
플랫폼 개발팀 기술 블로그
Tuckman의 팀 발달 모델 본문
지금까지 IT업계에 20년 가까이 일을 하면서, 많은 팀을 겪어 왔습니다.
역할로는 팀원에서부터 파트장, 팀장까지 다양하게 경험을 해왔으며 현재도 진행중이지요.
팀과 프로젝트를 리딩한 경험도 다양한데, 팀의 규모로는 3명에서부터 20명이 넘는 팀을 리딩해 본 경험이 있습니다.
또한 경험해 온 환경도 무지 다양한데, 여러 회사의 다양한 팀 구조와 문화를 체험했습니다.
인터넷 컨텐츠 회사에서 부터, 게임회사, 대기업 SI 등의 서로 다른 조직 문화에서 일을 해왔으며, 팀의 조직화 특성으로는 보통의 기능조직 성격의 팀에서부터 프로젝트에 특화되어 구성된 TFT(Task Force Team)까지 겪어 봤습니다.
지금까지 제가 겪어온 팀들은 제각각 다른 특성들이 있었지만, 결국 사람이 모여서 일을 하는 것입니다.
그래서 팀이 결성되고 협업하고 때론 갈등에 직면하고 목표를 달성해 나가는 근본적인 원칙과 과정은 크게 다르지 않다고 봅니다.
오래전 팀리딩을 담당하게 되면서, 프로젝트 관리와 동기부여에 관련된 다양한 이론과 지식을 찾아서 학습해 왔습니다. 그전에는 관심 없었던 다양한 경영이론과, 심리학 이론 등이 존재하더군요.
이 글에서는 그 중 하나인, Tuckmana의 팀 발달 모델을 소개하고 개인적인 경험과 접목하여 글을 정리해 볼까 합니다.
Tuckman's Team Development Model
1965년, 심리학 교수인 Bruce Tuckman은 'Developmental Sequence in Small Groups'이라는 논문을 통해 Team Development Model이라는 경영이론을 발표했습니다.
팀이 형성되고 발달해 나가는 과정을 4단계로 나눈 이 모델은, 각 단계별로 팀이 겪게 되는 특징을 잘 설명합니다.
첫 논문 발표시 4단계였던 것이 1977년에 Adjourning 단계가 추가되면서 현재는 총 5단계 모델로 알려져 있습니다.
국제적인 프로젝트관리 협회인 PMI에서 발행하는 PMBOK에서도 '인적자원관리'라는 지식영역에서 이 모델을 '프로젝트 팀 개발'이라는 항목으로 안내하고 있습니다.
팀 리더는 팀 운영과 프로젝트의 성공을 위해 이 모델을 참조할 수 있습니다. 팀이 발달하는 과정을 이해하고 각 단계별로 당면하는 팀의 상황과 각 상황별로 필요한 리더십 스타일을 이 모델의 이론에 근거하여 결정할 수 있습니다.
개인적으로도 이 모델은, 그간 제가 맡은 팀을 이해하고 문제를 해결하고 리딩 스타일을 결정하는데 많은 도움이 되었습니다.
Tuckman에 의하면 팀은 (아래 도식에서와 같이) 5단계의 과정을 거치게 됩니다. 처음에 혼돈과 불확실성으로 가득찬 상태에서 긴장과 대립, 갈등이 촉발되는 시기가 옵니다. 이후 각 단계를 거치면서 팀은 성장하고 프로젝트를 성공적으로 완수할 수 있게 됩니다. 물론 잘 운영되는 경우에 말이지요.
출처: https://www.lfhe.ac.uk/download.cfm/docid/3C6230CF-61E8-4C5E-9A0C1C81DCDEDCA2
Tuckman의 이론을 요약하여 다음과 같은 표로 정리해 봤습니다.
처음 이 모델을 봤을 때, 참으로 공감되는 내용이 많았습니다.
제가 맡은 여러 형태의 팀들 중에서 특히, SI 프로젝트를 수행할 당시의 팀이 이 모델의 이론과 매우 흡사 했습니다.
각 단계별 리더십 스타일
제가 이 글을 정리하고자 했던 동기는 바로 이 부분입니다. 팀리더가 어떻게 해야 팀을 원만하게 운영하고 프로젝트를 성공시키느냐 하는 것입니다.
팀리더는 프로젝트를 성공시키고 팀을 성장시키는데 책임이 있습니다. 그 책임을 다하기 위해서는 팀과 팀 구성원들을 정확히 이해하고 자신의 리더십 스타일을 적적히 변경할 수 있어야 합니다.
팀 리더는 Tuckman의 모델에 참고하여 자신의 리더십 스타일을 결정하거나 조정할 수 있습니다.
여기에 좋은 안내서가 있습니다.
https://kristalaace2014.wordpress.com/2014/02/26/w1_al_tuckman-analysis-assignment/comment-page-1/
위의 표는 각 단계별로 팀리더의 스타일을 안내하고 있습니다. 저도 이 표를 보면서 간과했던 부분을 다시금 깨닫는 계기가 되었습니다.
형성기(Forming)
모든것이 불명확하고 불확실한 상태입니다. 프로젝트의 목표와 과제에 대해 공감과 이해가 부족한 상태이며, 구성원들은 서로 어색하고 신뢰가 형성되지 않은 시기입니다.
'우리가 여기에 왜 모였는가?'' 를 분명히 해야 합니다.
즉 목표를 명확히 설정하고 작업 과제와 R&R을 분명히 해서 구성원들을 인지시켜야 합니다.
요약하자면 이 시기에서 팀 리더는 프로젝트의 방향 설정과 공유에 집중하고 각 구성원들의 R&R과 수행과제를 명확히 전달하는 것이 필요합니다. 지시형 리더십 스타일이 필요하다 하겠습니다.
격동기(Storming)
프로젝트의 목표와 개인의 역할을 인지하게 된 시기입니다.
이제 본격적으로 각 구성원들이 프로젝트를 위해 일을 시작하게 되는 것이지요. 그러나 이제 막 모인 사람들은 각자의 업무 스타일과 개성이 표출됩니다. 이로 인해 잦은 의견충돌과 대립이 발생하면서 긴장상태로 접어 듭니다. 말 그대로 격동기 입니다.
팀 리더로써 가장 중요한 시기입니다. 다름과 틀림을 구분할 수 있도록 해야 합니다. 구성원들의 서로 다른 업무 스타일로 갈등이 고조되지 않도록 하는 조치가 필요합니다.
팀이 일을 하는 방식에 대한 표준(기술표준, 프로세스 표준, 의사결정 방식 등)이 반드시 필요합니다. 각자의 스타일을 존중하되, 협업을 위한 표준으로 스타일을 조화시켜야 합니다.이 시기의 팀 리더는 구성원들의 개인적인 상호작용에 많은 관심을 가져야 합니다.
구성원들의 의견 불일치, 갈등을 적극적으로 중재해야 합니다. 이때 팀의 표준이 많은 도움이 됩니다.
코치형 리더십 스타일이 필요하다 하겠습니다. 특히 개인적인 관계를 촉진하는 역할이 중요합니다.
규범기(Norming)
이제부터 팀의 정체성이 서서히 형성되기 시작합니다. 팀 구성원들은 공동의 목표 달성을 위해 모였다는 것을 자각하게 됩니다. 상호 조화를 위해 노력하기 시작하고 서로를 신뢰하기 시작합니다. 이제 각 구성원들은 자신의 작업을 원만히 수행하며 원만히 협업하기 시작합니다.
이때 팀 리더는 작업 그 자체 보다는 작업과 작업간의 우선순위와 프로세스에 집중해야 합니다.
즉 프로젝트의 진행을 촉진한느 참여형 리더십 스타일로 팀을 리딩하는 것이 좋습니다.
성과기(Performing)
이제 팀은 최고의 성과를 내기 시작합니다. 서로간의 신뢰가 매우 높아진 시기입니다. 프로젝트 목표 달성을 위해 구성원 스스로가 최적의 방안을 스스로 도출해 내기도 합니다.
팀 리더는 구성원들에게 권한을 위임해도 큰 문가 없으며 오히려 권한 위임으로 인한 동기부여와 시너지가 높아지기도 합니다. 즉 위임형 리더십 스타일이 권장됩니다.
해지기(Adjourning)
프로젝트의 수행이 완료되고 팀이 해체하는 시기입니다. 보통 기능조직팀은 해체라는 것이 없지만 프로젝트에 특화된 팀은 해체하게 됩니다. 이 시기에는 특별한 리더십 스타일이 요구된다기 보다는, Lesson Learned를 통해 프로젝트를 수행하면서 겪었던 성공과 실패, 프로세스 지식 등을 정리하고 평가를 수행합니다. 이러한 경험이 쌓여 다음 프로젝트에 경험적 지식으로 활용됩니다.
'프로젝트 관리' 카테고리의 다른 글
아키텍처의 출발점 (0) | 2019.04.04 |
---|---|
Core/Context 모델 (0) | 2019.03.22 |