프로젝트는 언젠가 끝이 있고, 투입된 인력은 언젠가 끝이 있다.
IT 프로젝트는 기획 > 디자인 > 퍼블리싱 > 개발 순서로 처리되는 특성상 순차적으로 투입되는 경우가 종종 있다.
그리고 투입인력 종료시점도 이와 같은 순서로 진행된다. (물론 같이 모든 파트가 들어왔다, 모두 종료되는 경우도 있다.)
처음에 4개 파트가 모두 투입되고, 마지막에 4개 모두 빠질수도 있지만 각자의 사정이 있기에 종료시점도 제각각이다.
기획은 가장 먼저 확정되기에 투입종료시기도 가장 빠르다.
(물론 PM역할을 같이 하는 경우라면 프로젝트 종료시까지 같이있겠지만...)
그런데 빠져나갈때도 기술이 있다.
그냥 투입종료일이 되서.. "안녕 나 갈께.. 바이바이"
이런식으로 하면 십중팔구 고객사와 이슈가 생길 수 있다.
가뜩이나 산으로 가는 프로젝트, 프로젝트가 잘 안된다면 이 문제는 더 심하다.
추후에 문제소지를 없애기 위해선 아래 사항에 유의해야 한다.
1. 고객사에 퇴사시기를 명확히 밝힌다.
모든 파트가 일시에 빠지는 경우가 아니라면 고객사 담당자에게 내 퇴사 시기를 말한다.
고객사 담당자는 내 퇴사시기를 모르기 때문이다. 하루 이틀 전에 얘기하면 서로 당황하기 일쑤다.
내 경우는 종료되기 2주 전쯤 담당자한테 말했다.
마무리 작업 내용이 많지 않고, 수정요청사항이 들어오더라도 충분히 대응할 시간이 2주라고 생각했기 때문이다.
만약 이 때 기획서의 수정요청사항이 나온다면 이건 단순수정사항이 아닌 요청변경건으로 처리해야 한다.
내가 수정하는 기획서만 바뀌는 것이 아니라 프로젝트 일정에 전반적인 영향이 있기 때문이다.
2. 요청된 산출물 완료여부를 확인 받는다.
업무를 하다보면 이메일이 아닌 구두로 진행되는 경우도 많다. 이런 경우에는 고객이 컨펌하더라도 나중에 오리발 내밀 수 있다.
또한 남아 있는 다른 파트가 기획자 탓을 하기도 한다. "기획이 제대로 안되서 개발 못했다." "기획서 업데이트가 필요하다."
또 현업까지 합세하여 먼저 빠진 기획자를 탓하기도 한다.
그러기에 우리는 현업에게 확실하게 확인을 받을 필요가 있다.
퇴사 전 빠진 부분에 대해서 문의하고, 최종적으로 컨펌 받았는지를 이메일로 받는것이 좋다.