전산이야기

작년 부터 2개 업체와 각각 솔루션 구축 프로젝트를 하고 있다. 기본적으로 패키지 형태이지만 상당수는 우리 회사에 맞춰서 커스터마이징을 하고 있다. 

예전에도 느꼈지만 외주 프로젝트 관리는 어려운 점이 많다. 2개 업체 각각을 A, B라고 하고 해당 업체와 프로젝트 진행하면서 느낀 문제점을 기록 해 본다.

(물론 우리 회사 자체적인 문제점도 많이 있지만 일단 이는 생략 한다)


(1) A 업체

  1. 지연된 납기

개별 이슈에 대하여 약속한 기일 내에 제대로 맞춰 준 적이 거의 없다. 하나의 이슈가 지연 되면 순차적으로 그 뒤의 이슈들도 계속 밀려서 결국 나중에는 전체 프로젝트 지연을 초래 한다. 결과적으로 4월에 끝나야 할 프로젝트가 6월 현재 아직도 끝나지 않았고 이번 달 말까지도 끝날 수 있을 지 모르겠다. 일정준수의 의지가 없어 보이기 까지 한다. 맨날 죄송하다는 소리만 하고 약속을 지키지 않아 신뢰가 무너진 상태이다. 

  2. 무리한 동시 진행

해당 업체는 작년에 비슷한 시기에 동시 다발적으로 6개 업체와 계약을 맺고 프로젝트를 진행 했다. 이것이 결국 납기지연의 원인이 됐다. 욕심 부려서 수주한 프로젝트들이 여기저기 문제가 생기자 제한된 리소스로 제대로 일정을 소화 할 수 없었을 것이다.

  3. 소프트웨어 품질 문제

개발자가 제대로 테스트를 하지 않고 검수 요청을 하거나, 이미 가동 중인 프로그램 상에서도 지속적인 오류가 발생 했다.

개발자가 원래 테스트를 제대로 안 하는 스타일 이거나 무리한 동시 진행으로 인해 제대로 테스트 할 수 없는 상황 이거나 둘 중 하나가 원인으로 보인다. 어쨋든 테스트도 제대로 하지 않은 프로그램을 검수 해달라고 요청 하는 것 자체가  문제다.


(2) B 업체

  1. 도메인 전문성 부족

이전에 우리 회사와 같은 업종의 레퍼런스가 있다고 하여 도메인 특성을 잘 이해할 것으로 기대 했으나 예상 밖으로 너무나 몰라서 이를 이해 시키고 솔루션에 반영 하기까지 상당한 시간이 소요 되었다.

  2. 리소스 부족

사장을 포함하여 전체 인원이 3명, 그나마 한명은 단기 계약이고 정식 직원도 경력이 1년 정도 되는 열악한 리소스다 보니 전문성, 생산성을 기대하기 어려운 상황 이었다. 그러다 보니 단일 프로그램 하나를 4개월 동안 계속해서 만들고 있는 수준.

향후 프로젝트 완료 후 유지보수 지원이 제대로 될 수 없는 구조 이다.

  3. 시행착오 방법론

프로젝트 솔루션의 설계, 구축을 주관하고 있는 사장이 솔루션에 대하여 완전한 이해를 하지 못하고 시행착오 적으로 계속적으로 의사결정이 번복 되다보니 잦은 설계 변경과 이로 인한 오류발생과 소스 수정등이 지속적으로 발생하고 있다.

이는 전체적인 일정 지연과 이미 완료된 테스트를 또 다시 해야 하는 문제가 생긴다.

  4. 소프트웨어 품질 문제

앞서 A 업체의 품질 문제를 언급 한 바 있지만, B 업체는 이 보다 훨씬 심하다. 정말 맛 볼 수 있는 모든 오류를 다 경험 하는것 같다. 최초로 만든 프로그램은 기업용 프로그램이 아니라 대학교 전산실습 시간에 테스트용으로 만든 프로그램 수준 이었다. 안정성 결여, 기본적인 이벤트 전후 상태 체크, 메시지 처리, 동시성 문제등 어느 하나 제대로 된 것이 없었다. 


프로젝트를 추진 할 때 업체의 선정은 정말로 중요 하다. 일단 계약이 되고 프로젝트 킥오프가 되면 갑을 관계가 프로젝트 기간 동안에 바뀌기 때문이다. 우리가 돈을 주고 있지만 우리 맘대로 못하는 상황이다. 따라서 프로젝트 시작 전에 사전평가를 철저히 해서 '가격'으로만 판단 하는 우를 범해서는 안된다. 

그러나 여전히 제일 싼 업체에 일을 맡기는 관행이 있고 또는 의사결정을 할 수 있는 위치의 사람이 알고 있는 업체에 주어 지는 것이 현실이다. 하지만 대부분 프로젝트가 시작되고 문제가 생겨도 문제 해결은 실무 담당자의 손에 넘어가고 결정권자는 실질적인 도움을 주지 못한다. 

앞으로는 이러한 전철을 밟지 않도록, 외주 업체 선정에 대한 정확한 사내 프로세스를 만들어 놓고 이를 준수 하는 방식으로 해야 하지 않을까 한다.

Comment +0


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

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

가. 개인에 대한 습관

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

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

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

나. 대인관계의 습관

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

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

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

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

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

Comment +0

"기술관리자는 기술이 아니라 사람을 다룬다"

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

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

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

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

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

기술자와 기술관리자는 다르다. 기술관리자는 기술이 아니라 사람을 다룬다. 그래서 기술자 시절에 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

Comment +0

컨설턴트 리더쉽

관리2010.03.30 19:43

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

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

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

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

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

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

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

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

9. 당신이 제안하는 것을 상대방이 기꺼이 하도록 만들어라.

Comment +0