비록 이뤄 놓은 것이 그렇게 많진 않지만, 그간 게임 개발 업력이 쌓이면서 나름 직관이 생긴 부분이 있다면, 바로 프로젝트의 진행 경과를 보고 이 프로젝트가 망할 프로젝트인지 아닌지 거의 정확하게 예측할 수 있다는 것이다.1 이러한 능력에 대해 나는, 아이러니하게도 이건 그간 이뤄 놓은 것이 그렇게 많지 않았고, 그렇다고 또 이룬게 아에 없지는 않았기 때문에 생긴 통찰인 것으로 결론지었다.
그간의 경험을 바탕으로 만들어진, 어떤 프로젝트가 실패하는 – 혹은 실패를 향해 달리고 있는 프로젝트인지에 대한 나의 직관을 공유해볼까 한다. 우선 오해를 피하기 위해, 이 글에서 정의하는 프로젝트의 실패에 대해서 먼저 정리하고 가자.
프로젝트가 목표했던 결과물을 도출하지 못하고, 중도에 포기 되거나, 목표와 전혀 다른 결과물을 만들어내는 것을 프로젝트 실패로 정의 한다. 이는 개발 완료 이후 상업적인 성공 / 실패와는 완전히 독립인 사건이다.
정의: 프로젝트 실패
보편적인 프로젝트의 성공 요소
우선 21세기 인류의 멘토(…) 인 ChatGPT 에게 프로젝트 성공에 필요한 요소를 물어보았다.
- 명확한 목표 설정: 프로젝트 팀이 명확한 목표를 설정하고 이를 이해하고 공유해야 합니다. 목표는 구체적이고 측정 가능해야 하며, 모든 팀원이 동의하는 것이 중요합니다.
- 좋은 팀 구성: 팀 구성원들은 각자의 역할과 책임을 이해하고, 서로 협력하며, 서로의 강점을 활용할 수 있어야 합니다. 팀원들 간의 의사소통과 협업 능력이 중요합니다.
- 철저한 계획과 일정 관리: 프로젝트를 위한 철저한 계획 수립과 일정 관리는 중요합니다. 목표를 달성하기 위한 세부적인 계획과 마일스톤을 설정하고, 일정을 지키기 위한 리소스와 작업 분배를 관리해야 합니다.
- 효과적인 의사소통: 팀원들 간의 효과적인 의사소통은 프로젝트 성공에 필수적입니다. 이를 위해 정기적인 회의, 이메일, 채팅 등의 커뮤니케이션 도구를 활용하고, 문제 또는 혼란을 방지하기 위해 명확하고 정확한 정보 전달이 이루어져야 합니다.
- 변경 관리: 프로젝트 도중 변경 사항이 발생할 수 있으므로, 변경 관리 프로세스를 수립하여 변경의 영향을 평가하고, 필요한 조치를 취할 수 있도록 해야 합니다.
- 품질 관리: 소프트웨어 개발 프로젝트에서는 품질 관리가 매우 중요합니다. 품질 관리를 위해 테스트 계획, 테스트 자동화, 코드 리뷰 등을 수행하여 결함을 최소화하고 사용자 요구 사항을 충족하는 소프트웨어를 개발해야 합니다.
- 지속적인 개선과 학습: 프로젝트 완료 후에도 지속적인 개선과 학습을 추구해야 합니다. 프로젝트에서 얻은 경험을 돌아보고, 성과와 문제점을 분석하여 향후 프로젝트에서 더 나은 결과를 얻을 수 있도록 해야 합니다.
뒤집어 이야기 하면, 위와 같은 요소가 프로젝트에 결여되어 있다면, 프로젝트 실패에 한발 더 가깝다고 할 수 있을 것이다. 하지만 이런 조언은 어떻게 보면 너무 보편적인 이야기라 크게 와 닿지 않을 것이다.
프로젝트 실패 체크 리스트
위의 AI의 조언은 좀 더 구체적인 내용이 필요하다. 이제 나의 경험에 바탕으로, 위의 AI의 조언에 구체적인 내용을 적어보고자 한다. 혹시나 필요한 사람이 있을 수 있다는 생각에 체크 리스트 형태로 정리해 보겠다.
1. 명확한 목표 설정
☐ 프로젝트의 비전, 목표가 담긴 문서가 없다. 있다고 하더라도 업데이트가 늦고, 찾기 어려워 팀원들이 존재를 모른다.
☐ 프로젝트 비전, 목표에 화려한 미사여구만 달려있고, 구체적으로 어떤 제품이 될지 상상할 수 있는 내용이 존재하지 않는다.
☐ 목표는 바뀔 수 있지만, 프로젝트 진행 중 목표가 자주(최소 매 마일스톤 마다) 바뀌고, 이에 대한 내용이 팀원들에게 충분히 전파되지 않는다.
2. 좋은 팀 구성
☐ 목표하는 제품을 만들기 위한 기술 스택을 갖춘 작업자가 프로젝트에 존재하지 않는다.
☐ 프로젝트에 대한 목표나 이해를 바탕으로 한 것이 아닌, 자신의 업무, 파트 관점에서 업무를 주도하려는 팀원이 존재한다.
☐ 남의 이야기를 듣지 않는 팀원이 존재한다.
3. 철저한 계획과 일정 관리
☐ 팀 내에 프로젝트 업무와 이슈를 기록하고 이를 지속적으로 추적하는 업무를 담당하는 사람이 없다(꼭 PM이 아니라도 팀장, 팀원 중에서도 해당 업무를 담당하는 사람이 없다).
☐ 구성원이 현재 프로젝트의 진척 상황을 한눈에 파악할 수 있는 제도가 팀 내에 존재하지 않는다.
☐ 계획과 일정은 상위 관리자에게만 일부 공유가 되고, 팀원들은 자신이 해야 할 일을 해당 업무가 지정 될 때 즈음에나 계획과 일정의 일부만 확인하고 계획 수립이 가능하다.
☐ 프로젝트의 규모나 목표에 맞는 프로젝트 관리 방법이 도입되어 있지 않다. (예를 들어, 인원이 수십명이 넘어가는 프로젝트에서 일정 및 업무 추적을 스프레드시트로 한다)
☐ 마일스톤이나 업무는 항상 팀의 업무 처리 능력이 고려되지 않고, 무리하게 설정되곤 한다.
4. 효과적인 의사소통
☐ 프로젝트의 상태에 대해 공식적으로 확인할 수 있는 수단이 구성원에게 제공되지 않는다. 각 구성원이 다른 구성원에게 알음알음 퍼즐 맞추는 형태로 프로젝트 상태를 확인해야 한다.
☐ 의사소통은 비공식적인 경로에서만 활발하게 이뤄지며, 공식적인 경로는 매번 조용하거나, 프로젝트와 크게 관련 없는 의제만 논의된다.
☐ 팀 내부의 결정에 대한 공유가 제때 이뤄지지 않거나, 일부에게만 이뤄진다.
☐ 팀 내부 커뮤니케이션에 대한 접근 권한이 겹겹이 설정되어 있으며, 이 때문에 프로젝트 진행 목표나 과정에 대해 구성원들이 수시로 오판하는 상황이 만들어진다.
5. 변경 관리
☐ 변경에 대한 납득할 만한 근거가 없거나, 심지어는 프로젝트의 목표와 동떨어진 변경을 자주 시도한다.
☐ 변경을 결정할 때, 프로젝트 진행에 대한 평가를 거치지 않는다.
☐ 변경에 대한 내용이 전체 구성원에게 전파되지 않는다.
☐ (주로 시간이 없다는 핑계로) 변경이 중의적이고 모호한 형태로 정리되어 전파된다.
6. 품질 관리
☐ 각 파트의 작업자들은 자신이 오늘 완료한 결과물을 당일 혹은 다음날 실제 제품(일일 빌드 / 에디터) 상에서 확인할 수 있는 방법이 없다.
☐ 각 파트 작업자들은 자신의 업무 내용을 실제 제품에서 확인할 방법이 존재하지만, 이를 하지 않는다. 혹은 관련한 업무 체계가 존재하지 않는다.
☐ 실제 개발 중인 제품의 현 상태가 어떠한지 추적하고 관리하는 업무 체계가 존재하지 않는다.
☐ 현재 개발 단계에서 발생하는 여러가지 이슈에 대해 기록하고 추적하는 업무 체계가 존재하지 않는다.
7. 지속적인 개선과 학습
☐ 위의 문제들을 모든 구성원이 충분히 알고 있지만, 이를 개선하려 하지 않거나, 개선 노력이 내부/외부의 힘에 의해 매번 좌절된다.
총 7개 항목에 24개 체크 문항이지만, 이 중 몇 개 이상 체크 되면 프로젝트가 실패한다는 것은 없다(경험 상 보통 망하는 프로젝트는 하나만 하지 않는다).
사실 프로젝트에서 가장 중요한 것은 현재 상태를 세밀하게 파악하고, 발견된 문제를 최대한 신속하게 해결하는 것이라고 생각한다. 문제의 원인은 다양하며, 모든 것을 한 방에 해결해주는 명쾌한 답은 없다. 자신이 몸담고 있는 프로젝트, 조직, 환경에 따라 해결법은 다 달라질 수 밖에 없기 때문에, 프로젝트를 성공으로 이끄는 것은 쉽지 않으며, 매 번 프로젝트를 성공시키는 것 역시 그리 쉬운 일은 아니다.
그렇기 때문에, 7. 지속적인 개선과 학습 은 프로젝트의 성패를 좌우하는 가장 핵심 요소가 아닐까? 만약 내가 마지막 항목에 체크 되어 있는 팀에 속해 있다면, 나는 주저 없이 그 팀을 탈출할 것이다.
이런 능력은 비단 나만 가지고 있는 것은 아니란 것 또한 잘 알고 있다↩
1 Comment
Comments are closed.