세상을 놀라게 하자!

기술관리 본문

Software construction/Agile development

기술관리

유진호 2010. 4. 18. 15:14

서론

 최근 연구결과에 의하면 실제 진행되는 정보기술 프로젝트들의 32%만이 성공( 2009 Standish group CHAOS 2009 report ) 한다고 합니다. 그럼 어떻게 32%는 이룩할 수 있었을까요? 어떤 공통된 완벽한 답은 없습니다. 각자의 길을 잘 수행한것일뿐입니다.

실제 일반적인 관리자 육성 교육 몇번 받았다고 해서 그런 사람들이 진행하는 프로젝트가 성공하지도 않습니다. 그 자리에 서 있는 사람에 따라 달라진다는 거지요. 그럼 뭐가 달라서 어떤 관리자들은 성공하고 어떤 이들은 실패할까요?이를 위해 두가지를 생각해야 합니다. 첫번째는 기술관리자가 생각하는 성공의 정의이고 두번째는 구성원들의 성향입니다.

 첫번째, 기술관리자의 성공의 가장 큰성공은 무엇일까요? 자신이 관리하는 프로젝트가 성공하는걸까요? 프로젝트를 성공한 다음에 팀이 해체되거나 조직이 사라지는 경우도 있는데 이것은 성공한 걸까요? 게다가 프로젝트의 성격을 고려해야 합니다. 만약 플랫폼 설계라면 이 플랫폼의 사용빈도가 성공한거겠고 응용프로그램이면 실제 사용자들의 반응이 좋고시장점유율이 올라가면 성공일 수 있겠고요.이런 다양한 변수가 프로젝트 성공의 정의가 힘들지요. 하지만 모든 경우에 고객은 '완성된 결과'에만 관심이 있습니다. 어떤 방식을 사용하든 그것은 관심 밖입니다.


 두 번째 구성원들의 성향이 중요합니다. 문제를 보는 시각/문제의 속성/뜻하지 않은 일에대한 태도등에 따라 완전히 다른 길로 가게 됩니다. 어떤 개발자들 집단은 귀찮다고만 하고 게으름 피우다가 한꺼번에 일처리하길 좋아합니다. 어떤사람들은 또 한단계 한단계 밟아가길 좋아합니다. 이에 따라서 당연히 관리방법이 달라집니다.

그러므로 반드시 먼저 해야하는 일은 '현재상황 파악'입니다. 내가 속한 팀은 어떤 팀인가? 우리가 하는 일은 어떤일인가? 여기서 모든 것은 시작합니다. 전문가 일수록 상황을 알아보려 하고 초보자일수록 진단을 하려합니다.



첫 시작 : 누구랑 일하게 되는가?

자신이 기술관리자 위치에 부임이 되게 되었다면 처음 어떻게 해야 할까요? 그동안 제가 모시던 분들은 대부분 팀원들과 1:1로 만남을 가졌었습니다. 저도 이 방식이 굉장히 좋았었습니다. 그 때 아래의 질문을 해보시길 권합니다. 내부 승진자라면 스스로에게 물어보고 다른 팀원들의 답과 비교하시길 권합니다. 외부에서 영입되어 오신 분이라면 이를 통해 지금 회사 분위기를 알 수 있을 것입니다.

  • 과거 팀 리더가 바뀌었을 때가 있었는가? 그 때 어떤 일이 일어났었는가?

  • 팀에 새롭게 사람이 들어왔을 때 어떤 일이 일어났었는가?

  • 구성원이 팀을 떠나게 될 때 어떤 일이 일어났었는가?

  • 위기로 인해 팀 내의 사회적 관계가 바뀌었었나? 어떤 일이 일어났었나?

    그 이외에 팀원들에대해 MBTI나 Kai같은 전문적인 특성 검사를 같이 할 수 있으면 좋은 시작이 될 것입니다. 만약 이를 팀원들이 그리 좋아하지 않는다면 팀원들의 성향을 유추하셔야 하는데 훈련이 되지 않는다면 쉽지 않을 것입니다.   이 과정이 끝났다면 일과 그에 필요한 품성 / 능력별로 제대로 배치가 되었는지 고민할 수 있습니다. 하지만 이것도 시작할 수 있는 기본 자료일 뿐입니다.



팀 을 조직하는 방식

  제럴드 와인버그의 '프로그래밍 심리학'에 의하면 팀을 조직하는 방식에는 1) 목표시스템의 구조, 2) 팀의 구성에 따라 나뉜다 합니다. 예컨데 팀 안에 숙련된 프로그래머가 한 사람있고 나머지는 약간 못미치는 사람들이 라고 합시다. 그리고 이들이 만들어야 하는 시스템은 큰 메인 프로그램들 아래 자잘한 서브루틴들이 있는 것이라고 하지요. 그렇다면 팀은 이렇게 일을 처리할 것입니다. 숙련된 프로그래머가 팀의 리더가 되어 주요 부분을 직접 만들고 나머지 일들을 세심하게 계산해서 서브루틴들을 분리할 것입니다. 경력이 비슷한 사람들이 주로 있다면 이 시스템을 크게 몇 단계로 나눠서 따로 만들고 나중에 붙이는 방식을 택할 것입니다. 단, 아주 이상적인 경우일 때 이럴 것입니다.


  팀원내의 지위는 언제 확립이 될까요? 바로 누가 누구의 작업을 비판하는가 입니다. 모든 엔지니어들이 자신들의 작업에 대해 상호 평가를 하면서 일이 진행된다면 조직의 계층성이 지나치게 커지는 것을 막을 수 있고 민주적인 분위기를 유지할 수 있습니다. 이 민주적인 분위기가 굉장히 중요합니다. 그것은 팀이 위기에 '민첩하게'대응할 수 있는 밑거름이 되기 때문입니다. 실제 제럴드 와인버그는 이런 이유로 민주적인 조직을 만드는 것이 프로그래밍 조직에 더 낫다고 권장했습니다.


  또 지나치게 어려운 일을 맡은 사람들이 쉬운일을 맡은 사람보다 더 높은 지위를 가질 수 있습니다. 비 이성적인 부분이 있기 때문에 이 부분을 정말 주의해서 조직해야 합니다. 이른바 슈퍼사원이 등장하는 것으 막으라는 말입니다. 실제 슈퍼사원들이 모든 일을 자신만 아는 블랙홀로 만드는 경우가 많아서 그 사람만 일하다 방전되거나 시스템을 망가뜨리게 된다는  잭 웰치의 조언을 잊지마시기 바랍니다. ( 비록 잭이 스스로 슈퍼사원급이었지만. )




목표의 수립과 합의

  제럴드 와인버그는 이렇게 이야기 합니다. "어떤 팀원이 사소한 업무를 할당받아서 감정이 상한다면 팀 전체에 매우 나쁜 영향을 줄 수 있다" ( '프로그래밍 심리학'에서 인용 ) 사회심리학적으로 한 명 이상의 구성원이 그룹의 목표를 공유하지 못하면 그룹 전체의 업무 효율에 악영향을 미친다는 사실을 증명했습니다. 내 것이 아니면 책임을 질 필요가 없기 때문입니다. 자기주도성을 부여할 수 있는 가장 큰 힘이 목표의 공유입니다. 꼭 주어진 일의 '의미'를 공유해야 합니다.  그리고 모든 목표의 지향점은 결국 ' 다른 사용자에게 서비스 제공'하는 것입니다. 다른 사소한 것들이 발목을 잡지 않게 주의해야 합니다.



리더십은 무엇인가?

  몇몇 관리자들은 지각하는 프로그래머들을 볼 때 분통이 터질 것입니다. 하지만 잊지 말아야 할것은 그들이 어제 새벽 2시까지 일을 했던 거지요. 그런 일들이 수도 없이 많습니다. 어떤 행동을 사람들이 할 때는 그만한 이유가 뭔가 있습니다. 먼저 파악하고 결정해도 늦지 않습니다.

  일반적으로 프로그래머들은 자신보다 뛰어난 프로그램 실력을 가진 사람들의 말을 주로 따릅니다. 만약 상부에 의해 '낙하산'으로 왔다면 빨리 자신이 프로그래밍 실력이 없다고 밝히는 것이 더 낫습니다. 발각되면 비웃음을 사고 아무것도 할 수 없게 될 것입니다. 이런 사람들이 제일 최악으로 치닿는 길은 팀에게 경영진의 입장을 강요하고 굴복시키는 길 뿐 일 것입니다. 문제는 이런 팀이 얼마나 형편없이 업무처리를 하는지 알아야 합니다.

  제럴드 와인버그는 가능한 프로 그래밍 팀을 '민주적'으로 이끌라고 권장합니다. 민주적인 리더쉽이 환경의 변화에 훨씬 유연하게 작용해왔기 때문입니다. 권위적인 관리자들은 이것 믿지 않지만 믿음이 아닌 사실이 그렇습니다. 스위스는 전쟁 위험이 있을 때에만 군대를 통솔할 장군을 선출한다 합니다. 그래야 매 상황마다 적절한 사람이 서 있게 되기 때문이라고 합니다.

  불행히도 그런 적절한 사람을 못 구한다면 어떨까요? 팀내에 마땅한 사람들이 없거나 인격에 문제있는 사람들 뿐이거나 결국 외부로 리더가 임명되면 그 집단은 반드시 민주주의와는 멀어지게 됩니다. 그리고 이렇게 외부에서 오게 되는 경우에 이 리더들은 팀과 팀의 목표를 좌지우지 하려는 외부 세력 사이에서 정보를 전달하는 역할을 악용하고 싶은 욕구를 가지곤합니다. 근시안적 성과주의 때문입니다. 하지만 이것이 오히려 팀의 잠재능력을 깍아 먹습니다. 팀 리더는 아래 두가지를 기억해야 한다고 제럴드 와인버그는 주장합니다.

  • 경 영자가 약속 이행을 아무리 강하게 요구한다 해도, 진정으로 원하는 것은 결과물 자체다.

  • 팀 전체가 참여하여 설정한 목표를 추구한다면 결과물을 훨씬 더 쉽게 얻을 수 있다.

    실제 사용할 수 있는 제품을 매 기간마다 제공하라는 애자일의 지침이나 다 함께 모여 목표를 공유하는 스크럼이 성공률을 비교적 높이는 비결은 여기 있습니다. 실제 조직의 에너지가 방전되는 비율도 덜합니다.




위기를 맞이 할 때

 아무리 팀원들이 목표를 잘알고 받아들이고 민주적로 운영햐도 위기는 옵니다. 제품을 성공적으로 출시했는데도 망하는 회사가 있고 매출도 성공적으로 이뤘는데도 망하는 경우가 있습니다. 심지어 내부에 배신자나 정말 맘이 상해서 여태까지 추진한 일들을 모두 날려먹고 도망가는 사람도 있을 수 있지요.


  '프로그래밍 심리학'에서 제럴드 와인버그가 분류한 것을 보면 '권위적'인팀과 '민주적'인 팀으로 팀의 성격을 나누고 있습니다. 그리고 이들이 위기를 맞았을 때 대하는 특성에 대해 쓰고 있습니다. 요약해 보면 이렇습니다.

  • 새로 사람이 들어왔을 때

    • 권위적인 팀

      • 새로 온 사람에게 호의적
      • 원 인: 리더가 구멍난 일들을 매워서 새로온 사람을 훈련할 것이기 때문에. 리더가 바빠지면 이런 역할을 못하므로 위기가 다가온다.
    • 민주적인 팀

      • 다소 냉정하고 비우호적
      • 원인:  모두가 새로온 사람을 도와서 훈련해야 하기 때문에. 하지만 비교적 빨리 처리 된다.
  • 팀원들 중 능력이 모자란 사람을 발견했을 때

    • 권위적인 팀

      • 늦게가서야 탐지될 확률이 크다.
      • 팀 원을 해고할 가능성이 높다. 하지만 이 결정도 거의 끝에 가서야 내리게 된다.
    • 민주적인 팀

      • 서로가 다른 사람의 작업을 돌아봐주게 되므로 비교적 빠르게 찾아낸다. 
      • 업 무가 자연스럽게 다른 팀원에게 넘어간다.
  • 협력하기

    • 민주적인 팀:  능력만큼이나 사람들과 어울리는 능력이 중요하다
    • 권위적인 팀:  별로 그럴 이유가 없다. 심지어는 다른 사람들과 친하게 지낸 필요가 없어서 권위적인 팀을 좋아하는 프로그래머도 있다.



   더 놀라운 것은 반사회적인 행동을 할 가능성은 훨씬 재능있고 뛰어난 사람들이라는 것입니다. 이런 사람들의 경우 조바심을 억누르지 못하는데가 다른 사람들은 그가 제시하는 종류와 의견들을 제대로 이해하거나 구현할 수 없다는 점이 문제이지요.


  위기가 많은 팀일 수록 리더쉽이 매번 바뀌고 어려운 업무일 수록 가장 효과적으로 팀을 이끌 수 있는 리더를 진정 열렬히 따르게 됩니다.  실제 사회심리학에서 조직은 아래 두가지 조직의 특성이 있다고 이야기 하고 있습니다.


  • 위기시에 비교적 강력한 리더십을 행사하려는 시도는 구성원들이 비교적 거부감 없이 쉽게 받아들인다.
  • 그 자칭 리더가 집단의 문제에 대한 효과적인 해결책을 빨리 내지 못하면 나머지 사람들은 그를 느긋하게 지켜봐 주지 못하고 금세 조바심을 낸다.


그래서 조직구성에 관한 와인버그의 조언은 이렇습니다. "너무 지배적이지도 너무 수동적이지도 않은 늘 변하는 사람을 뽑아라.", "프로그래머에게 후능한 리더를 어떻게 따라야 할 지, 스스로 집단내에에서 리더로 가장 적임자일 때 어떻게 그 기회를 잡아야 하는지를 가르쳐야 한다"


결 론 

  "우리는 어떤 시기에 누가 적합한 리더가 될지 정확히 예측할 수 없으므로, 이상적인팀은 프로그래밍 기술만큼이나 대인관계의 기술을 고려하여 구성되어야 한다"라는 제럴드 와인버그의 말은 충분히 어떤 기술 조직에서도 들어볼 만한 조언입니다. 결국 사람이 모든 것을 만들어내는 현실임에도 우리는 특정 방법론, 특정 기술만 고집하곤 합니다. 은탄환이 없다는 '맨먼스 신화'의 조언은 그래서 더욱 중요한 교훈일 것입니다.


 그럼 이 모든 것을 어떻게 시작할 수 있을까요? 제가 드리는 조언은 '회고'입니다. 일반적으로 과제가 설정되고 팀이 구성되는데 이 순간에 팀원 모두 서로를 아무도 모르는 상황입니다. 누가 누군지, 어떤식으로 일하는지, 어떤 식으로 조직을 구성하기 좋아하는지, 누가 실력이 있는지등 모르는 것 투성입니다.  심지어 몇년을 같이 일해도 피상적으로 아는 경우도 있습니다. 한 주 동안 팀이 했던 일을 서로 같이 되돌이켜 보면서 어떤 일이 있었는지를 나눠보길 원합니다. 그 안에서 지금 속한 여러분의 조직의 성취, 아픔, 장점, 약점을 파악할 수 있을 것입니다.


 파악을 먼저 해야 합니다, 지금 우리가 속한 기술조직이 어떤 상태인지. 그리고 우리에게 필요한 것이 무엇인지 하나하나 찾아보고 머리를 맞대고 찾아봐야 합니다. 그러기 위해서는 민주적인 조직 운영이 필요하고 목표를 명확하게 해야 합니다.

 사람을 생각하면 길이 보일 것입니다. 성과를 생각하면 안개속일 것이고요.    제가 알고있는 팀을 운영하는데 가장 핵심적인 조언입니다.


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

참고자료

  1. 제럴드 와인버그, '프로그래밍 심리학'
  2. 2009 Standish group CHAOS 2009 report
 
Comments