2012년 11월 5일 월요일

내가 책임지고 해보겠습니다.

우리나라 경영자들은 "내가 책임지고 해보겠습니다."라는 말을 좋아한다. 물론 책임감을 가지고 일을 추진하는 것은 좋은 일이다. 하지만 많은 경우 엄밀히 말하면 제대로 책임을 지는 것이 아니다. 결과적으로 책임을 지겠다고 말만하는 꼴이 되는 경우가 많다. 그럼에도 무모하더라도 추진력있게 밀고 나갈 사람이 인기가 많다.

경영자들이 이런 돌격형 인재를 좋아하는 이유는 여러가지가 있다. 실제 좋은 성과를 내는 경우도 많지만 소프트웨어에서는 상황이 좀 다르다. 

경영자들이 소프트웨어 개발에 대해서 잘 모르기 때문에 그냥 알아서 개발을 해주기를 원하는 경우가 많다. 또한 이런 경우 무모한 시도가 되는 경우가 많다. 

열심히 하는 것은 좋지만 무모한 것과는 다르다. 대부분의 무모한 프로젝트는 일정이 제대로 예측이 안되는 상태로 밀어 붙인다. 일정이 촉박하다는 이유로 분석, 설계 생략하고 코딩부터 진행하고, 개발 막바지까지 현재 진행률을 파악하기가 어렵다.

비즈니스를 하기에는 이렇게 열심히 일하지만 예측 불가능한 프로젝트보다는 합리적인 일정제시와 제시된 일정에 결과가 제대로 나오는 프로젝트가 더 좋다. 그래야 비즈니스도 계획한 대로 움직일 수 있다.

이렇게 무모한 프로젝트를 진행하는 개발자들은 불투명한 프로젝트 진행을 선호한다. 투명하게 프로젝트를 진행하는 것이 더 효율적이라는 것을 몰라서 그렇게 하기도 하지만, 정보와 지식을 숨길 수록 자신들의 가치가 더 올라간다고 착각을 하기도 한다.

이런 환경에서는 경영자는 Detail은 잘 모르고 개발자들을 쪼기만(일정 압박) 하고, 개발자들은 매일 야근에 내몰리다가 프로젝트 막바지에는 이런 저런 핑계를 만들어 내기 급급해진다. 물론 가끔은 일정내에 프로젝트가 끝나기도 하지만 그 과정에서 마케팅, 영업, QA와 유기적으로 협력이 잘 안되고 혼자 달려가는 프로젝트가 되곤한다. 개발자가 개발을 끝내주면 그때부터 다른 부서는 일이 시작된다. 무엇을 개발하고 있는지 제대로 파악이 안되므로 미리미리 준비를 하기도 어렵다.

물론 개발자는 열싱히 일을 했다. 비난을 들으면 억울할만하다. 물론 나는 개발자를 비난하는 것은 아니다. 이런 일이 벌어지는 근본적인 이유는 경영자들의 무모한 개발자를 선호하고 너무 압박을 하기 때문이다. 이런 일이 반복되면 개발자는 지치고 프로젝트는 지연된다. 잘못된 방향으로 달려가던 프로젝트는 커다란 매몰비용(Sunken cost)를 치뤄야 하기도 한다. 이런 상황에서는 경영자도 개발자도 선택의 여지가 별로 없다. 아무리 손해를 보더라도 경영자는 이런 무모한 프로젝트에 계속 후원을 할 수 밖에 없다. 

이 모든 부작용은 개발 문화의 부재에서 오는 것이다. 제대로 된 스펙에 의해서 합리적인 일정을 제시하고 경영자는 이를 믿어줘야 한다. 처음에는 개발자들이 역량이 부족하여 나름대로 개발자들이 제시한 일정이 좀 틀릴 수도 있지만 개발자들은 최대한 합리적인 가능한 일정을 제시해야 한다. 그런 관계가 거듭되야 개발자도 역량이 향상되고 비즈니스 일정에 맞춰서 제품을 만들어 줄 수 있다.

혹자는 현실적으로 불가능한 일이라고 한다. 항상 일정이 너무 촉박하여 경영자는 절대로 개발자들이 제시한 일정을 따를 수 없다고 한다. 그래서 무모하게 짧은 일정을 제시한다고 한다. 경영자가 그렇게 하는 이유는 무지 때문이기도 하고 개발자들이 합리적으로 일정으 제시하지 못하기 때문이기도 하다. 가끔은 경영자와 개발자의 신뢰가 무너진 경우도 있다. 그렇게 해서는 평생을 가도 무모한 프로젝트만 진행하게 된다.

그 부작용은 개발자 사기저하, 비즈니스 일정이 꼬이고, 제품의 품질이 떨어진다.개발자들은 매일 야근에 고생을 하지만 일정 지연에 자주 내몰린다.

여기서 핵심은 경영자들의 이해이다. 그리고 개발자들도 제대로 된 분석, 설계 능력을 갖춰서 합리적인 개발 계획을 제시할 수 있어야 한다. 한번에 그렇게 될 수는 없지만, 경영자와의 신뢰 하에서 개발자에게 꾸준히 투자를 해줘야 개발자들도 그렇게 할 수 있는 역량이 올라가게 된다. 

댓글 6개:

  1. @booiljung 지금도 비슷한 현상이 여기 저기서 또 일어나고 있습니다. 경영자가 기술을 어느 정도 이해하던지, 믿어주든지 해야 합니다. 이도 저도 아니면 결정을 대신해줄 CTO가 필요합니다.

    답글삭제
  2. @booiljung 나름 개발을 알고 있다고 생각하는 개발자 출신 오너도 마찬가지입니다. 자신이 마지막 개발했던 수준에 머물러 있는 경우가 많습니다. 이런 경우 더 문제 해결이 어렵습니다.

    답글삭제
  3. 기술을 알아도 일단 코딩 부터 들어가야 마음이 편한 사장님도 계시더군요.

    2년 정도 개발일을 하시다가 창업을 하셨는데

    사이트 소개서 수준의 글을 쓰시고 바로 개발에 들어가라 하시니 이걸 어찌해야 할지 모르겠습니다.

    문서? 라고 적혀 있는건 그냥 개요만 있고 이걸 개발하면서 보면서도 답이 안나오니 사장님에게 계속 물어보고 하고

    주무시기전에 생각난건지 몰라도 뜬금없는 기능 추가가 이뤄지고 되려 그걸 왜 몰랐냐는 듯이 나무라기도 합니다.


    레드마인 이나 SVN 처럼 프로젝트 진행을 위한걸 쓴다고 하면 마지못해 수긍하시지만 정작 저 혼자 쓰고 있고요.


    고민이 이만저만이 아니네요

    답글삭제
  4. 제가 보기엔 이건 프로젝트 관리의 문제라고 생각합니다. 맨 마지막의 분석/설계 이야기는 왜 나오는지 조금 의문이 드네요

    답글삭제
  5. 일반적인 경우 분석설계가 제대로 되지 않은 상황에서 프로젝트 관리는 할게 별로 없습니다. 일정 예측도 부정확하고 그냥 쪼는 수밖에 없습니다. 제대로된 프로젝트 관리는 스펙이 제대로 작성되어야 합니다. 프로토타입 방법론이나 점진적인 개발을 할 경우에도 짧은 주기로 똑같은 상황이 벌어집니다.

    답글삭제