대규모 시스템 구축 시 체크리스트 (2)
성공적인 PLM 시스템 구축을 위해
지난 글에서 기존 시스템들의 운영, 유지 보수 인원이 프로젝트 팀에 참여를 해야 한다는 체크 리스트 항목이 있었습니다. 이번 글에서는 팀 구성에 대한 체크 리스트를 알아보겠습니다.
5. 현업 담당자를 프로젝트 팀에 참여를 시키고, 현업 프로젝트 관리자를 선정해야 한다.
신규 시스템 구성에는 업무에 대한 To-Be Process를 정의해야 합니다. To-Be Process를 정의하려면, 기존 As-Is Process를 분석해야 하는데, 그 역할은 현업 담당자가 수행해야 합니다.
기존 업무를 수행했고, 정확히 알고 문제점을 파악할 수 있는 현업 담당자가 팀에 포함이 되어 있어야 하고, 컨설턴트가 To-Be Process를 정의할 때 그것을 검토하고, 1차로 확정 짓는 역할도 현업 담당자가 맡아주어야 합니다.
적절한 현업 담당자가 없는 시스템 구축팀은 업무와 동떨어진 시스템을 구축할 위험이 있는 동시에 기존 업무에 대한 이해 없이 시스템 구축을 시작할 위험이 있습니다.
6. Task Force 팀에 속한 컨설턴트, 개발팀, 현업 담당자는 최대한 한 공간에 일해야 한다.
물리적인 구분은 정서적 단절과 정신적 장벽을 가져옵니다. 컨설턴트와 개발팀, 현업 담당자의 역할은 서로 상호 견제, 상호 보완하는 관계를 갖습니다. 현업 담당자는 As-Is 업무 프로세스를 분석하고, To-Be 업무 프로세스를 검토하여 확정하는 역할을 맡습니다.
현업 담당자는 최대한 업무를 익숙한 방식대로 하려고 하고, 기능은 최대한 사용자 편의성에 맞게 구현하고자 노력합니다. 개발팀은 설계된 기능을 기준으로 정해진 기간, 정해진 자원으로 개발하는 역할을 맡습니다. 개발팀은 최대한 기본 기능은 변경 없이 안정적으로 개발을 수행하고자 하여 약간은 방어적인 모습을 보입니다
특히, 패키지 제품인 경우는 최대한 기본 제품의 변경이 없도록 요구사항을 제한하여 범위 관리를 합니다.
컨설턴트는 As-Is 업무 프로세스를 문제를 파악하고, 이를 개선하는 To-Be 업무 프로세스를 정의합니다.
그리고, 그 프로세스 맞춰서 기능 설계를 합니다. 컨설턴트는 현업 담당자와 개발팀 사이를 조율하여 최적의 결과를 내는데 집중합니다. 현업 담당자에게는 As-Is가 아닌 To-Be를 받아들이도록 설득하고, 개발팀은 설계된 기능을 주어진 자원에서 최대한 개발하도록 독려합니다.
각자 역할이 있다 보니, 토론도 많이 하고, 언쟁이 일어나기도 합니다.
그렇게 활발한 토론과 언쟁의 결과가 성공적인 시스템을 구축하는 것이겠죠. 그런데, 공간이 떨어지면, 서로 발전된 방향으로 나아가는 것이 아니라, 언쟁이 감정의 골로 깊어지고 서로 불신하고 포기하고 같은 팀이라고 하기엔 민망할 정도로 서로 교류를 안 하게 됩니다.
공간이 떨어져서 토론과 언쟁을 피하는 고 상대편을 욕하는 건 서로 문제를 회피하는 결과 밖에 만들지 못합니다. 특히 현업 담당자와 개발팀 사이에 있는 컨설턴트는 누구의 편을 드는 것이 아니라 중재자로서 최적의 결과를 내도록 유도해야 합니다. 정답지가 있다면 고객 만족이겠지만, 고객 만족이 As-Is를 답습하는 것이 아니라, 고객이 To-Be를 받아들여서 발전할 수 있도록 설득하는 데 있음을 알아야겠죠.
저는 한때 컨설턴트는 고객사의 돈을 받아서 일을 하는 것이므로 현업과 힘을 합쳐서 최대한 개발팀이 일을 많이 하도록 하는 게 제 역할이라고 생각한 적이 있었습니다. 최대한 As-Is를 고려한 편의 기능도 잔뜩 포함시켰고, 결국은 개발팀은 그 기능을 모두 개발했지만, 끝날 즘엔 개발팀 인원들은 녹초가 돼서 절 한 팀이 아니라 얄미운 시누이 정도로 생각하게 되었습니다.
그럼에도 끝까지 문제 없이 프로젝트를 했던 건 고우나 미우나 한 공간에서 생활했기 때문이 아닐까 합니다.
7. 인력 이탈, 인력 교체, 추가 인력 투입 등의 인력에 대한 Contigency Plan이 잡혀 있어야 한다.
초기에 프로젝트 팀을 구성하고 나서, 인력 변동이 없으면 좋겠지만, 팀원 교체 상황은 프로젝트 기간 중에 수시로 발생하게 됩니다. 퇴사하거나 실력이 없어서 교체를 해야 하거나, 물량이 많아서 추가로 투입을 하는 등 인력에 관련된 이슈는 계속 발생한다고 봐야 합니다.
인력에 대해서는 무엇도 전제해서는 안 됩니다.
누구는 안 빠질 것이다. 누구는 그 일을 다 할 수 있을 것이다. 현재 인력 이상은 투입할 일 없을 것이다. 예상외 상황은 언제나 발생할 수 있으며, 그 상황을 어떻게 대응하느냐가 프로젝트에 미치는 영향을 크게 하는가, 작게 하는가 달라집니다.
그리고, 인력에 관련된 문제는 최대한 빨리 처리해야 합니다. Man-Month의 미신이란 말이 있습니다.
아무리 인력을 투입해도 시간을 대체하질 못합니다. 2명이서 2개월 동안 할 수 있는 일과 4명이 1개월 동안 할 수 있는 일은 같은 4Man-Month의 일이지만 성격은 완전히 다릅니다.
인력에 대한 문제가 발생했을 땐, 시간이 최대한 소모되지 않게 지체함이 없어야 합니다.
더 중요한 건 프로젝트 시작할 때 인력에 대한 비상 계획을 미리 세워 두는 겁니다.
비상 계획 없이 일이 터져서 어찌해야 하지, 버둥거리다가 시간이 다 지나버리면 그땐 사람을 충분히 투입해도 돌이킬 수 없을 수 있습니다.
다음 글에서 이어서 쓰겠습니다.
