반응형

* 2004.9.10 컨설턴트 교육자료 정리
(부재 : 성공적인 컨설턴트/프로젝트 관리자)

# 추천서 : 성공하는 사람의 7가지 습관

가. 개인에 대한 습관

1. 주도적이 되자 
  - 조셉올리키 - MRP원조자, 우연한기회에 엄청난 study -> MRP 개발
  - 일에 대한 재미
  - 남보다 먼저 하자(전문가) 
  - 개인의 지식의 차이가 아닌 회사의 지식base를 근거로 고객요구 해소

2. 목표를 정하고 일하라
  - 개인의 비전(장기적)을 뚜렷히 : 승부를 걸어 볼것을 찾아라
  - 고객은 나의 거울(고객의 평가는 정확하다) : 신뢰구축
  - 지시를 받아서 하면 전문가가 아니다.

3. 우선순위
  - 습관 / 중요성
  - 중요한 것과 안 중요한 것을 판단하는 능력
  - 고객와의 마찰요소(서로 상이한 요구 및 우선순위 판단) : 스스로 문제 해결하는 것이 중요치 않음.
     모든 수단(딴 사람)을 통해 신속하고 정확하게 해결하는 것이 중요.

나. 대인관계의 습관

4. 윈윈(win-win) 정책
  - 나와 고객이 모두 성공 -> 서로 상충될 가능성(서로의 win이 부딪힘) -> 미해결시 신뢰성 상실
     -> 고객의 win factor가 무엇이며 어떻게 도울 수 있을까(사소한 것 부터 해결)
     -> 상충되지 않는 factor를 찾아서 해결(어차피 상충되는 것은 해결이 힘드므로)

5. 경청
  - 고객의 말을 끝까지 듣는다 (알아도 아는 척 하지 말고, 틀렸다고 구박하지 않아야 한다) -> 진지한 대화

6. 시너지를 내자
  - 같이 해서 문제해결 능력 강화
  - 혼자서 알고 해결하지 말라(기술 상호 공개/교환) : 같은 팀끼리, 고객과 나

7. 심신단련
  - 운동, 독서

※ 쉬운 프로젝트는 없다. 모두 risk 가 존재 한다.
    -> 최악의 상황을 가정, 예측 -> 해결방안 모색(미리 대처)

반응형
저작자표시 비영리 변경금지

'관리' 카테고리의 다른 글

외주 프로젝트 관리  (0) 2015.06.05
"기술관리자는 기술이 아니라 사람을 다룬다"  (0) 2010.03.30
컨설턴트 리더쉽  (0) 2010.03.30
반응형
"기술관리자는 기술이 아니라 사람을 다룬다"

훌륭한 관리를 한번도 받아보지 못한 사람이 훌륭한 관리자가 될 수 있을까? 글쎄, 아마도 훌륭한 관리자가 되기는 어려울 것이다. 마치 어린 시절에 사랑을 받고 자라지 못한 사람이 성인이 되어서 제대로 사랑을 하기 힘든 것처럼.

그것은 심리학을 통해 검증된 통계적 사실이다. 왜 그럴까? 아는 것이 그것 밖에는 없기 때문이다. 맞아본 사람이 때릴 줄 안다. 학대를 받아본 사람이 학대할 줄 안다. 간혹 예외가 있을 뿐이다.

안타까운 사실은, 조직 생활에서도 이와 같은 원리가 그대로 적용된다는 사실이다. 관리 업무는 눈에 잘 보이지 않는다. 좋은 관리, 나쁜 관리는 그 행위 자체보다는 결과로서 판단된다. 또한 관리 활동의 대부분은 소프트 스킬에 속하므로, 학습에 의해 습득 가능한 하드 스킬과는 달리 역량을 키우는 것이 쉽지 않다.

그런데 현실을 보면, 조직(회사)은 아무 준비도 없이 기술자를 관리자로 만들어 버린다. 좋은 관리를 받아본 적이 없고, 그렇다고 해서 딱히 관리 교육을 받은 적도 없는데(물론 교육을 받더라도 효과가 별로 없지만), 어느 날 갑자기 조직은 팀 또는 프로젝트 관리를 기술자에게 맡겨 버린다.

■기술자와 기술관리자는 다르다

기술자와 기술관리자는 다르다. 기술관리자는 기술이 아니라 사람을 다룬다. 그래서 기술자 시절에 PC를 붙잡고 씨름하던 것과는 완전히 다른 관점과 방식과 필요하다. 하지만 좋은 관리를 받아 본 적이 없고 더군다나 준비도 안된 상태에서 좋은 관리자가 되는 것은 거의 불가능하다. 어쩔 줄 몰라 하다가, 자기가 정말 닮고 싶지 않았던 그런 관리자와 유사한 행동을 반복하게 된다.

한때 기술자였으나 실패한 관리자의 사례를 하나 살펴보자. 실제 사례를 바탕으로 재구성해 보았다.

개발자 K는 뛰어난 개발자였다. 그는 개발 능력이 뛰어났기에 조직에서 인정을 받고 있었다. 대개의 조직은 일정 경력을 갖춘 우수한 개발자에게 관리자를 맡기고 싶어한다. 그 뛰어난 능력을 단지 개발에만 쏟지 말고 여러 개발자들을 관리하는데 써달라는 것이다.

결국 개발자 K는 조직의 갑작스런 필요에 의해 관리자 역할을 맡게 되었다. 하지만 그는 관리를 잘 하지 못했다. 아니, 잘하지 못한 정도가 아니라 처참할 정도로 못했다. 그가 맡은 프로젝트의 팀원들이 급기야는 (K의 관리를 더 이상 받을 수 없다고) 상층부에 집단으로 항의를 함으로써 그는 결국 해고되고 말았다. 개발자에서 관리자가 된 K는 도대체 어떤 관리를 행한 것일까?

그는 부적절한 인력 배치를 했을 뿐만 아니라, 팀원들에게 업무를 맡긴 후 결과가 나올 때까지 기다려주는 인내심이 없었다. 매일매일 점검(을 빙자한 간섭)을 했으며, 자신이 잘 알고 있는 미시적인 내용(하지만 별로 중요하지 않은 것)에 대해 팀원과 불필요한 논쟁을 하기도 했다.

업무 지시를 명확하게 하지 않았으면서도 업무 성과가 마음에 안 든다며 팀원들을 질책하기도 했고, 기술이 부족한 팀원에게 일을 맡기면서도 해당 기술을 습득할 수 있는 여건을 마련해 주지 않았다. 팀장으로서 팀원들의 고과를 매겨야 하는 상황에서는, 제대로 상담조차 하지 않은 상태에서 고과를 확정시켜 팀원들의 분노를 유발하기도 했다.

그가 맡은 프로젝트는 말도 안 되는 데드라인에 맞추어야 하는 일명 죽음의행진(Death March) 프로젝트였는데, 팀원들에게 야근이나 휴일 근무를 은근히 종용하곤 했다. 또한 자잘한 코딩 기법이나 검증되지 않은 새로운 방법론에 몰두한 나머지, 자신이 보기에 미진하게 생각되는(하지만 사실은 대세에 전혀 영향을 미치지 않는) 사소한 일들을 혼자서 모두 처리하려고 했다.

그리고 그는 회사 돈이 아닌 개인 돈으로 밥 한번 산 적이 없었다. 인간적인 매력조차 보이지 못한 것이다. 하지만 그가 개발자였을 때는 그렇지 않았다. 관리의 스트레스가 그를 더욱 메마른 인간으로 만든 것이다.

그러한 결과로 팀원들은 그를 단지 직위를 가진 사람으로 인정할 뿐, 리더나 코치로 인정하지 않았다. 결국 그는 팀 전체를 궤멸 상태에 빠지게 만들었다. 동기부여가 없는 지속적인 초과근무를 통해서 팀 전체가 모든 에너지를 소모하고, 결국 일에 대한 의욕을 완전히 상실하게 되었으며, 따라서 프로젝트 목표를 달성할 가능성이 희박해졌다. 마침내, 참다 못한 팀원들이 궐기했고 K는 해고되고 만 것이다.

실제로 현업에서는, 그런 식으로 알게 모르게 해고되는 관리자들이 참 많다. 무엇이 잘못된 것일까?

일단 표면적으로는 올바른 관리를 행하지 못한 K에게 책임이 있다고 할 것이다. 하지만 본질적으로는 K를 관리자로 선임한 조직에게도 상당한 책임이 있다고 볼 수 있다.

유능한 개발자였던 K에게 그가 잘 수행할 수 없는 관리자 역할을 맡기고, 결국 그를 해고한 것은 바로 조직이다. 결국 조직도 K도 모두 큰 손실을 보았다. 만일 K가 개발자로 계속 남았더라면 어땠을까? 그는 계속, 조직에 필요한 유능한 개발자로서 일할 수 있었을 것이다.

기술자와 기술관리자 역할은 조직의 갑작스런 필요에 의해 무리하게 맡겨져서는 안되며, 개인의 성향과 자질에 맞추어 맡겨져야 한다. 또한 준비과정과 교육을 통해 단계적 시나리오에 따라 맡겨져야 한다. 기술자와 기술관리자를 구분하는 간단한 몇 가지 질문을 살펴보자.

- 기술자: 더 많은 기술적 작업과 도전을 다루기를 원하는가? 사람 문제보다 기술 문제를 해결하는데 더 많은 관심이 있고 실제로 마음이 편한가?

- 기술관리자: 사람들에게 코칭과 조언을 해주기를 좋아하는가? 업무를 지시하고 피드백을 주는 법을 배우고, 필요하다면 하기 힘든 대화도 기꺼이 나누겠는가?

한국의 많은 조직들은, 유능한 기술자에게 갑작스레 관리를 맡기는 경향이 있다. 물론 유능한 기술자였다가 나중에 더 유능한 관리자가 된 사람들도 있다. 중요한 점은, 각각의 사람에 맞는 적합한 역할을 부여하고 그의 역량을 최대한 이끌어 냄으로써 조직의 생산성 향상 및 개인의 발전을 가져오는 것이다.

특정 개인이 기술관리자 역할에 적합한지 아닌지, 조직 또는 개인 스스로 판단하기 어려운 경우가 종종 있다. 그럴 경우에는 관리자 업무의 적성 판단을 위한 허니문 기간을 갖는 것이 좋다. 초급관리자로서 적은 수의 팀원 관리를 맡고, 일정 기간 동안 기술 업무와 관리 업무를 병행하면서 해당 개인 스스로 자신의 적성을 파악하고, 조직은 관리 성과를 냉정하게 파악하는 것이다. 그 후 해당 개인의 커리어 패스를 결정하면 된다.

관리자를 잘 선임하는 것은 몹시 중요한 일이다. 많은 사람들이 관리의 이름을 빙자한 모욕의 느낌을 경험하곤 한다. 관리에 실패하면 엄청난 비용을 지불한다. 팀원들의 신뢰를 잃고, 결국 생산성의 추락을 경험하게 되고, 프로젝트 목표 달성은 불가능해 진다.

1년이라는 프로젝트 기간 동안 프로젝트매니저가 3번이나 해고된 프로젝트를 본 적이 있다. 그런 상황에서 사실 진짜로 해고되어야 할 사람은 프로젝트매니저를 선임한 경영진이 아닐까?

매니지먼트의 핵심은 재능을 배치하는 기술이다. 조직의 경영진은 기술자와 기술관리자의 차이를 명확히 인식하고, 적합한 적성과 자질을 가진 사람이 관리자로 선임될 수 있도록 최선을 다해야 한다. 적절한 관리자를 선임하는 것이야말로, 그 이후에 발생하는 어떤 문제 해결보다도 가장 효과적이고 본질적인 문제 해결책인 것이다. @

출처: http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039169207
반응형
저작자표시 비영리 변경금지

'관리' 카테고리의 다른 글

외주 프로젝트 관리  (0) 2015.06.05
성공적인 컨설턴트/프로젝트 관리자  (0) 2010.03.30
컨설턴트 리더쉽  (0) 2010.03.30
반응형

1. 칭찬과 감사의 말로 시작하라.

2. 잘못을 간접적으로 알게 하라.

3. 상대방을 비평하기 전에 자신의 잘못을 먼저 인정하라.

4. 직접적으로 명령하지 말고 요청하라.

5. 상대방의 체면을 세워주워라.

6. 아주 작은 진전에도 칭찬을 아끼지 말라. 또한, 진전이 있을때마다 칭찬을 해주어라.
   동의는 진심으로, 칭찬은 아낌없이 하라.

7. 상대방에게 훌륭한 명성을 갖도록 해주어라.

8. 격려해 주어라, 잘못은 쉽게 고칠 수 있다고 느끼게 하라.

9. 당신이 제안하는 것을 상대방이 기꺼이 하도록 만들어라.
반응형
저작자표시 비영리 변경금지

'관리' 카테고리의 다른 글

외주 프로젝트 관리  (0) 2015.06.05
성공적인 컨설턴트/프로젝트 관리자  (0) 2010.03.30
"기술관리자는 기술이 아니라 사람을 다룬다"  (0) 2010.03.30
반응형

시내·인터넷전화 가입 여부에 상관없이 SK브로드밴드 가입자 간 유선통화는 모두 무료화 한다고 합니다.

기사 : SK브로드, 시내·인터넷전화 망내통화 '전면 무료화'
반응형
저작자표시 비영리 변경금지

'IT정보' 카테고리의 다른 글

USN 기술 동향  (0) 2010.04.09
XP Home 에서 IIS 설치 하기  (0) 2010.04.06
현재의 모바일 웹, 왑(WAP)보다 못해  (0) 2010.03.28
Windows7의 XP Mode CPU 제한조건 해제  (0) 2010.03.27
모니터 - 디지털/아날로그  (0) 2010.03.24

+ Recent posts

티스토리툴바