블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

애자일 팀 모델에 대하여

ALM/애자일 | 2015.09.08 23:50 | Posted by 조대협

애자일 팀 발전 모델에 대하여

Functional team, Product Team, Feature Team

조대협 (http://bcho.tistory.com)

 

개요

 

관리자(CTO)역할을 맏으면서 가장 고민중에 있는 것 중 하나는 팀을 어떻게 모델하여 최적화된 개발팀 구조를 가지느냐 이다.

근래의 개발팀의 모델은 애자일 사상에 영향을 받아서 작고, 독립적인 팀의 모델로 진화하고 있으며 대략적인 특징은 다음과 같다.

·             Self organized

·             Cross functional

·             2 pizza team


Cross functional 모델은, 하나의 팀 내에서 기획부터 디자인,개발 및 테스트를 모두 진행할 수 있는 팀 모델로 팀 안에 앱,프론트,백앤드 개발, 기획,테스터와 같은 모든 역할을 하나의 팀내에 모두 가지고 모델이다. 이런 모델을 기반을 Self organized라는 팀 모델을 가질 수 있는데, 이는 팀내의 모든 기능 유닛들이 다 있기 때문에 팀이 독립적으로 제품에 대한 기획에서 부터 개발 및 출시가 가능하게 되는 모델이다. 이러한 팀 모델은 원할한 커뮤니케이션을 전제로 하기 때문에 팀의 구조가 커지면 원할한 커뮤니케이션이 어려운 이유로 팀의 규모는 두개의 피자를 먹을 수 있는 정도의 팀구조 즉 7~8명 정도의 2 pizza team 정도의 구조를 가지게 된다

 

팀 모델과 더불어 이러한 모델을 효과적으로 적용할 수 있는 Devops와 같은 서비스 운영 모델이나, MSA (Micro Service Architecture)와 같은 아키텍쳐 모델이 발전되고 있다. 이 부분은 오늘 다루고자 하는 부분이외의 부분이기 때문에 넘어가도록 한다.

 

이렇게 Cross functional team model로 이동을 함에 있어서도 몇가지 문제들이 발생하는데, 이러한 문제를 해결하기 위한 다음 모델이 Featured team model 이다. 이 글에서는 전통적인 functional team model에서 부터, 현대 애자일이나 MSA와 함께 대두 되고 있는 Component based team model 그리고 최근에 소개되고 있는 Featured team model에 대해서 알아보고자 한다.

 

이해를 돕기 위해서 아래와 같은 일반적인 앱/웹 서비스를 예를 들어서, 이러한 서비스를 개발하기 위한 각 팀모델에 대해서 설명하도록 하겠다.

이 서비스는 뉴스에 대한 포스팅과 함께 포스팅에 대한 댓글 기능을 제공하는 서비스이고,

모바일앱과 HTML 웹 페이지를 이용하여 사용자에게 서비스를 제공하고,

운영 시스템으로는 관리도구를 이용하여 댓글과 포스팅을 관리할 수 있다.”

 



Functional vs Cross functional team


이러한 팀 모델을 이해하기 위해서는 Functional team modelCross functional team model에 대해서 먼저 이해할 필요가 있다.

 

Functional team

먼저Functional team 모델은 가장 흔하게 존재하는 팀 모델중의 하나로, 개발 기술이나 역할 별로 팀을 나누는 방식이다. 예를 들어 프론트앤드 웹 개발, 앱 개발, 백앤드 개발, QA, 운영팀등으로 나눠서 팀을 관리하는 방식이다.

이 팀 모델을 앞에서 언급한 서비스에 적용하게 되면 다음과 같은 팀 모델이 나오게 된다.

 



이 모델의 장점은 기술을 각팀이 잘 통제하여 각 레이어(계층)별로 일관된 아키텍쳐와 기술 통제 모델을 가지고 갈 수 있지만, 일종의 풀(Pool)모델 처럼 각 기능이나 제품을 개발할때 마다 개발자를 그때 그때 마다 순환 배치하기 때문에 제품(프로덕트)에 대한 일관성을 가지고 가기가 힘들고, 각팀간의 인터페이스를 맞추기 위해서 커뮤니케이션 작업이 추가로 많이 소요된다.

 

Cross functional team

그래서 이러한 기술 중심의 Functional team 모델에서 발전한 것이 근래에 유행하고 있는 Cross functional team 모델이다.

Cross functional team 모델은 앞에서도 언급하였지만, 하나의 팀 안에서 기획에서 부터 프론트앤드, , 백앤드 개발, 테스트 및 운영까지 모두 할 수 있는 조직 모델이다.

 

Component Team & Featured Team in Cross functional team model


Cross functional 팀은 모든 기능(역할)구조를 가지고 있는 구조라는 기본을 가지고 있는데, 이를 세부적으로 살펴보면 크게 Component team (Product Team)Featured team 이라는 두가지 모델로 나눠볼 수 있다.

 

근래에 가장 많이 언급되는 Cross functional team modelcomponent team (product team) 모델이다. 모든 역할을 가지고 있는 하나의 팀이 하나의 제품을 맞는 형태이다. 앞서 언급한 서비스 예제에 맞추어 보면 다음과 같은 구조를 따르게 된다.

 



 

특히나 근래에 마이크로 서비스 아키텍쳐 (aka. MSA)와 함께 가장 많이 언급되는 모델로, 하나의 팀이 하나의 제품을 장기간 맏아서 진행하는 형태이다.  이 경우 기획에서 부터 운영 및 기술 셋까지 완벽하게 독립적으로 운영할 수 있기 때문에, 독립성이 매우 뛰어나서 기동성이 나올 수 있기 때문에 이론적으로는 참 이상적이다.

 

이상적이기는 하지만 이 모델에는 단점이 존재하는데, 일반적으로 하나의 서비스는 하나의 제품이로만 구성되지 않으며, 서비스를 구성하는 제품간에는 유기적인 연동이 반드시 필요하다는 것이다.

위의 예를 들어보면 새로운 댓글 기능이 들어간다고 가정했을때, 이 댓글 기능은 단순히 앱 개발팀이 혼자 단독적으로 수행할 수 있는 것이 아니라, 웹 개발팀도 댓글을 개발해야 하고, 관리도구 개발팀도 이 댓글을 관리 하는 지원 시스템을 개발해야 한다.

그러면 댓글이란 기능을 개발하려면 요구 사항이 3개의 팀으로 전파되어야 하고, 3개의 팀의 연계 아키텍쳐가 같이 설계되어야 한다.

즉 단일 요구 사항을 분석하고, 아키텍트가 기능에 대한 전체 컴포넌트에 대한 큰 설계를 마무리 한후 각 프로덕트팀으로 설계를 내려 보내서 개발을 진행해야 한다.



<그림. Component(Product) 기반 개발팀의 개발 프로세스 >

출처 : http://www.featureteams.org/feature_team_primer12.pdf

 

실제로 필자가 몇년전에 운영했던 팀운용 방식인데, 여러 프로덕트팀을 조율하는 Chief 아키텍트의 역할이 필요하고, 또한 각 팀의 개발 역량이나 개발 분량이 다르기 때문에 개발 스케쥴이 서로 맞지 않는 일이 발생하고 결국에는 이를 조율하기 위한 Program manager와 같은 역할이 필요하다.

 

새로운 팀에서도 이러한 방식의 팀 모델링을 하려고 시도를 했으나 벽에 부딪혔다. 기획이 각 기능 단위로 나오기 때문에, 각각의 프로덕트 오너(기획자)를 팀마다 묶을 수 도 없었을 뿐더러, 그렇게 팀을 나누기에 팀의 크기에 팀원간의 역량에도 차이가 있었다.

할 수 없이 전통적인 Functional Team 모델을 사용하면서 운용을 하면서 적절한 팀 모델을 찾기 시작했다http://bcho.tistory.com/1040

 키는 기능 단위의 팀 모델을 찾았는데, Feature Driven Development (FDD)와 같은 개발 방법론을 찾았으나, 실용적인 개발팀 모델은 찾지는 못했고, 어설프게나마 기능 우선의 개발팀 모델이 필요하다는 것을 느끼고 팀구조를 그렇게 차차 전환하던중에, Craig LarmanBas Vode가 작성한 “Feature Team Primer” 라는 문서를 찾게 되었다. http://www.featureteams.org/feature_team_primer12.pdf

 

잠깐 옆으로 빠지자면, Craig Larman을 처음 접한것은 1996Applying UML 이라는 책을 접하면서였다. 그 당시만 해도 UML에 대한 서적들은 대부분 UML에 대한 Notation이나 다이어그래밍 방법에 포커스가 맞춰져 있었을뿐, 요구 사항에서 부터 UML기반의 잘 정리된 설계 문서까지를 만들어내는 프로세스나 실용적인 방법론이 없었기 때문에 나름 상당히 감명을 받고 읽은 책이었는데, 2010년대에, 큰 조직에서 일을 하면서 애자일 방법론을 엔터프라이즈 레벨까지 확장하고 싶다고 생각하면서 찾았던것이 Enterprise Agile 방법론이나 Scaled Agile 방법론이었는데, 그러던중에 “Scaled Lean & Agile Development” 라는 책에서 또 다시 Craig Larman을 만나게 되었다.




변함없이 실용적인 내용을 담고 있었고, 그 나이에도 그러한 안목과 실용성을 잃지 않는다는게 대단하다고 느끼게 하는 분이다.

그리고 이 “Feature team primer”의 공동 저작자인 Bas VodeOdd-e라는 애자일 컨설팅 회사의 컨설턴트로, 국내에서 일년에 몇번 애자일 교육을 여는 분인데, 팀원들에게 애자일 스크럼 공인 자격증을 받게 하기 위해서 교육 프로그램을 찾던중에 접하게 되었다. 노키아 애자일 방법론등에 영향을 줬고, Craig Larman과 이 문서를 만들었는데, 국내에 20159월달에 교육이 있었고, 오프모임까지 있었지만 (신청해놓고 못나갔다.) 못 만난게 아쉽다. 30분이라도 이야기할 시간이 있었다면 아마도 또 다른 배움이 있지 않았을까?

 

다시 본론으로 돌아와서, 이러한 제품 기반의 Cross functional team의 문제점을 해결하고자 제안된 방법론이 Feature Team 모델이다. 이 모델은 Cross functional team을 조직하고, 이 팀이 제품(프로덕트) 단위가 아니라 기능 단위로 여러 프로덕트에 걸쳐서 개발을 진행하는 모델이다.




 

이 팀 모델을 앞에서 제시한 예시 서비스에 대입해보면 위와 같은 그림이 된다.

각팀에는 기획, 프론트,백앤드,,QA등의 모든 역할의 사람이 들어가 있고, 각 팀은 댓글이나 포스팅과 같은 기능 단위로 전체 컴포넌트(프로덕트)에 걸쳐서 개발을 진행한다.

 

지금까지 생각에는 이게 조금 더 실리적인 방법이 아닌가 하는 결론에는 도달해 있으나, Feature team 모델 역시 많은 단점과 제약 사항을 가지고 있다. 예를 들어 백앤드 개발자는 전체 백앤드에 기능을 녹여놔야 하기 때문에, 전체 백앤드의 구조를 모두 알고 있어야 한다. 프론트앤드도 웹과 관리도구에 대한 프론트엔드 개발을 해야 하기 때문에, 전체를 다 알아야 한다. 즉 개인 개발자나 기획자가 커버해야 하는 영역이 늘어나고, 손대야 하는 코드가 많아지기 때문에, 코드를 개발한 후 머지도 여러 컴포넌트에 걸쳐서 해야 하고, 손이 많이 가지만 하나의 서비스 기능에 대해서 일관성을 가질 수 있는 장점은 있다.

또 다른 문제로는 중앙 통제적으로 아키텍쳐를 드라이브하지 않기 때문에 기능별로 각각의 변종 아키텍쳐가 생겨날 수 있는 문제가 생기고 결국은 기술에 대한 통제 (Technology governance)문제가 발생한다.

 

기술적으로 한명의 엔지니어가 전체 영역을 이해하고, 거기에 각각 코드를 넣기 위해서는 많은 시간이 필요한데, 이를 줄이려면, 새로운 기능을 넣는 컴포넌트(프로덕트)가 새로운 기능을 붙이기에 잘되어 있다면 가능하다. 여기서 프레임웍과 플랫폼에 대한 니즈(needs)가 발생하는데, 새로운 기능을 쉽게 꼽아 넣을 수 있는 형태로 시스템이 개발되어 있으면 된다. 새로운 API를 넣기 위해서는 Spring REST + JPA를 레퍼런스에 따라서 개발을 쉽게할 수 있고, DB 정규화 없이도 탄력적으로 DB모델링을 할 수 있는 Document based NoSQL (eg. MongoDB, CouchBase etc)들로 잘 구성되어 있으며 가이드가 잘되어 있다면, 새로운 기능을 기존 컴포넌트에 추가하는데 크게 문제가 없다. Feature team 모델을 운영하려면, 시스템 아키텍쳐가 쉽게 이해하고 확장할 수 있는 구조로 설계되어 있어야 하고, 새로운 기능을 추가하기 쉬운 가이드나 레퍼런스 구현이 잘되어 있어야 하며, 여러 컴포넌트에 걸쳐 한명의 개발자가 기능을 추가할 수 있어야 하기 때문에, 테크놀로지(프로그래밍 언어나 프레임웍)들이 한정(표준화)되어 있고, 각 엔지니어들에게 교육되어 있어야 한다.

 

그렇다면 결론은 Feature Team 모델인가?

그렇다면 이 Feature team 모델이 모든 개발에 있어서 만병 통치약인가? 결론은 당연히 No이고, 모범 답안은 역시 “Case by case” 이다.

조직에 따라서 프로덕트 단위로 개발을 하는게 더 효율적일 수 도 있고 이런 경우에는 프로덕트(Component) 중심의 cross functional team 모델이 적합할 수 도 있다. 프로덕트에 따라서 빠르고 생산적인 개발 기술이 필요할 경우에는 Ruby on railsnode.js 로 그 제품(프로덕트)를 개발하는 모델을 사용할 수 있다.

또는 한 조직내에서 어떤 제품은 독립성이 높고, 계속해서 기능 추가가 독립적으로 가능하다면 제품 기반의 cross functional team으로 독립 운영하고, 나머지 부분은 Feature team 모델로 운영할 수 도 있다.

즉 개발하고자 하는 서비스나 팀의 상황, 조직의 성숙도, 개발 스피드, 기술 수준, 관리 역량등 다양한 요인에 맞춰서 팀 모델을 점차적으로 변화시켜 나가고 최적의 모델을 찾는게 답이 아닌가 싶다.

 

참고 : http://www.featureteams.org/feature_team_primer12.pdf

매니지먼트의 기본 #1 - 관리자의 역할

(http://bcho.tistory.com)


해당글은 https://www.coursera.org/learn/fundamentals-of-management/outline 코세라 강의를 정리한 글입니다. 


요즘 하는 일이 일이다 보니, 매지니먼트쪽을 많이할 수 밖에 없는데, 얼마전 Cousera 강의에 짧지만 좋은 내용들이 있어서 간략하게 정리해본다. 

캘리포니아 대학의 강의로, 짧지만, 매니지먼트에 대해서 일목 요연하게 잘 정리를 해놨다.


일반적으로 회사에서 사람이 떠나는 이유는?

설문 조사 결과, 여러가지 이유를 대기는 하지만, 대부분의 이유중 상당 부분이  "Boss" 즉 상사 때문이라는 결과가 있다. 

아래로는 직원을 챙기고, 위로는 임원을 대해야 하는 관리자에게 무슨 일이 있길래, 이 "관리자" 때문에 사람이 떠날까?

이 강의에서는 관리자의 역할과 책임, 그리고 필요한 역량등에 대해서 다루고 있다.


매니져가 항상 집중해야 하는 분야는?





첫번째로, 항상 고객을 만족 시켜야 한다. 고객은 일반 End Customer가 될 수 도 있지만, 사내의 부하 직원, 또는 매니져의 상사가 될 수 도 있다. 고객의 정의는 "나로 부터 서비스를 받고 가치를 창출하는 사람"으로. 나와 일로써 유관된 사람이면 대부분 고객으로 정의할 수 있다.


두번째로, 다른 사람을 리딩해야 한다. 관리를 하는 것이 기본적인 역할이라고 하면 관리란 사람을 Enforce하고, 시키고 강제하면서 push하는데 반해, 좋은 형태의 매니져는 리더쉽을 가지고 있는 리더형으로 enforce/push 보다는 사람들에게 영향을 주고, 같이 가고자 하는 방향으로 Pulling 는 역할을 한다.


세번째로, 지속적으로 팀을 improvement 시킨다. Improvement 계획을 세우고, 계획을 실행하면서 모니터링 하며, 계획이 벗어날 경우 그 이유를 찾고 이에 대한 대처 방안을 찾아야 한다. 사실 가장 기본적인 관리자의 역할이지만 이게 제대로 작동하지 않는 경우가 많은것 같다. 실제로 어떤 일이 주어졌을 때, 계획을 세우기 보다는 주목구구로 하는 경우가 많고, 일 중간중간에 제대로된 체크를 하지 않아서 관리가 망가지는 것이 아닐까?


네번째로, Integrity (청렴성 이라고 하나??). 도덕적으로 청렴해야 하며, 옳은 일을 옳은 방법으로 해나가야 한다.


다섯번째로, 다양한 성별이나 인종,국가와 문화에 관계 없이 다양성을 인정하면서 일해야 한다. 예전에는 글로 읽을때 확 와닿지는 않았는데, 젊음 친구들, 결혼한 사람, 신혼 등등 다양한 상태의 직원들을 관리하려면 이를 인정하는 기반에 관리를 해야 한다.


여섯번째로, 전염병이나 정치적인 이슈와 같은 주위 환경을 신경써야 한다. 조류독감이나 메르스같은 질병이나, 선거등 여러가지 이슈 상황에서 팀이 최적의 업무를 할 수 있는 형태로 팀을 운영해야 한다.



아키텍트에서 메니져로...

사는 이야기 | 2011.07.22 15:30 | Posted by 조대협
처음에는 프로그래밍이 좋아서 개발자로 시작을 했었고, 나름 벤쳐에서 영업도 해봤고
CTO도 해보고, 프리도 해보고, 그러다가 외국회사에서 엔지니어,컨설턴트,프리세일즈를 거쳐서 아키텍트로 일을 하다가 지금은 프로젝트 메니져를 하고 있습니다.
구축 프로젝트라기 보다는 사업을 만들고 구축까지 End 2 End를 책임지는 과정인데..
확실히 메니져에 입장이 되보니 생각할것이 훨씬 많아지는 것 같습니다.
그 중에서 가장 중요한 것은 개발팀과 사업부의 중간에서 사업의 당위성을 설득하고 기술과 비지니스 중간의 브릿지 역할을 하는 일입니다. 예전에 프리세일즈 경험이 있어서 요즘 들어 큰 도움이 되고 있습니다.
 가장 중요한 것은 비지니스나 사업부 그리고 Executive는 개발이 어쩌고 저쩌고, 기술이 어쨌다는 것이 아니라..
이 기술은 애플이 쓴 기술, 아니면 오라클 제품.. 그리고 얼마... 구축 기간은 얼마... 이걸 썼을 때 서비스 밸류의 차이는 무엇
등등이 Summary 형태로 1~3페이지내에 정리가 되어야 합니다. 물론 뒤에 백 데이타로 50장의 문서가 붙어야 합니다.
 사업부의 사업 계획은 당장 매출과 연결이 되고 Time to market과 ROI가 중요하기 때문에 예측 가능한 수치를 산정하는 것이 중요합니다. Forecast라고도 하는데, 개발 비용에 대해서 남는 것은 문제가 안되지만 모자라는 것은 항상 문제가 됩니다.
 이런 입장에서 제가 할 수 있는 부분은 이 과정에 대해서 밸런싱을 절묘하게 조정하는 것인데.. 머리가 아프네요... 비지니스 요건이 시간이 다르게 변하고, 위의 층층층을 설득하기 위해서 비젼을 관통 시키는 과정에 많은 리소스를 사용하고 있습니다. 전형적인 Business making (Cooking) 과정입니다.
 거기에 반 아키텍트 역할도 하고 있으니 오버로드가 이만 저만이 아닙니다.
그래도 예전 금융권 프로젝트할때 몇달을 밤샜던것에 비하면 괜찮은데.. 차라리 몸이 피곤한게 났겠다는 생각도 듭니다. 요즘 거의 좀비 모드 입니다.
 그래도 몇년 뒤면 또 이 경험들이 갚진 경험이 되서 조금더 제 포지션을 올려주지 않을까 기대해봅니다.
거의 한달만에 포스팅이라서.. 말이 두서가 없네요..

'사는 이야기' 카테고리의 다른 글

블로그 50만 돌파  (0) 2013.03.14
삶의 가치와 휴식에 대한 글 하나..  (2) 2011.07.25
아키텍트에서 메니져로...  (2) 2011.07.22
또 회사를 옮깁니다.  (10) 2011.07.03
메니져의 역할과 필요성  (1) 2011.05.30
다시 돌아보는 MS  (2) 2011.04.14

또 회사를 옮깁니다.

사는 이야기 | 2011.07.03 21:37 | Posted by 조대협

Microsoft에 근무한지 약 1년이 좀 지났는데, 기대하지 않던 기회가 와서 회사를 다시 한번 옮기게 되었습니다.
좋은 패키지 제안 해주신 모社의 존경하는 임원분께 진심으로 죄송하게 생각합니다. 블로그를 통해서 다시 한번 감사드리고, 어떤 형태로든지 함께 일할 수 있는 기회가 오기를 기대해 봅니다.
Microsoft의 지난 1년은 저에게 상당히 의미가 있었던 한해였습니다.
먼저 Java/Unix/Open source 기반의 제 기술 Background를 MS 진영의 기술까지 확장할 수 있었으며, 기술에 대한 편견을 버리고 모든 기술에 대해서 동등하게 바라볼 수 있는 식견을 가질 수 있었습니다. 아울러서 주로 임원 관련 미팅등을 통해서 전통적인 기술 지향적인 사고에서 비지니스를 바라볼 수 있는 능력과 식견을 닦을 수 있었습니다.
Microsoft에 와서 교육도 정말 많이 갔었는데, 갈때 마다 감동하고 놀라웠던 순간이었던 것 같습니다.
왜? 아직도 MS가 대단한 회사인지를 체험할 수 있었던 기회라고 할까요? 여러 Vendor  생활을 해왔지만, 이처럼 직원들에게 투자를 많이하고, 기술에 열정적인 회사는 처음 경험해보았습니다.
이런 여러가지 이유때문에 사실 Microsoft를 떠나는 결정을 하는게 쉽지 않았습니다. 사실 저한테 제일 잘 맞는 회사 스타일이었거든요.
그럼에도 불구하고, 좋은 Offer와 함께, 클라우드라는 도전적인 과제를 주신 K팀장님과, K수석님께 감사드립니다.
옮긴지. 벌써 2주가 지났는데.. 바쁜 일상 속에 오늘에야 글을 올립니다.
제 Role도 지난주에나 결정이 났고, 조만간에 다시 발표되겠지요.
이번에는 기술 아키텍트 보다는 메니져에 가깝습니다. 6개 정도의 개발팀을 이끌어야 하고, 개발 과제를 받아서 진행하는 팀에서 부터, 과제 제안에서 사업 승인까지 받아야 하는 일들도 있어서, 또 다른 경험을 하게 될것 같습니다.
항상 Role이 바꾸면 시행 착오도 많고, 스트레스도 엄청납니다만, 지나고 나면 그 경험이 다음 먹거리를 제공해주더군요.

아직 새로운 직장과 Role에 적응하느냐고, 제 스타일이 Work & Life Balance를 찾아가지 못하고 있습니다만, 조만간에 이도 해결해야 할 과제 입니다. 거의 매일 음주에, 담배 한갑과 커피 그리고 야근에 찌들어 살았는데.. 2주 지내고 보니 생산성은 오히려 낮더군요.... Relationship buiding을 위해서 음주를 많이 했는데.. 이 역시 다른 방법을 찾아보는게 좋겠습니다.

어설픈 메니져 역할 (기존의 단순한 프로젝트 PM이나 PL이 아니라)을 하다보니, 사람 찾는 것이나, 사람에 대한 능력을 평가하고 어느쪽에 투입할 것인가도.. 새로운 과제 같습니다.

혹시 주변에 좋은 분들 있으면 많이들 소개해주세요. :)
앞으로 몇년 후가 될지 모르겠습니다만, 다음 글에도, 좋은 회사, 좋은 팀이었더란 글을 남기고 싶습니다.

그동안 도와주신분들 감사드립니다.

아울러, 이 회사 전에 다른 Offer를 주신 P 상무님께도 진심으로 감사드립니다. 언젠가는 꼭 한번 일해보고 싶습니다.

평가의 방법

IT 이야기/IT와 사람 | 2007.08.21 18:46 | Posted by 조대협

오늘 인턴 사원 평가를 했다.
예전 팀장 시절에는 체계가 없어서 제대로된 평가를 한적이 없었는데.
오늘은 인턴사원이지만 평가를 하면서 시니어로써의 무게를 느껴봤다.

하나 얻은 교훈은 "피드백을 할때, 좋은 것을 80%, 나쁜것을 20%" 이야기 하라는 것이다.

맞는말인지, 의미는 잘 모르겠지만, 예전에 내가 평가를 받을때의 느낌을 생각해보면 맞는 말 같다. 사실 피드백에서 나쁜점들이 50%이상 나온다면, 이미 그 사람은 회사에서 존재하기 어려운 사람이 아닐까?
 '칭찬은 고래도 춤추게 한다'고, 업적을 찬양해서 일할 수 있는 동기를 부여하고, 부족한점은 메꿔 나가게 하는것이 메니져로써의 역할이 아닐까?

'IT 이야기 > IT와 사람' 카테고리의 다른 글

프로젝트를 가장 쉽게 망치는 방법  (0) 2008.07.14
이런 오픈소스 라이센스 정책이 있었으면 좋겠다..  (2) 2008.06.23
HP 비리...  (0) 2008.02.04
깨진 창문 이론  (1) 2007.10.30
프로와 아마추어의 차이  (2) 2007.09.06
평가의 방법  (1) 2007.08.21