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


Archive»


아키텍트,PM,개발자의 차이...(1)

IT 이야기/IT와 사람 | 2008.12.23 09:39 | Posted by 조대협
PM,아키텍트,개발자.. 모두 프로젝트에서 없어서는 안될 사람들이다.
IT 생활을 하다보니 각자의 역할이 명확하게 다르고 거기에 요구 되는 능력도 다르다는것을 알게 되는데.
반대로 제역할을 못하는 사람들과 일을 하게 되면 참으로 고달퍼 지는건 사실이다.

* 프로젝트 메니져
프로젝트 메니져의 역할은 어떻게든 프로젝트를 성공적으로 끝내는 것이다.
인원이나 일정에 대한 관리뿐만 아니라, 특히 돈 (Budget)과 위험요소(Risk)에 대한 관리가 중요하다.
무엇보다 중요한것은 Communication이다. 고객과의 의사소통과 팀원들과의 의사소통이 가장 중요한 역할이다.
그 과정에서 RISK들이 자연스럽게 도출되고, 각자의 능력을 최대화해줄 수 있는 방법을 찾을 수 있게 된다.

경험상 많은 프로젝트 관리자들을 보면, 정작 자신이 해야할 무언가를 외면하고 엉뚱한것에 매달려서 집착하는 경우를 많이 봤다. 마치 자신의 능력이 부족함을 다른데서 메워 보여 주려는 듯이..
일정 관리는 MS-PROJECT를 그려놓고 일정이 늦었네 마네 하는 것이 아니라, 매주 단위로 각 개발인원의 일정과 작업량을 체크하고 요건의 변화나 위험요소에 따라서 탄력적으로 일정이나 Scope를 조정하는 것이다..
야근 안한다고 쪼는게 아니란 말이지~~

그리고 RISK 관리... 정말 하는 사람들 많이 못봤다. 많은 기법과 쉬운 관리 방법들이 있는데도 불구하고 말이다.
또 다른 PM의 역할중의 하나는 정치와 고객의 요건 변화에서 팀원을 보호하는 일이다. 요건 변화를 무조건 거절하라는 말이 아니라. 요건 변화에서 오는 일정 변경에 대해서 적절하게 평가하고 자원을 할당하라는 말이다.

적어도 내 경험상으로는 그렇다. 야근이 절대 프로젝트 품질에 도움이 되지 않는다.
피치못할 일정때문에 야근은 분명 있을 수 있다. 동감한다. 그런데 그런 집중 근무 기간이 2주가 넘게 되면 생산성에 심각한 문제가 온다.

예전에 시스템 테스트를 45일간 진행한적이 있다. 9시 출근해서 보통 11시~1시 사이에 끝나는 일정이 한달반동안 계속되었다.
처음 2주는 그럭저럭 버텼지만, 그 다음부터 지각하는 사람들이 늘어나고, 일정 진행에 있어서 꼭 있어야할 사람들이 아침에 지각을 하게 되고, 보통 안늦어도 10시정도에 출근들을 하게 되었다. 고객측에서도 야근에 의한 피로로 생각해서 납득을 해줬지만 지친 몸 상태에서 업무를 정작 시작할 수 있는 시간은 11시가 넘어서였고 한 30분정도 업무를 보면 점심 식사 시간이 되었기 때문에, 결과적으로 실제 업무는 1시부터 시작되었다.
그렇게 저녁 늦게 까지 또 야근을 하다보면. (사실 야근이 모든 인원에게 필요한것은 아니었지만. 한국 IT의 이~~상한 문화때문에.... 앉아 있는 일이 많았다.) 몸의 피로도도 올라가고 사기도 저하가 된다. 결국에는 야근을 안하는만 못하다는.. 결과는 내겠지만 그 품질이 보장이 될까?

고객은 항상 무리한 일정으로 무언가를 요구한다... "우린 이 시스템의 성능 테스트를 하고 싶습니다!! 단 3일만에 말이지요.." 당신이라면 받아 들이겠습니까? 안 받아 들이겠습니까?

어떤 TASK를 할때 현재 가용한 RESOURCE를 가지고 프로젝트에 필요한 VALUE를 낼 수 있는지 없는지가 결정의 포인트가 되어야 하리 않을까?

사실 프로젝트 메니져의 커뮤니케이션과 RISK관리 능력에 대해서 정리를 해보려고 했는데.
쓰다보니 야근 이야기에서 욱!! 하는 바람에 이야기가 삼천포로 빠져 버렸다.. ^^;
다음 이야기는 또 나중에 이어서...




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 무혹 2008.12.23 10:37 신고  댓글주소  수정/삭제  댓글쓰기

    윗 글에서 쉬운 RISK관리 기법과 방법이 있다고 하셨는데요.. 거기에 해당하는 자료나 책, 그리고 실 사례(?)를 알 수 있을까요? 평소 많이 궁금하던 부분이었는데요...

    • 조대협 2008.12.23 12:48 신고  댓글주소  수정/삭제

      블로그 멘 위에 보시면 devmento 발표 자료 링크가 있습니다. 거기에서 23 페이지를 보시면 Erik van의 Risk 기반 테스트 기법이 있는데, Google에서 찾아보시면 자료가 더 있을겁니다. 같은 원리로 리스크를 관리할 수 있습니다.

      예를 들면 팀원과 고객을 함께 앉혀 놓고 RISK ITEM을 각자 10개씩 종이에 적도록 합니다. 그리고 취합해 놓으면 10개의 TOP RISK ITEM을 찾을 수 있습니다. 각 리스크 아이템에 대해서 발생 가능성과 비지니스 임팩트에 대한 항목을 5개 정도 만듭니다.
      발생 가능성은 기술 성숙도,Learning Curve,오픈 소스를 썼다.. 모 그런게 될 수 있겠고, 임팩트는 필수 기능이다. 지연시 시장 진입이 느려져서 치명적이다 그런것들이 됩니다.

      모인 사람들이 다시 이 표를 가지고 각각 점수를 메겨서 분포도를 그려보면 위에 언급한 PT의 그림처럼 나옵니다. 그중에서 STA 영역에 대한 RISK는 모두 관리해야 하고, ITA는 기술적인 측면에서 SSTA는 비지니스 측면에서 관리하도록 하면 됩니다.

      Risk Management에 대한 내용은 프로젝트 관리 문서에 많으니까는 찾아보시면 도움이 많이 되지 않을까요?

  2. 무혹 2008.12.24 07:41 신고  댓글주소  수정/삭제  댓글쓰기

    답변 감사합니다. 말씀하신 내용 살펴보도록 하겠습니다.
    자료를 보다가 궁금한 부분은 질문을 좀 드리겠습니다.