Joypia

프로젝트 관리에 있어 제일 중요한 것이 뭐냐고 묻는 다면 나는 '계획'이라고 확신한다. 프로젝트가 실패하는 가장 주된 원인이 뭐냐고 묻는다면 역시 '계획'이라고 생각한다. 그러면, SI 프로젝트에서 계획은 어떻게 세워지는지 그 긴 여정을 따라가 보자. ​ ​ 1. 프로젝트 계획을 잘 세우려면 '기획'을 잘 해야 한다. ​ 왜냐하면 어찌된 영문인지 모르지만 기획단계에서 시작 날짜와 종료 날짜가 이미 정해지기 때문이다. 이는 시사하는 바가 매우 크다. 사실 수행팀은 일정에 대한 헤게모니를 갖고 있지 않다. 잘 아는 바와 같이 계획은 이미 RFP에 명시되어 있다. 즉. 일정, 품질, 결과물의 책임은 전적으로 - 분명히 얘기하는데 - 발주처의 기획자에게 있다. 그들이 요구사항과 일정과 품질 수준을 이미 기획단계..

올해 프로야구 플에이오프가 시작 되기전 모 구단 감독 사퇴건으로 야구계가 소란했다. 이 구단 뿐만 아니라 저 남쪽 구단 중 하나도 옛부터 프런트 간섭이 비밀 아닌 비밀로 유명하다. 성적이 안좋은 이유 중 하나로 치부하곤 한다. 난 고향이 부산이라 처음엔 롯데 자이언트 팬이었다가, 금성산전에 입사하면서 엘쥐 트윈스로 갈아탔다가, 오비 베어스 홈피 관리하고 기능 만들고(스포츠서울 기자와 ‘야구114’ 사이트 만들고) 하면서 지금의 두산 베어스 팬이 되었다. 미안하다. 야구 얘기 하려는 게 아니다. 이번 이슈를 계기로 PM 얘길 하려고 한다. 프로젝트를 하다보면 비슷한 사례가 이 바닥에서도 종종 발생한다. 다른게 있다면 프런트가 아니라 발주처에서 PM 을 갈아 치운다는 거다. 큰 프로젝일수록 빈번히 일어난다...

공공기관 SI 프로젝을 하다보면 신경 쓰이는 일이 몇몇 있다. 그 중 하나가 각종 보고시 발표하는 거다. 경험상 착수보고는 거의 하는 편이고, 그 외 중간보고와 완료보고가 있다. 사실 프로젝이 잘 진행 될수록 보고회를 갖는 경향이 있다. 그러니 발표가 꺼려 지거나 하기 싫다면 프로젝을 개판 치면 된다. ^^~ 이 발표회가 신경 쓰이는 이유는 보고를 받는 대상 때문이다. 보통 임원급이 참석하는데 금액이 크고 중요한 것은 아무래도 기관장이 참석하게 된다. 그러면 수행사도 그에 맞는 사람이 참석하게 되는데 보통 고객보다 한 지위 높은 사람이 참석하는 것이 좋다. 높은 분이 참석할수록 고객 담당자나 수행팅이나 모두 긴장할 수밖에 없다. 고객은 자기 상사만 신경 쓰겠지만 수행팀은 자사 임원까지 신경 쓰는 보통 귀..

공공 SI 에서 가장 어려운 프로젝은 전에 없던 것을 구축하는 신규 프로젝이다. 경험이나 선례가 없어 고객도 모르고, PM 도 모르고, PMO도 모르고, 감리도 모르고, 전문가도 없다. 멍청하게도 이런 프로젝에서 고객이 결정해 주길 바란다면 실패한다. 고객의 입장에서도 이런 PM 이 들어왔다면 당장 교체를 요구해야 한다. ​이 경우 다음과 같이 진행함으로써 반드시 고객을 리딩해야 한다. 1. PM 과 PL은 관련 법규, 정책, 기술, 동향 등을 졸라 공부해야 한다. 공공 기관은 해당 법령에 의해서 업무가 발생한다. 따라서 다른 조직과는 다르게 꼭 관련 법규를 서베이할 필요가 있다. 해당 업무 프로세스나 비즈니스 로직을 수립할 때 관련 기술이나 동향을 살펴 볼 필요가 있다. 가끔은 이미 해당 기술이 나와 ..

보통 SI 에서 테스트 관련 업무는 뭐 이정도 되겠다. - 테스트 계획 세우기 - 테스트 환경 만들기 - 테스트 열씸히 하기 - 나온 오류 수정하기 - 테스트 결과 보고하기 이런 테스트 업무를 하는 시기는 설계 단계에서 계획을 세우고 시나리오를 만드는 것 외에는 구현 단계에 들어와 본격적으로 이루어진다. 하지만 설계 단계에서도 테스트는 이루어 져야 한다. SW 개발에 있어 설계가 가정 중요하다고 하면서 그 설계가 잘 되었는지는 검증하는 메쏘드가 거의 없다. 사실 SI 에서 설계는 고객의 요구사항을 설계도로 보여주는 것이다. 건축으로 따지면 조감도를 그리는 것이다. 여기에 그림으로는 그럴듯 하지만 과연 그렇게 구축될 수 있는지 설계상 검토가 필요하다. 다시 건축을 거들떠 보면 하중은 견딜 수 있는지, 동선..

SI 프로젝이 시작되면 제일 먼저 팀들에게 교육하는 게 있다. 그 중에 프로젝트의 성공 기준은 어떤 것인가를 장표 하나 분량으로 설명하는데 다음과 같다. 완벽한 성공 일정이 앞서가고, 예산보다 적게 사용, 모든 사람의 기대보다 초과된 성과 매우 성공적임 ​범위에 맞춰 정해진 일정 및 예산 내에 완료 성공적임 ​목표한 일정에 완료했으나 스펙을 만족시키기 위해 재작업이 요구되며, 이로 인해 이익에 영향을 미침 성공적이지 못함 ​약간의 목표 일정 지연과 고객이 만족하지 못함 부분적 실패 ​늦은 일정과 예산 초과, 산출물이 받아들여지지 않음 완전한 실패 ​목표를 완료하지 못하고, 수익을 얻지 못하며, 그것이 , 치명적인 이슈가 됨 ​ 여기서 보면 성공의 기준은 일정 내에 검수를 받느냐가 기준임을 알 수 있다. ..

머 거창(?)하게 제목을 붙였지만 어디까지나 개인적인 생각이다. 공공SI를 하기 위해 계약과 관련된 문서 중 가장 비중이 큰 세 개가 있다. 보통 RFP 라고 하는 제안요청서, 이 걸 보고 밤새워 업체에서 만드는 제안서, 그리고 수주하게 되면 10일 이내 만들어 내는 사업수행계획서가 그 것이다. 이들의 의미를 생각해보자. 확실한 근거를 찾기 위해 여기 저기 뒤져야하지만 매우 귀찮은 관계로, 그냥 내가 이제껏 들어 왔거나,혹은 어디서 봤거나, 아무튼 내가 인지하고 있는 것으로 설명해 보겠다. 우선 제안요청서부터 살펴보자. 제안요청서가 만들어지려면 먼저 사업계획서가 만들어 져야 한다. 그래야 내부적으로 결재도 받고, 예산도 받고 할 수 있다. 이 거 만들 때, 요즘은 공공기관이나 정부부처 담당자가 직접 만드..

난 SI 프로젝트에서 고객보다 반 보(요즘은 한 보 앞서가는 건 거의 불가능하다) 정도만 앞서가길 원한다. 매번 프로젝트가 시작되면 PM 이나 PL 들에게 요구하는 첫 번째 사항이다. '고객보다 반보 앞서 가라.' 1. 이는 고객이 얘기하기 전에 먼저 선수를 치라는 얘기다. 고객이 무엇을 궁금해 하는지 미리 파악하여 준비를 하고 일정을 통보하는 것이다. 물론 고객이 전혀 생각 안할 수도 있다. 이 경우에도 고객에게 신뢰를 심어 준다. 2. 고객이 요구하는 것 보다 조금 더 확대된 서비스를 제공하는 것을 뜻한다 고객이 두 가지 안을 보자고 하면 3가지 방안을 만들어서 보여주어야 한다. 기능이나 범위를 확대하아는 얘기가 아님을 명심하자. 3. 미리 일어날 수 있는 문제를 예고할 수 있는 것을 뜻한다. 미리 ..

그동안 개발자들이 자기의 권익을 제대로 찾기 위해 여러가지 움직임이 일고있다. 2013년도에는 서울시에서 IT 개발자들을 모아 그들의 의견을 청취하기도 했는데, 깜작 이벤트로 끝난 것 같다. 그 뒤 개발자에게 직접 의견을 청취하는 노력을 별로 보지 못했다. 그러나 내가 보기엔 다른 분야는 모르겠으나 공공 SI 분야의 개발자들은 그 능력이 예전만 못하다는 느낌을 받는다. 물론 여기엔 여러가지 이유가 있다. 나중에 시간이 되면 이 부분에 대해서도 얘기를 해보고 싶다. 개발자로써 당당한 권리와 정당한 대가를 받고 싶다면 능력을 우선 보여줘야 한다. 잘 알다시피 코딩 실력외에 철저히 업무를 분석하는 능력과 설계 능력을 갖춰야한다. 이럴려면 문서 작성 능력과 리뷰하는 능력도 잘 갖춰져야 한다. 말도 안되는 표현으..

차를 몰고 가다보면 가끔 '사고다발구간'이라는 표지판을 볼 때가 있다. 그 구간 또는 지역을 하나하나 살펴보면 별 문제가 없는 것처럼 보인다. 아마도 그 구간의 도로 여건, 신호체계, 교통량 등 여러 가지 주변 특성으로 인해 사고가 다른데 보다 빈번하게 일어나는 게 아닌가 싶다. 마찬가지로 SI 프로젝트에도 '사고다발 프로젝트'가 존재하는 것이 아닌가 하는 생각이 든다. 정리한 것은 없지만 괘 경험이 있는 PM 이나 개발자들은 나름대로 사고다발의 조건을 알고 있을 것 같다. 물론 도로의 사정과 교통체계 등 여러 가지가 변하듯이, 프로젝트도 환경이 변함에 따라 그 조건도 변하고 있는 것 같다. 뻔히 보이는 위험이 있는 경우가 아니라 별개로 보면 문제가 없는데 사고가 발생하는 프로젝트의 경우 또는 조건을 정..