Core/Context 모델

Posted in 프로젝트관리 // Posted at 2019. 3. 20. 12:03

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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


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

---

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

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

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

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

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

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

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

Core/Context 모델  (0) 2019.03.20
Tuckman의 팀 발달 모델  (1) 2019.03.07
데브옵스 처방전  (0) 2015.05.21
개발자 칠거지악  (0) 2015.02.06
6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05

submit

Tuckman의 팀 발달 모델

Posted in 프로젝트관리 // Posted at 2019. 3. 7. 13:00

지금까지 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의 이론을 하나의 표로 요약해 봅니다.

처음 이 모델을 봤을 때, 참으로 공감되는 내용이 많았습니다.

제가 맡은 여러 형태의 팀들 중에서도 특히, 프로젝트에 특화된 팀(TFT)이나 SI 프로젝트를 수행하는 팀 구조에서 이 모델의 적합성이 더 높았습니다.


각 단계별 리더십 스타일

이 글에서 하고자 하는 얘기의 핵심입니다. 팀리더가 어떻게 해야 팀을 원만하게 운영하고 프로젝트를 성공시키느냐 하는 것입니다.

팀리더는 프로젝트를 성공시키고 팀을 성장시키는데 책임이 있습니다. 그 책임을 다하기 위해서는 팀과 팀 구성원들을 정확히 이해하고 자신의 리더십 스타일을 적절히 변경할 수 있어야 합니다.

즉 팀 리더는 Tuckman의 모델에 참조하여 팀을 이해하고 자신의 리더십 스타일을 결정하거나 조정할 수 있습니다.

여기에 좋은 안내서가 있습니다.


https://kristalaace2014.wordpress.com/2014/02/26/w1_al_tuckman-analysis-assignment/comment-page-1/

위의 표는 각 단계별로 팀리더의 스타일을 안내하고 있습니다. 저도 이 표를 보면서 간과했던 부분을 다시금 깨닫는 계기가 되었습니다.


형성기(Forming)

모든것이 불명확하고 불확실한 상태입니다. 프로젝트의 목표와 과제에 대해 공감과 이해가 부족한 상태이며, 구성원들은 서로 어색하고 신뢰가 형성되지 않은 시기입니다.  

'우리가 여기에 왜 모였는가?'' 를 분명히 해야 합니다.

팀 리더는 팀 구성원들이 길을 잃지 않고 프로젝트를 수행할 수 있는 초석을 마련해야 합니다. 프로젝트의 목표와 방향성을 명확히 수립하고 전달해야 합니다. 또한 R&R을 설정하는 동시에 구성원 개개인과 프로젝트 과제(What) 자체에 집중해야 할 시기입니다.

다시 말하자면, 우리가 왜 모였으며 무엇을 언제까지 누가 어떤 일을 해야 하는지를 명확히 해야 할 시기입니다. 그러므로 이 시기에는 보다 직접적인 리더십 스타일이 필요한데 이를 지시형 리더십 스타일이라 하겠습니다.

격동기(Storming)

앞서 형성기의 단계를 거쳐, 팀 구성원들은 프로젝트의 목표와 개인의 역할을 인지하게 되었습니다. 이제 본격적으로 각 구성원들이 프로젝트를 위해 일을 시작하는 시기입니다. 그러나 이제 막 모인 사람들은 각자의 업무 스타일과 개성이 표출됩니다. 이로 인해 잦은 의견충돌과 대립이 발생하면서 긴장상태로 접어들기도 합니다. 말 그대로 격동기 입니다.

팀 리더로써 가장 중요한 시기입니다. 다름과 틀림을 구분할 수 있도록 해야 합니다. 구성원들의 서로 다른 업무 스타일로 갈등이 고조되지 않도록 하는 조치가 필요합니다. 팀이 일을 하는 방식에 대한 표준(기술표준, 프로세스 표준, 의사결정 방식 등)이 반드시 필요합니다. 각자의 스타일을 존중하되, 협업을 위한 표준으로 각자의 업무 스타일을 조화시켜야 합니다.

이 시기의 팀 리더는 구성원들의 개인적인 상호작용에 많은 관심을 가져야 합니다. 구성원들의 의견 불일치, 갈등을 적극적으로 중재해야 합니다. 이때 팀의 표준과 프로세스가 많은 도움이 됩니다.

코치형 리더십 스타일이 필요하다 하겠습니다. 특히 개인적인 관계를 촉진하는 역할이 중요합니다.


규범기(Norming)

이제부터 팀의 정체성이 서서히 형성되기 시작합니다. 팀 구성원들은 공동의 목표 달성을 위해 모였다는 것을 자각하게 됩니다. 각자는 상호 조화를 위해 노력하기 시작하고 서로를 신뢰하기 시작합니다. 이제 각 구성원들은 자신의 작업을 원만히 수행하며 조화롭게 협업하기 시작합니다.

이때 팀 리더는 작업 그 자체 보다는 작업과 작업간의 흐름과 우선순위, 프로세스에 집중해야 합니다.
즉 프로젝트의 진행 자체를촉진하는 참여형 리더십 스타일로 팀을 리딩하는 것이 좋습니다.


성과기(Performing)

이제 팀은 최고의 성과를 내기 시작합니다. 서로간의 신뢰가 매우 높아진 시기입니다. 프로젝트 목표 달성을 위해 구성원 스스로가 최적의 방안을 스스로 도출해 내기도 합니다. 팀 자체가 하나의 유기체로 동작하게 되며 자신감이 최고조에 달하는 시기입니다.

팀 리더는 구성원들에게 권한을 위임해도 큰 문가 없으며 오히려 권한 위임으로 인한 동기부여와 시너지가 높아지기도 합니다. 즉 위임형 리더십 스타일이 권장됩니다.


해지기(Adjourning)

프로젝트의 수행이 완료되고 팀이 해체하는 시기입니다. 보통 기능조직팀은 해체라는 것이 없지만 프로젝트에 특화된 팀은 해체하게 됩니다.

이 시기에는 특별한 리더십 스타일이 요구된다기 보다는, Lesson Learned를 통해 프로젝트를 수행하면서 겪었던 성공과 실패, 프로세스 지식 등을 정리하고 평가를 수행합니다. 

이러한 경험이 쌓여 다음 프로젝트에 경험적 지식으로 활용됩니다.


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

Core/Context 모델  (0) 2019.03.20
Tuckman의 팀 발달 모델  (1) 2019.03.07
데브옵스 처방전  (0) 2015.05.21
개발자 칠거지악  (0) 2015.02.06
6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05
  1. 김영찬

    동아리 운영하는데 도움이 될 것 같네요!

submit

데브옵스 처방전

Posted in 프로젝트관리 // Posted at 2015. 5. 21. 11:43

 

이런 증상이 있지 않나요? 데브옵스를 처방해 드리겠습니다.

------------------------------------------------------------------------

우찌.. 이런..

이리도 이그젝틀리 한지..

 

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

Core/Context 모델  (0) 2019.03.20
Tuckman의 팀 발달 모델  (1) 2019.03.07
데브옵스 처방전  (0) 2015.05.21
개발자 칠거지악  (0) 2015.02.06
6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05

submit

개발자 칠거지악

Posted in 프로젝트관리 // Posted at 2015. 2. 6. 16:01

IT 전문 매거진에 실린 '개발자가 저지르기 쉬운 7가지 나쁜 습관'의 내용이다.

오늘자 전자신문에 실린 '정보통신산업진흥원 SW공학센터장(이상은)'의 컬럼 내용을 옮겨온다.

 

자칫 나태해지기 쉬운 개발업무를 돌아볼만 하다.

 

 

1. 욕심에 의한 엔지니어링의 남용

- 책에서 제시된 방식들이 항상 효과가 좋은 것은 아니어서 원래 사용했던 방법을 효과적으로 사용하는 것이 더 좋은 방법일 수 있다. 프로그래밍의 대가들은 "새로운 기법을 활용하는 것보다 더 중요한 것은 기능의 효과적 구현이다"라고 말하고 있다.

 

2. 계속 기능만 추가하고 개발했던 내용을 리팩토링하지 않는 것

- 이미 개발된 코드는 완전하지도 않으며 추가되는 기능이 점점 늘어 갈수록 복잡해지고 뒤엉켜 버리기 때문에 기존 코드의 품질과 유지보수성을 평가해 코드에 대한 신뢰성을 확보하는 것이 중요하다.

 

3. 개발자 사이의 경쟁

- 팀 간에 프로젝트가 비공개적으로 진행되면 다른 팀이 이미 구현한 라이브러리를 중복적으로 개발하게 된다. 개발의 최우선 과제 중 하나는 각자가 어떤 작업을 하고 있는지 서로에게 알리는 것이고, 모든 팀들이 공통의 목표를 갖고 정보를 공유하는 것이다.

 

4. 입력값의 유효성 검증에 실패하는 나태함

- 개발하면서 사소한 실수는 빈번히 일어자지만 잘못된 입력값을 받아들이는 개발 실수는 매우 치명적이어서 신중해야 한다.

 

5. 소스코드에 코멘트를 달지 않는 것

- 일단 개발된 소스코드는 보관되었다가 나중에 유지보수를 위해 다른 사람이 작업을 하게 되는 것이 보통이다. 이때 코멘트가 없다면 해당 코드가 무엇을 의미하는지 이해하기 어렵고 시간도 오래 걸린다. 따라서 최소한 힌트를 남겨둬야 한다.

 

6. 버전관리를 하지 않는 것

- 요즘엔 강력하고도 효과적인 버전관리 도구를 무료로 손쉽게 구할 수 있다. 심지어 분산 프로젝트를 관리할 정도의 도구도 최소 비용으로 구할 수 있다. 따라서 다른 문제가 없다면 가장 기본이 되는 버전관리시스템은 반드시 만들어둬야 한다.

 

7. 단위테스트를 하지 않는 것

- 개발된 프로그램이 좋은 평가를 받는 것은 개발자로서 영광스러운 일이다. 하지만 결함을 가진 코드가 출시된다면 그 뒤처리를 감당하기 어렵게 된다. 코드를 출시하기 전에 단위 테스트를 철저히 할수록 나중에 감당해야 하는 피해를 최소화할 수 있다.

 

 

 

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

Tuckman의 팀 발달 모델  (1) 2019.03.07
데브옵스 처방전  (0) 2015.05.21
개발자 칠거지악  (0) 2015.02.06
6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05
공학의 ACE  (0) 2013.06.28

submit

6하원칙 리더십

Posted in 프로젝트관리 // Posted at 2014. 7. 9. 23:30

 

누가(who),  언제(when),  어디서(where),  무엇을(what),  왜(why),  어떻게(how)

 

그 규모의 크기에 상관없이, 리더는 책임감을 가지고 자신의 리딩 업무를 수시로 점검해야 할 것이다.

 

리더에게 주어진 것은 명령을 할 수 있는 권한이 아니다.

리더에게 부여된 권한은 책임에 수반되는 수단일 뿐이다.

라서 책임이 없는 리더의 권한은 봉건사회 계급구조상의 비루한 권력과 다를바 없다.

 

프로젝트팀을 관리하는 리더의 책임은 무었일까? 리더가 구성원들의 모든 잘못에 책임을 져야 하는가?

 

여기서 언급하는 책임은 이러한 1차원적인 문제가 아니다.

 

제일 중요한 리더의 책임은 바로 '비전' 제시이다. 그 흔하디 흔한 말... '비전'이다.

식상할 정도로 자주 언급되는 이 말은 역설적으로 그 실체를 찾기 힘들 정도로 귀하디 귀하다.

 

흔히 어떤 일을 구체화 시킬 때 6하원칙에 입각하여 서술하곤 한다.

 

리더의 책임이라는 관점에서 가중 중요한 원칙은 바로 "왜(why)" 이다.

구성원들이 하는 '그일'에는 이유가 있어야 한다는 것이다. 이유도 모른채 혹은 이유가 공감되지 않은채 하는 일은 초등학생도 싫어하는데 하물며 성인이래야...

 

'왜(why)'가 뚜렷하다면, '무엇(what)'은 저절로 성립된다.

 

반면, 평범한 리더(리더라 부를 수 있을지 모르겠지만...)는 '어떻게(how)'에 집중한다.

구성원들에게 '이건 이렇게, 저건 저렇게...' 어떻게 하는지 알려 주고 싶어서 안달이다.

키 플레이어가 좋은 리더가 되기 힘든 대표적인 사례라 하겠다.

 

더 최악은 '누가, 언제, 어디서'에만 집중하는 리더이다. 사실 이런 부류는 리더라 부르면 안된다.

야근의 횟수로 역량의 척도로 판단하는 전형적인 예를 들 수 있겠다.

 

6하 원칙은 모두 중요하다.

 

하지만 훌륭한 리더가 되기 위해서는 '왜(why)'와 그에 맞는 '무엇을(what)'에 우선 집중해야 한다.

'어떻게(how)'는 그 다음이다.

 

조직의 핵심 가치에 공감한 구성원들이 그들의 열정과 호기심을 프로젝트에 불싸지르도록 하는 중요한 기준임을 명심하자!!!

 

스스로 반성해 볼 일이다.

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

데브옵스 처방전  (0) 2015.05.21
개발자 칠거지악  (0) 2015.02.06
6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05
공학의 ACE  (0) 2013.06.28
주석은 Why > What > How 순으로...  (2) 2013.06.12

submit

요청 수가 꽤 되는 미들웨어 시스템이 있다. 그리고 이 시스템은 매번 호출 될 때마다 상세한 호출 로그를 남긴다.  마치 SQL Server의 프로파일러 마냥...

 

중요한 건 특별한 상황이 아니면 이 로그는 거의 볼 일이 없다는 것이다.

시스템이 오픈 된 초반에는 많이 참고하지만, 어느정도 안정성이 확보된 이후에는 특별히 사고나 나지 않는 이상 들여다 볼일이 거의 없다.

 

문득... 보지도 않는 이 많은 로그를 저장하는게 비효율적이라는 생각이 들었다.

그래서 보통 다른 산업에서 적용하고 있는 '표본조사'가 떠올랐다.

 

어느 제품을 생산하는 라인에서 매번 높은 수준의 전수 조사를 하게 되면 효과에 비해 비용이 너무 많이 들게 된다. 그래서 생산품 중 일부를 표본적으로 조사하는 방식이 이용되는데 로그저장도 이와 같은 개념을 접목시키면 좋겠다는 생각이 들었다.

 

즉, 매 50번째 마다 호출로그 남기기!!!

 

물론 이런 산업에서는 생산과정이 항상 일관되고 특별한 외부 요인이 개입되지 않는 환경 즉, 생산의 표준화가 보장된 상태여야 하는 전제조건이 있긴 하다.

 

따라서 표본적으로 로그 수집을 하는 경우에도 오류로그는 매번 발생할 때마다 남기는 것이 권장될 것이다.

 

결론적으로, 일반적인 로그는 표본로그로 오류 로그는 전수로그로 남기는 것이 핵심!!!

 

 

 

 

 

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

개발자 칠거지악  (0) 2015.02.06
6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05
공학의 ACE  (0) 2013.06.28
주석은 Why > What > How 순으로...  (2) 2013.06.12
애매함의 불편함  (0) 2013.06.12

submit

공학의 ACE

Posted in 프로젝트관리 // Posted at 2013. 6. 28. 14:54

모든 분야의 엔지니어링 원리는 다음과 같이 단계적인 발전 과정을 거치게 된다

 

Art --> Craft --> Engineering

 

공학의 ACE라 하는데, 각 단계는 다음과 같은 의미를 가지고 있다

 

Art개인의 재주에 의존하는 단계

Craft: 차츰 과학적 원리가 도입된 숙련공이 일반화 되는 단계

Engineering: 공학적 원리가 적용되는 단계

 

소프트웨어 공학 서적에 나오는 내용으로 소프트웨어 역시 다른 엔지니어링 분야의 단계와 같은 발전 과정을 거친다는 것이다. 타 산업분야에 비할바는 아니지만, 소프트웨어 공학이라는 개념이 탄생한지도 50년이 다 되어가니 적지 않은 세월이 흐른 셈이다.

 

소프트웨어 산업의 중심에 있는 우리 프로그래머들은 과연 이러한 체계적인 공학 원리에 충실하고 있는지 생각해 봐야 할 문제이다. 국내 환경이 공학적 접근 노력을 시도할 수도 없을 만큼 스펙타클하게 운영되고 았는 현실인지라 힘에 겨운 것도 있지만, 그렇다고 환경만을 탓하고 있기엔 우린 너무 빨리 늙어 버린다. ㅎㅎ

 

소프트웨어 공학이라는 개념이 탄생하고 뛰어나신 분들이 연구에 연구를 거듭하는 것은 결국 소프트웨어의 품질과 생산성이라는 두 마리 토끼를 어떻게 쉬이 잡을 것이냐를 위한 것인데 프로그래머들의 현실적인 생산성 문제로 공학적 접근을 하지 못한다는 것은 뭔가 앞뒤가 맞지 않다

 

소프트웨어 공학이 프로그래밍 코드보다는 개발 공정에 초점이 맞춰져 있어 내일 당장 동작하는 코드를 내뱉어야 하는 프로그래머들에게는 (뭔가.. 그럴싸 하다는 건 알겠으나...) 체감되지 않기도 한다

 

역사가 깊은 건축 공학의 많은 개념이 소프트웨어 공학에도 접목되는데, 예를 들어 빌딩을 지으면서 공학적 접근을 하지 않을 수는 없을 것이다. 그럼 아파트 혹은 빌라라면?? 아니면 집에서 키우는 개를 위한 개집을 짓는다면??

 

산업의 발전을 그렇다치고, 우리 개인의 발전 과정과 현 상태는 어떤가?

A와 C단계를 겨우겨우 오르락 내리락 하지 않는지, 자문해 볼 일이다.

 

작은 슈퍼를 운영하더라도 경영 마인드가 있어야 한다는 예기가 있다

 

비슷하게 풀어보면,

개집을 지어도 빌딩 건축업자 마인드가 있어야 있어야 하지 않을까?

 

오버거나 말거나...

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

6하원칙 리더십  (0) 2014.07.09
로그수집에 대한 잡설(전수조사 vs 표본조사)  (0) 2013.09.05
공학의 ACE  (0) 2013.06.28
주석은 Why > What > How 순으로...  (2) 2013.06.12
애매함의 불편함  (0) 2013.06.12
조직의 비전 vs 개인의 가치  (1) 2013.04.02

submit

주석은 Why > What > How 순으로...

Posted in 프로젝트관리 // Posted at 2013. 6. 12. 20:24

프로그램 코드의 주석은 코드 이해와 유지보수성을 좋게 하는 중요한 요소이다.

그러나 실무 환경에서는 잘 지켜지지 않는 경향이 있다. 개발 규칙이 철저하게 지켜지는 환경이라면 몰라도 그렇지 않을 경우 종종 무시되곤 한다.

 

코드에 주석을 다는 것이 중요하다는 것은 두말이 필요 없을 것이며, 더 나아가 주석에 어떤 내용을 담을 것인가도 매우 중요하다 하겠다. 특히 다른 사람이 작성한 방대한 코드를 분석하게 될 경우 주석의 퀄리티(?)는 분석을 얼마나 빨리 정확하게 하는가의 주요한 잣대가 된다.

 

주석의 퀄리티는 주석에 담긴 내용으로 평가할 수 있다. 개인적으로 주석의 내용은 다음과 같은 순으로 작성하는 것을 권장.. 아니 필수라고 하고 싶다.

 

Why > What > How

 

지금 자신의 주석 습관을 되새겨 보자. 대체로 What 을 설명하고 있지 않는가?

 

제일 중요한 것은 Why이다. 즉 해당 코드가 왜 이렇게 작성되었는가?에 대한 대답이다. 특히 오랜 시간 유지보수되어온 코드라면 Why는 더욱 중요해진다. 대부분의 프로그램은 시간이 감에 따라 수정/보완이 되고, 요구사항/환경의 변화와 시스템의 제약사항 등으로 처음 보는 사람이 쉽게 납득하지 못하는 형태로 변모되기 일쑤다.

 

다시 말해 코드 자체가 이해 되지 않는 경우보다는 왜 코드를 이렇게 작성해야 했는가?... 에 대한 대답이 필요하게 되는 것이다. 이것은 코드를 잘 작성했고 못했고의 문제가 아니다. 코드의 히스토리에 대한 의문이다.

 

필자는 실제로 방대한 시스템을 인수받을 일이 있었다. 그 시스템은 오랜 시간 운영 되어온 시스템으로 주석이 잘 작성되어 있지 않았을 뿐더러 있는 주석의 경우에도 대부분 What를 설명하고 있었다. 따라서 코드 분석에 가장 많은 시간을 할애한 부분이 바로 Why에 대한 대답을 찾는 것이었다.

 

사실 코드를 읽을 수 있는 프로그래머라면 What과 How는 어렵지 않게 파악이 가능하다. 그러나 Why의 경우 쉽지 않다. 특히 코드 자체가 아니라 시스템의 제약사항이나 요구사항의 특수성을 반영한 코드를 Why 없이 분석한다는 것은 참으로! 쓸데 없는 에너지가 낭비되는 것이다.

 

(참고로 개발자 들이여... 남의 코드를 보고 무조건 까지 말자. 그에게 말 못할(?) Why가 있었을지도 모른다)

 

결론! What과 How도 간단하게 명시하는 것이 좋지만 귀찮다면 Why 라도 남기도록 하자.

 

혹시 '누구 좋으라고' 라는 의문이 드는가? 그렇다면 당신은 지친 개발자!

 

Tags 주석
  1. 박현수

    지친 개발자 here we go~

  2. 입문자

    좋은 글들 잘 읽고 갑니다.

submit

애매함의 불편함

Posted in 프로젝트관리 // Posted at 2013. 6. 12. 10:46

아침 출근길에 애매한 신호등과 마주쳤다.

 

빨간불이었다가, 갑자기 빨간등과 녹색등이 같이 들어와 버린 상황. 순간 정지해 있던 차량들의 주춤거리는 모습. 다행히 차량 통행이 많지 않고 복잡한 도로가 아니라서 큰 혼란은 발생하지 않았지만, 문득 머리속에 스친 생각은 프로젝트 관리도 이와 다르지 않다는 것이었다.

 

 

(당신이 이 신호등과 마주쳤다면 어떻게 하겠는가?)

 

프로젝트 관리자는 여러 애매한 상황에 놓인다. 특히 시스템이 방대하고 이해관계 마저 복잡한 경우에는 더욱 그러하다. 따라서 프로젝트 관리자는 애매한 상황을 정리하는데 노력을 기울여야 하며, 프로젝트 구성원들이 정확한 노선으로 일을 진행할 수 있도록 도와야 한다.

 

프로젝트 관리자가 어떤 결정을 내릴 때, 스스로 애매함을 정리하기 힘든 상황이라면 다음 두 가지 요령이 필요하다.

 

애매함 보다는 차라리 고집이 낫다

애매함을 오랜 시간 방치하기 보다는 차라리 고집을 부리는 것이 낫다. 오랜 시간 방치한 애매함은 프로젝트의 진행을 더디게 만들고 구성원들을 지치게 한다. 차라리 결정을 하고 독단적이라는 비난을 두려워 하지 말고 고집을 부리는 편이 낫다. 단, 고집을 부릴만큼 본인이 많은 고민을 해야 한다. 한면이라도 고집의 근거와 타당성이 있어야 한다는 말이다.

 

애매함 보다는 위임을 활용하라

고집을 부리기 싫거나 한면이라도 타당성을 찾기 힘든 상태, 아니면 그 어떤 이유로든 고집을 부리기 힘든 상황이라면 차라리 그 결정을 위임하는 것이 좋다. 이것은 책임을 회피하기 위해 일을 떠넘기는 개념과는 다르다. 결정도 정확히 내리지 않고 누군가가 결정하도록 위임도 하지 않는다면 모두가 실패하는 결과를 맞을 것이다. 수 많은 결정들 가운데 일부는 그들의 능력을 전적으로 활용하라는 것이다.

 

물론 고집과 위임이 애매함의 유일한 해결책은 아니다. 이것은 애매함을 순조롭게 풀기 힘든 상황에 꺼낼 수 있는 카드라고 하는 것이 맞겠다.

 

 

 

 

 

 

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

공학의 ACE  (0) 2013.06.28
주석은 Why > What > How 순으로...  (2) 2013.06.12
애매함의 불편함  (0) 2013.06.12
조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
경험 관리하기  (0) 2013.01.04

submit

조직의 비전 vs 개인의 가치

Posted in 프로젝트관리 // Posted at 2013. 4. 2. 19:00

소프트웨어 기반 프로젝트의 성공에 매우 밀접하게 작용하는 요소가 바로... 사람이다.

 

인적자원관리라는 용어가 사용되는데, 인적자원의 획득과 역할과 책임, 양적/질적 관리와 교육/평가/보상 등을 관리하는데, 뭐니뭐니 해도 동기 부여를 어떻게 하느냐가 핵심이라 할 수 있다.

 

각 개인마다 서로 다른 내적 동기요소를 파악하여 프로젝트 혹은 회사의 궁극적 비전과 일치 시키는 것이 이상적이라 하겠다. 그러나 문제는 이게 말 처럼 그렇게 쉽지 않다는 것이다.

 

조직의 비전은 간혹 어떤 사람들에게는 '그들만의 비전'으로 치부되기도 한다.

 

조직의 비전, 개인의 가치.. 이 둘의 함수관계에 따른 공헌도 조사가 흥미롭다.

아래 글에 따르면, 이 두 가지 가치의 조화가 가장 이상적이지만, 차선책은 개인의 가치 확립에 무게 중심을 둬야 한다는 시사점을 제공한다.

 

결국 조직의 비전을 확고히 하고 이를 공유,공감시키는 활동과 더불어 이와는 별개로 개인의 가치 확립에도 노력과 비용을 들이는 것이 궁극적인 프로젝트 성공에 열쇠가 될 수 있다는 점이다.

 

개인적 가치의 확립은 헌신과 솔선수범에 이르는 길이 된다.

한 조사기관에서 사람들에게 이런 가치 확립과 특별한 성과를 얻기 위한 노력 간의 함수관계에 대해 질문했더니, 집단이나 조직의 가치가 불분명하고 개인의 가치도 확립되지 않았을 경우에 평균 공헌도는 7점 만점에 4.9점이 나왔다. 또 집단의 가치가 명확하고 개인의 가치가 불분명할 경우에도 역시 평균 공헌도는 낮았다. 그에 반해 집단의 가치가 명확하지 않지만 개인의 가치가 확립되어 있을 때는 7점 만점에 6.12점이 나왔고, 개인의 가치와 집단의 가치가 모두 확실하고 이 두 가지가 조화를 이룰 때는 평균 공헌도가 7점 만점에 6.26점으로 가장 높았다. 이런 수치로 미우러 볼 때, 자신의 개인적 가치를 알고 있다는 것은 집단의 가치를 공유하는 것보다 더 중요하다는 사실을 알 수 있다.

- +9(플러스 나인), 로버트 K. 쿠퍼 저

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

주석은 Why > What > How 순으로...  (2) 2013.06.12
애매함의 불편함  (0) 2013.06.12
조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
경험 관리하기  (0) 2013.01.04
인수 요구 산출물  (0) 2013.01.03
  1. aral1

    개발자의 자존감을 지켜주고 동기부여를 해줄때 개발자는 자신의 역량을 최대치로 발휘한다는 말씀이군요.
    신이난다, 신들렸다 이런 것들과 일맥상통하지 않나 싶습니다.
    그럴때 개발자는 초능력 즉, 자신을 뛰어넘는 능력을 발휘할 수 있는것 같습니다.

submit