Joypia

PM 의 가장 큰 역할은 사업관리이다. 사업관리의 기본은 사실 매우 간단하다. 각 타스크 별로 일정 계획을 세우고, 그 계획대로 진행되는 지 점검하고 계획대로 안되었다면 따져본 후 적절한 후속 조치를 취해 지연 일정을 만회하면 되는 것이다. 말은 쉽다. 하지만 실현하기는 쉽지 않다. 우선 일정계획이다. 보통 WBS 방식을 사용한다. 이 계획이 잘 못 되면 모든 게 틀어진다. 두번째로 점검이다. 사실 PM 들의 가장 큰 문제가 점검을 할 줄 모른다는 것이다. 마지막으로 적절한 후속조치인데, 이 부분에서 PM 의 경륜과 노하우가 빛이나는 부분이다. 앞의 두가지가 부실해도 - 죽, 뒤 늦게 발견되어 사고가 터져도 마무리의 기술로 충분히 보완되기 때문이다. 각 항목에 대해 자세한 부분은 추후 시간이 되면 따져 ..

PM은 물론이고 개발자 모두가 반드시 몸에 베어야 하는 것들이 몇가지 있다. 그 중에 하나가 회의록 작성이다. 고객이나 이해 당사자가 모여 얘기를 하면 무조건 회의록을 작성하는 버릇을 들여야 한다. 이를 지키기 위해서는 PM 자신이 버릇이 들여있어야 함은 물론이고, 팀원들에게 뿌리 내릴 때까지 끊임없이 잔소리를 해야한다. 이렇게 하기 위한 몇가지 요령을 살펴보자. 우선 하나의 팀으로 구성된 프로젝트 조직이면, 팀원 중 회의록 작성 전담자를 지명하는 것이다. 회의록 전담자는 다음과 같은 사람을 고른다. 팀이 여러 개이면 각 팀마다 회의록 작성자를 임명해야 한다. - 신입 개발자는 피하는 게 좋다. 뜻도 모르고 적는 것에 정확한 기록을 기대하기 힘들기 때문이다. 따라서 적어도 3년차 이상 개발자에서 선택한다..

많은 SI 회사들이 민수와 관수 또는 공공과 사기업으로 구분 짓는데는 상당한 일리가 있다. 특징이 뚜렷이 구분된다고 생각하기 때문이다. 고객, 이른바 '갑'이 나타내는 특징은 사실 공공분야가 일반기업 분야도 포함하고 있다고 생각한다. 즉 공공 특징의 일부만 사기업이 갖고 있다고 보는 견해다. 왜냐하면 나의 경우 7 대 3 정도로 공공과 일반을 경험했지만 사기업에서만의 별다른 특징을 찾지 못했다. 모든 분야가 그렇겠지만 이 분야의 일도 경험(여기서 경험은 갑을 대하는 경험을 말한다)이 쌓일수록 베테랑이 되어가고 그만큼 미래예측이나 대처 능력이 높아진다.이는 갑의 사고방식, 행동, 일처리 순서 등에 대한 일반적인 특징을 갖고 있기 때문이다. 우리는 그것 중에 아주 심한 경우를 "갑질"이라고 표현한다. 자 공..

PM 이 사업관리 하는 것 중에 가장 모호한 것이 위험과 이슈다. 도대체 이것의 기준이 무엇인가 헷갈리기 일쑤다. 지금까지 만나본 수 많은 감리들 조차 이 두가지를 구분하는 감리인을 만나보지 못했다. 그래서 어떤 경우에는 각각 관리 대장을 따로 만드는 것이 아니라 아예 '위험/이슈 관리 대장'이라고 하나로 작성하는 경우도 있다. 나는 이것을 이렇게 이해하고 있다. 물론 나 나름의 생각이라 정답이라고 할 수 는 없다. 위험은 프로젝트가 시작되기 전에 이미 식별된 것들이다. 이슈는 사전에 인지되지 못한 즉 프로젝트 수행 도중에 예상치 못한 리스크가 발생한 경우를 말한다. 문제는 이 얘기를 하려는 것이 아니라 앞서 얘기한 위험 관리에 대해 말하고자 한다. 내 생각에 따르면 위험은 미리 예견된 리스크라고 했다...

CHAOS Report 2015 자료를 보면 조금 흥미로운 내용이 있다. 5년 전이나 지금이나 프로젝트 성공율이 비슷하 것도 놀랍기는 하지만 이것 보다는 관심이 가는 3가지 통계치가 있다. 우선 프로젝트 규모별 성공율이다. 표에서 보면 규모가 클수록 성공율이 굉장히 낮아짐을 알 수 있다. 내 경험이나 언듯 생각해 보면 작은 프로젝트든 큰 프로젝트든 성공율에 큰 차이가 없어야 한다. 큰 프로젝트 일수록 공통팀이나 PMO 등 부가적인 조직과 지원이 많이 붙기 때문에 프로젝트의 품질도 그만큼 올라간다고 생각했다. 수치를 보고 가만히 생각하니 조금은 착각을 했다는 걸 깨달았다. 2~3 년 전부터 공공기관 정보시스템의 차세대 프로젝트가 시작되고 있다. 작게는 300억대에서 크게는 2,000억대 규모이다. 들리는 ..

공공 SI 에서 PT가 중요한 편에 속한다고 본다. 하늘을 봐야 별을 보듯이 수주를 해야 프로젝트를 할 수 있는 것 아닌가. 수주에는 반드시 제안설명 즉, PT 가 들어간다. 언제부터인가 PT를 그 프로젝에 예정된 PM 이 해야 한다는 조건이 붙어 PM 고민거리 중 하나가 되었다. 이 지랄 같은 조건이 붙은 것은 프로젝을 책임지고 수행할 PM 이 그 사업에 대해 설명할 수 있어야 되는 것 아니냐는 언뜻 들으면 그럴싸한 논리 때문인 것으로 알고 있다. 그 전엔 아무나 - 사업부장이나 PT를 그래도 좀 한다고 하는 사람이 했었다. 사실 PT를 잘한다고 반드시 프로젝 수행을 잘하리라는 보장은 없는 것이다. 하지만 현실은 그렇지 않으니 어떡하겠는가. 대부분 PM 이 PT를 잘 못하는 이유는 아주 가끔 하기 때문..