'프로젝트 관리'에 해당되는 글 3건

  1. 2019.04.04 아키텍처의 출발점
  2. 2019.03.22 Core/Context 모델
  3. 2019.03.08 Tuckman의 팀 발달 모델

변화경영연구소의 소장이셨던 고 구본형 선생의 유명한 책인 '익숙한 것과의 결별'에서는 다음과 같은 내용이 있다.



비전을 제대로 이해하기 위해서는 건축물을 연상하는 것이 가장 완벽한 동질성을 부여한다.

 

비전은 '미래의 설계도'라고 말하는 사람들이 많다.

그러나 나는 그 생각에 강하게 반대한다.

그것을 설계도라고 해석하는 데서부터 많은 오류가 발생한다는 것을 알고 있기 때문이다.

 

설계도는 전문가들을 위한 것이다.

보통 사람은 설계도를 보고 그 건물의 전체적 모습을 떠올릴 수 없다.

그것은 판독하기 어려운 수치와 기호일 뿐이다.

 

비전은 이해관계자 모두가 쉽게 그 모습을 머릿속에 떠올릴 수 있어야 하며,

그 모습의 아름다움 때문에 마음이 설레야 한다. 따라서 비전은 오히려 건물의 조감도와 흡사하다.

 

건물의 유려한 자태와 자재의 질감이 느껴져야 한다.

그리고 그 건물 속의 한 부분을 줌업시키면 그 속에 앞으로 자신이 거주하고 생활할 새로운 공간이 보인다.

 

이 건물이 만들어지면 이 아름다운 곳으로 이사올 것이다.

어둡고 추운 지금의 공간을 떠나 밝고 넓고 전망이 좋은 공간에서 생활하게 될 것이다. 



비전에 대해 설명하는 내용이지만, 문득 아키텍처의 출발점이 이와 같지 않을까 하는 생각이 든다.

 

IT 시스템을 위한 아키텍처의 1차적 목표 역시, 대형의 복잡한 시스템에 대한 합리적으로 이해가능한 청사진을 제공하는데 있다.

 

여기서 '이해가능한'의 대상은 시스템 구축에 참여하는 모든 이해관계자로 볼 수 있으며, 이 중 핵심 이해관계자는 바로 고객이 되므로 고객이 이해가능한 시스템의 청사진이어야 한다.

 

고객이 이해한다는 것은, 고객의 요구사항을 합리적으로 해결하는 청사진을 제공하는 것이며, 아키텍처 드라이버라는 용어로 불리우는 아키텍처 결정요인 중 비기능 요구사항에 해당하는 품질속성을 만족시키는 아키텍처가 훌륭한 아키텍처인 것이다.

 

품질속성이라는 것도 가용성/성능/보안/유지보수성과 같은 시스템적인 부분도 있지만, TimetoMarket/시스템수명/가격 등 비지니스적인 부분도 고려되어야 한다.

 

따라서 고객의 관점에서 비기능요구사항에 대한 만족스러운 청사진을 제공하는 것은 IT전문가들만 이해가능한 복잡한 설계도가 아닌 전체 조감도가 더 아키텍처에 근접한 것이 아닐까 한다.

 


다음 그림은 아파트 건축물의 조감도이다.

 

아파트는 주거공간이라는 가장 기본적인 기능적 요구사항 외에도 고객의 선택에 더욱 중요한 변수인 주변생활여건, 녹지공간, 전망, 해가 들어오는 방향, 역세권 등의 품질속성이 매우 중요한 축을 차지한다. 이런 요건은 전문 설계도 보다는 아래 그람과 같은 조감도가 더욱 많은 얘기를 해 준다.

 


물론 이해관계자 모두가 제시된 청사진을 기반으로 작업을 진행해야 하기에 설계자, 개발자, 유지보수자와 같은 IT전문가들이 아키텍처가 설계한 원칙을 준수하는데 동참시키기 위해서는 다양한 설계의 측면을 고려해야 한다. 그래서 아키텍처 뷰의 가이드로써 OMG의 4+1View, CMUSEI의 3View, 지멘스의 4View 같은 참조모델이 존재한다.

 

 


다음 그림은 아파트의 특정 가구에 대한 설계도이다.

이 설계도는 개별 세대의 방구조와 배치, 동선 등을 표현하는 좀더 세부적인 아키텍처에 해당한다. 또한 전문적인 기호와 수치는 또 다른 이해관계자(설계자, 시공업자 등)를 위해 제공되는 정보 상세한 설계 기준으로 사용된다.

 


현대 건축의 아버지라 불리우는, '르 코르뷔지에'는 다음과 같은 말을 했다고 한다.


 

우리는 돌, 나무, 시멘트를 사용하여 집을 짓고 건물을 만든다.

이것은 건축이다.

 

그런데 문득 그것이 내 마음을 사로잡고, 나를 감동시킨다.

그 순간 행복한 나는 이렇게 말한다.

 

"아~ 아름답군!". 아키텍처(Architecture)란 그런 것이다.

 

- 르 코르뷔지에, 19123 "Architecutre: From Prehistory to Post-Modernism"


 

IT 개발의 많은 요소들이 건축의 그것에서 차용되어왔다. IT 아키텍처 역시 건축물의 아키텍처 사상에 근원하고 있으며, 아키텍트라면 르 코르뷔지에와 같은 마인드를 가져야 하지 않을까 한다.

 

마지막으로 앞의 구본형 소장의 글을 SW아키텍처에 비유해 다음과 같이 무단 변경해 본다. 

 



SW아키텍처를 제대로 이해하기 위해서는 건축물을 연상하는 것이 가장 완벽한 동질성을 부여한다.

 

SW아키텍처는 '시스템의 설계도'라고 말하는 사람들이 많다.

그러나 나는 그 생각에 강하게 반대한다.

 

그것을 설계도라고 해석하는 데서부터 많은 오류가 발생한다는 것을 알고 있기 때문이다.

설계도는 전문가들을 위한 것이다.

 

보통 사람은 설계도를 보고 그 건물의 전체적 모습을 떠올릴 수 없다.

그것은 판독하기 어려운 수치와 기호일 뿐이다.

 

SW아키텍처는 이해관계자 모두가 쉽게 그 모습을 머릿속에 떠올릴 수 있어야 하며,

그 모습의 아름다움 때문에 마음이 설레야 한다.

 

따라서 SW아키텍처는 오히려 건물의 조감도와 흡사하다.

소프트웨어의 유려한 자태와 추상화된 고품질의 질감이 느껴져야 한다.

 

그리고 그 시스템 속의 한 부분을 줌업시키면 그 속에 서브 시스템이 생활할 새로운 공간이 보인다.

 

이 시스템이 만들어지면 이 아름다운 것을 사용할 것이다.

어둡고 추운 지금의 시스템을 떠나 밝고 넓고 전망이 좋은 시스템을 활용하게 될 것이다.



 

'프로젝트 관리' 카테고리의 다른 글

아키텍처의 출발점  (0) 2019.04.04
Core/Context 모델  (0) 2019.03.22
Tuckman의 팀 발달 모델  (0) 2019.03.08
Posted by 사용자 박종명

댓글을 달아 주세요

아마... 아래 그림은 한번쯤은 본 적이 있을 겁니다.
개개인의 서로 다른 재능을 무시한채, 획일적인 기준으로 평가하는 문제를 풍자하는 그림인데요..


"공정한 선발을 위해 같은 시험을 봐야 합니다: 모두 저 나무에 올라 가세요" (말풍선)

"모두가 천재다. 그러나 나무에 오르는 능력으로 물고기를 판단한다면, 그 물고기는 평생 자신을 멍청하다고 생각하며 살아갈 것이다" - 아인슈타인



이 카툰은 획일적인 교육과 평가에만 의존하는 교육분야의 문제 인식으로 자주 인용되지만, 기업의 경영 전략에도 대입해 볼 수 있다는 생각이 듭니다.


기업의 존재 목적은 수익 창출입니다. 모든 기업은 수익을 창출하기 위해 다른 기업과는 차별화된 재화나 서비스를 시장에 공급합니다. 이러한 수익 창출 과정에서 주어진 자원을 최대한 효율적으로 사용해서 수익을 극대화 시키고 리스크(risk)를 경감하는 것이 중요합니다.


따라서 기업은 자신이 제공하는 핵심 서비스 전개를 위한 업무 역량은 자체적으로 내재화 시켜서 경쟁력을 확보하고 다른 기업과의 차별화를 꾀해야 합니다. 


반면, 핵심 서비스에 직접적이지 않은 비 핵심업무는 다른 기업이나 다른 사람에게 위임하여 그들의 전문성을 활용하는 것이 좋습니다. 그렇게 해야 생산성이 향상하고 리스크를 경감할 수 있습니다. 


기업의 외주(아웃소싱) 전략에 좋은 참조 모델이 있어 소개하고자 합니다.


---


'캐즘(Chasm) 이론'으로 유명한 제프리 A.무어의 '코어/컨텍스트(Core/Context) 모델'은 기업이 주어진 자원을 어떻게 운용하는 것이 좋을지에 대한 참조 모델을 제시하며 '클라우드 충격'이라는 책에서 자세히 설명하고 있습니다.


코어(Core)란 의미 그대로 기업의 핵심 업무를 말합니다. 코어 업무는 기업의 경쟁우위를 높여주는 중요한 것이므로 최대한 자원을 집중해야 하고 자체 개발을 해야 한다는 것입니다.


반면 컨텍스트(Context)는 코어 이외의 모든 활동이라고 말합니다. 컨텍스트 업무는 차별성을 추구하는 것이 아니라 가능한 표준적인 방식으로 효율을 최우선으로 수행하는 것'이 좋다고 말합니다.


또한 이러한 컨텍스트 업무는 어느 누군가에게는 코어 업무이기 때문에 그쪽에 아웃소싱을 맡길 수 있다고 시사합니다.

게임을 개발하는 기업에서 인사관리 프로그램이 필요한 사례를 예로 들어 보겠습니다.


게임 개발은 회사의 중요한 코어 업무이기 때문에 자체 개발을 해야 하며, 인사관리 프로그램은 컨텍스트 업무이기에 그 업무를 코어로 하는 외부 업체에게 아웃소싱 하는 식입니다.


그러나 코어/컨텍스트만으로는 기업내 모든 활동을 양분하기에는 한계가 있어 보입니다.


무어는 코어/컨텍스트 구분과 더불어, '미션크리티컬/'비미션크리티' 이라는 또 하나의 축을 또 다른 기준으로 내세웠습니다. 미션 크리티컬은 만일 중지되었을 때 즉시 심각한 리스크로 이어지는 기업 활동을 말하며 그 외의 모든 업무는 비 미션크리티컬이 됩니다. 즉 리스크의 정도를 기준으로 삼고 있습니다

.

이에 대한 도식은 아래와 같습니다.


[출처: 클라우드의 충격]


---


제가 속해 있는 IT 분야에서도 아웃소싱 전략에 큰 영향을 주는 두가조 요소가 있습니다.


바로 클라우드(Cloud)와 오픈소스(Opensource)입니다.


오픈소스의 경우 외주(아웃소싱)라는 카테고리와는 성격이 조금 다를 수 있지만, 특정한 업무를 외부 자원으로 해결한다는 위임이라는 측면에서는 맥을 같이 하기에 연결지어 봤습니다.


클라우드의 경우 종전의 자체 전산실에 직접 렉과 장비를 구비하고 운영했던 온프레미스(On-Premise) 환경과는 달리 클라우드 환경에서는 이러한 물리적인 장비와 운영체제, 소프트웨어까지 빌려 쓸 수 있게 되었습니다. 또한 기업은 자신들이 어디 까지를 직접 운영할지 결정하여 Iaas, Paas, Saas 형태의 클라우드 서비스 모델을 선택할 수 있습니다. 


갈수록 IT 환경의 판이 많이 달라지고 있습니다. 자원을 최적화 시키는 것은 기업의 생산성을 향상시키는 것 뿐만 아니라, 서로 다른 재능을 가진 기업간 위임이 활성화 되어 산업의 발전에도 기여하게 된다고 봅니다. 과거 분업화가 많은 발전을 야기한 것 처럼요.


현재 자신의 회사나 수행하는 프로젝트에서, 코어와 컨텍스트, 미션크리티컬과 비미션크리티컬의 4사분면에 해당하는 업무가 무엇인지 파악하여 전략을 재정비 해 보는 것도 좋을 것입니다.

'프로젝트 관리' 카테고리의 다른 글

아키텍처의 출발점  (0) 2019.04.04
Core/Context 모델  (0) 2019.03.22
Tuckman의 팀 발달 모델  (0) 2019.03.08
Posted by 사용자 박종명

댓글을 달아 주세요

지금까지 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
Tuckman의 팀 발달 모델  (0) 2019.03.08
Posted by 사용자 박종명

댓글을 달아 주세요