제가 어떤 기획을 하고 있는지는 그때그때 프로젝트에 따라 다릅니다. 그래도 현재 진행하고 있는 프로젝트에서 기획 업무에 대해 이야기해 보면 더 쉽게 설명되는 부분도 있을 것입니다. 한 가지 먼저 말해두고 싶은 것은 저는 기획자이므로 항상 불확정성을 띄는 서로 다른 변수들로 인해 매번 다른 설계와 관리는 한다는 사실입니다.
현재 진행 프로젝트에서의 기획
기획의 특성상 예측 가능한 정형적인 업무를 하는 것은 아닙니다. 그러나 보통의 외주 기획에서는 정형적인 스타일로 업무를 해야 하는 경우가 종종 생깁니다. 그래서 많은 문제가 생기는 것을 자주 보게 되지만, 고객의 사전적 기대라는 측면에서 이러한 형식의 기획 업무 스타일은 어쩔 수 없습니다.
이런 외주 기획 상황에 비해 현재 진행하고 있는 프로젝트 기획은 조금 다른 상황이기는 합니다. 기획 문서와 방식은 제가 파악하는 현재 상황에 따라 조금씩 다르게 할 수 있다는 점입니다.
일단 아주 큰 프로젝트는 아니고, 또 기획적인 문제가 있어 제가 교체 투입되었기 때문입니다. 여기에 프로젝트 상황 때문에 투입될 때와는 다른 기획 롤을 수행하고 있다는 점도 있습니다.
프로젝트 상황
제가 이번 프리랜서로 투입된 프로젝트는 이미 약 1년 가까이 진행되어 오던 선행 프로젝트의 연장선에 있습니다. 그러기에 분석/설계를 위해 기존의 기획자는 작년부터 투입되어 있던 상황이었습니다.
저는 7월 말 경 이번 프로젝트 다음에 진행될 프로젝트의 범위를 잡고 기본 설계를 하기 위해 투입되었던 것입니다.
그런데 문제가 발생합니다.
이번 프로젝트에서 무엇을 할지에 대한 것도 제대로 정리되지 않는 상황이 근 2~3개월 지속된 것입니다.
이번 프로젝트를 위해 이미 작년부터 투입되었던 기획자의 분석/설계는 제대로 진행되지 않았고, 이 분석/설계의 문제가 비로소 이번 프로젝트가 정식 출범한 시점부터 점점 크게 불거진 것입니다.
이 때문에 8월 저는 다음 프로젝트가 아닌 아번 프로젝트의 기획으로 롤이 변화되게 됩니다.
먼저 프로젝트에서 한 일
기획 롤이 변경된 이후 제가 가장 처음 한 일은 이전 기획자의 작업 내용을 파악하는 것이었습니다.
여기서도 문제가 생깁니다. 도대체 근 1년 가까이 무슨 일을 했는지 파악이 안 된다는 것입니다. 일단 구체적인 내용이 없다는 것과 이번 진행할 프로젝트를 정의/규정할 만한 내용이 없다는 것이 1차적으로 큰 문제였습니다.
그래서 이번 프로젝트 관련 계약서와 개발 관련 서류를 전달받아 분석하였습니다.
여기서도 문제가 또 발생합니다. 계약서 상에는 API를 중심으로 외부 시스템과 연동하는 개발이 정의되어 있었는데, 개발자들은 화면 개발로 이해하고 있다는 것이었습니다.
이에 대해 고객과 회의한 결과도 화면 개발은 관리자만 있고 고객 서비스용 화면은 없다는 것이 확인되었습니다.
그런데 연동 API 개발은 전혀 진행되고 있지도 않았고, 화면에 대한 작업만 일부 진행된 상황이었습니다. 이 화면 개발 또한 무엇을 하기 위한 화면인지가 없으므로 단순 회원 가입, 로그인 등 일반적인 개념적 사항만 있었습니다. 심지어 우리 화면 이용자는 누구이고, 회원 가입 관리를 위해 무엇이 필요하고, 가입에 어떤 목적성이 있는가에 대한 정의조차 없이 개발이 진행되고 있었습니다.
그래서 저는 가장 먼저,
- 이번 프로젝트의 개발 대상은 무엇인가?
- 이 개발을 통해 무엇을 서비스할 것인가?
- 누가 이용할 서비스인가?
등을 고객 미팅을 통해 정의해 나갔습니다.
이를 기반으로 프로젝트 진행을 위해 2가지 문서를 작성하였습니다.
- 정책 정의서 - 이번 프로젝트와 관련한 개념, 기능, 정책에 대한 기본 내용을 정리하여 모아 놓은 문서입니다. 프로젝트 정의서라고도 할 수 있습니다.
- 기능 목록 - 이번 프로젝트에서 개발해야 할 기능의 목록을 정리한 문서입니다.
기능 목록은 이후 WBS 작성의 기반이 됩니다. 프로젝트 PM이 제가 작성한 기능 목록을 바탕으로 WBS를 작성한 것입니다. WBS가 있기는 했지만 이때까지 실질적인 이번 프로젝트와 관련한 WBS가 없었다는 것을 의미합니다.
저는 PM이 아니고 단지 프로젝트 중간 교체 투입되는 프리랜서 기획자로 투입되었습니다. 그런데 제가 투입되어 기획 롤이 변경되기 전까지 무엇을 개발할지에 대한 정의조차 되지 않았던 것입니다. 그런데 개발은 진행되고 있었고, 매주 주간회의도 진행되었다는 점이 이 프로젝트가 가진 원초적 문제 지점입니다.
원초적 문제라 제가 지적하는 이유는 프로젝트를 많이 해 본 분이라면 이해하실 것입니다. 그리고 말도 안 된다고 생각할 수도 있지만 의외로 최근 IT 개발 프로젝트에서 이런 일은 자주 발생합니다.
이미 회사 대 회사 개념으로 계약되어 수개월 진행된 프로젝트는 일종의 관성이 생기게 됩니다. 이는 회사 대 회사의 책임 문제와 계약 상 신의 성실 문제, 담당자와 고객 간의 신뢰, 개발자의 지난 시간에 대한 매몰 비용 인식 등 다양한 요소와 결합하면서 발생하는 문제입니다. 이 때문에 흔히 문제를 덮고 가자는 식으로 분위기가 조성됩니다. 그러므로 중간 투입된 인력이 이를 다 처리해야 하는 상황이 됩니다.
이것이 원초적 문제가 되는 것은 쉽사리 언급할 수 없기에 해결이 어렵다는 것입니다. 저 역시 아무것도 안되어 있는 상태에서 기획을 진행하는 것이 불가능하므로 이 원초적 문제의 일부만 끄집어낸 것으로 분란이 일어나기도 했습니다.
여기에 더해 이번 프로젝트가 활용해야 할 근 1년 가까이 진행되었던 이전 프로젝트 결과에서도 문제가 있음을 알게 되었습니다. 심지어 기획을 위해 알아야 하는 이전 완료 프로젝트의 내용을 물어보았을 때도 대답을 듣지 못하는 일도 생겼습니다. PM도 문제가 있다고 나중에 말해 주었습니다.
더하여 기획을 위해 프로젝트와 개발의 대상을 정의하는 작업조차 기존 인력의 강력한 반대에 부딪치기도 했습니다. 기획을 하려 하면 기존 정책을 바꾼다는 저항이 발생되는 것이었습니다.
이때 기존 정책이 무엇인지 물어보면 대답이 없다는 것이 또 다른 문제로 등장하였습니다. 이미 까먹은 시간에 대한 유령이 미래로의 전진을 막고 있는 것입니다.
이런 일은 여러 사람이 함께 일을 하는 조직에서 종종 발생합니다. 일이 되어 가는 것으로 인해 과거 아무 일도 하지 않았다는 것이 밝혀지는 것이 타격이 되는 인력들이 정치적으로 일을 못하게 방해하는 것입니다. 다른 인력들은 이전 잘못된 기획/설계로 진행한 작업들을 수정해야 하는 것이 이들의 반응에 동조하게 만들게 됩니다.
간단한 기획적인 경험/인사이트를 통해 이런 조직 내/프로젝트 팀 내 발생 현상을 통해서도 지금까지 어떤 일을, 어떻게, 얼마큼 했는지도 대략적으로 유추해 볼 수 있습니다.
다음에서는 공개할 수 있는 수준에서 제가 작업한 것들을 간략히 공개하려 합니다. 현재 진행되는 프로젝트이므로 상세 내용은 지울 것입니다.
그래도 IT 프로젝트를 해 온 사람들이라는 무슨 문서인지 알 것이라 이 정도만 공개드리겠습니다.
이번 프로젝트 기획 문서 일부
IT 개발 프로젝트 기획자의 작업물 하면 대부분 스토리보드(화면설계서)를 떠올리실 수 있습니다. 그러나 스토리보드(화면설계서)를 작업하기 위해 사전에 다양한 기획 문서가 있어야 올바른 방향의 스토리보드(화면설계서)가 작성될 수 있습니다.
스토리보드(화면설계서) 공통과 표준을 정하는 것도 필요하지만 이 작업은 무엇을 스토리보드(화면설계서)화 해야 하는지 구체적으로 알아야 작업의 의미가 생깁니다. 무엇에 대한 화면 설계, 스토리보드인지도 모른 채 잡는 공통과 표준은 의미가 없기 때문입니다.
그나마 스토리보드(화면설계서) 공통과 표준을 할 수 있는 기획 리더(PL)이라면 다행입니다. 그냥 레퍼런스 또는 이전 시스템 보고 그대로 스토리보드(화면설계서)를 그리라는 기획 리더(PL)가 상당히 있다는 것은 공공연한 실무적 사실입니다. 제가 전달받은 프로젝트 상황은 딱 이 정도 수준도 안되었습니다.
그래서 먼저 이번 프로젝트 대상이 무엇인지, 개발 시스템 정책은 무엇인지를 정리해 나갔습니다. 이 문서가 바로 '정책 정의서'입니다. 이런 정책 정의서는 표준 양식은 없고, 프로젝트 상황이나 내용에 따라 작성하면 됩니다.
이 말은 이번 프로젝트 정책 정의서는 공개할 수 없다는 것입니다. 특히 이렇게 시작부터 문제가 있는 경우는 더욱 정해진 양식이 아니라 업무 파악을 위한 정의서가 됩니다. 엄밀히 '정책 정의서'라기보다는 '프로젝트 정의서'가 맞을 것입니다. 그래서 더 공개가 어렵습니다.
그래서 어느 정도 표준을 따르는 기능 목록부터 알아보겠습니다.
위 그림은 정책(프로젝트) 정의서를 바탕으로 뽑은 약 100개가 넘는 기능 목록의 일부 내용입니다.
제가 프로젝트 기획을 맡은 이후 기능 목록이 나오게 되면서, 비로소 그래도 좀 더 현실적인 WBS가 작성될 수 있게 됩니다. 심지어 이전 WBS는 프로젝트 계약의 내용과 연결되지 않는 것이었습니다.
이후 저는 화면 목록을 작성합니다.
이번 프로젝트의 사이트는 총 3개가 됩니다. 그리고 이런 화면 목록(정의서)도 각 사이트에 따라 3본이 작성됩니다.
사실 기능 목록(정의서)과 화면 목록(정의서)이 작성되기 앞서 정책(프로젝트) 정의서 사이 다른 문서들이 있었습니다. 이는 크게 서비스 구성도와 IA 자료입니다.
위 내용들은 대부분 아시는 내용이고, 왜 필요한지, 또한 어떻게 기능 목록(정의서), 화면 목록(정의서)과 이어지는지 IT 개발 프로젝트를 하다 보면 수 없이 반복 경험하므로 더 이상 글을 추가하지는 않겠습니다.
사실 먼저 비즈니스 구조(BA)와 업무별 프로세스를 먼저 해야 했으나, 세부적인 비즈니스 업무 흐름과 구조의 파악의 어려워 개발을 위한 설계를 먼저 진행하면서 정리하다 보니 조금 기획 과정이 꼬인 감이 없지 않아 있습니다.
이미 개발자들이 모두 투입된 상황에서 기획이 진행되지 않아 제가 교체 투입된 것이라, 기획을 하는 도중에도 개발자들의 요청이 많았습니다. 심지어 기획 내용을 고객과 협의 조정 하기 전에 개발자와 설계 협의가 아닌 작업 내용 전체 리뷰를 해야 해서 기획 진행은 더욱 지연되고 있는 상황이었습니다. 사전 투입 기획자와 개발자가 분석을 해놓지 않아서 개발자는 스토리보드를 보고 분석을 하는 상황인 것입니다.
여기에 문제는 비즈니스 로직의 진행이 다른 제휴 기업들과 연동되어 진행되어야 하는데, 이에 대한 분석이 안되어 있는 것뿐 아니라 개발적인 진행도 되지 않았다는 점입니다. 개발자는 스토리보드를 보고 연동을 이해하고 있었습니다. 물론 ASIS가 없다면 이해가 되나, ASIS가 존재하고, 이미 수개월 분석/설계 시간을 가졌다는 점입니다.
이번 프로젝트 비즈니스 로직과 연동에서 처리되는 데이터와 내용은 이미 이번 프로젝트 이전의 프로젝트에서 관련 진행이 완료되어 있어야 하는 사항이어습니다. 이번 프로젝트는 ASIS 시스템이 있었기 때문입니다.
그리고 이를 바탕으로 TOBE에서 추가 또는 변경 처리되어야 하는 부분만 보완하면 되는 것이었는데, 그냥 교체 투입되어 제가 처음부터 다 해야 하는 상황이었던 것입니다.
그러므로 이번 프로젝트에 해당하는 플랫폼 기획뿐 아니라 이미 이전 프로젝트에서 완료된 것으로 되어 있는 제휴기업과 연동해서 처리되어야 하는 업무와 데이터도 새롭게 기존 ASIS 시스템을 분석하여 작업해야 했습니다.
이에 제휴기업들과 협의 및 연동을 위한 업무내용 및 업무 처리 흐름도 설계하였습니다. 이 작업은 과거 설계를 하던 개발자가 작업한 시퀀스 다이터그램을 얼핏 보았던 기억을 떠올려 응용하였습니다. 일반적인 프로세스 작성 보다 더 효과적이라 생각되었기 때문입니다.
이는 이번 프로젝트에서 앞으로 개발될 플랫폼의 데이터, API의 기본 자료가 될 것입니다.
위 그림은 개발 플랫폼과 제휴업체가 처리하는 작업의 내용과 이를 위해 전달이 필요한 데이터를 정리한 자료입니다.
위 그림은 각 업무가 처리되는 흐름 및 입력, 처리 데이터의 내용입니다. 이러한 업무의 시작부터 끝의 흐름을 파악되는 처리 업무에 대해서 정리 작업을 하였습니다.
이외에도 화면 구성과 주요 데이터 등에 대한 자료를 작성하였습니다.
스토리보드(화면 설계) 작업은 주로 저와 함께 일을 하는 주니어 기획자가 작성하고 있습니다. 필요할 경우 저도 스토리보드(화면 설계) 작업을 하기는 하지만 주로 주니어 기획자가 많이 작성하고 있기는 합니다.
저의 경우 주로 BA, 시스템 설계, 업무 처리를 위한 연동 데이터, 정책 등에 대한 작업을 하고 있습니다.
이번 프로젝트에서 제가 하고 있는 기획에 대해서는 이 정도 설명으로 끝 마치겠습니다. 하고 있는 프로젝트라 더 말하는 것도 어려울 듯합니다.
이번 프로젝트에 전에 했었던 다른 프로젝트에서는 저는 주로 화면 설계서(스토리보드) 작성 업무를 하였습니다. 이 때도 아무 자료 없이 그냥 ASIS 화면을 보고 그리라고 해서 고생한 적이 있습니다. 그래서 이번 프로젝트에서는 스토리보드(화면 설계) 작업을 하는 주니어 기획자가 어떤, 무슨 스토리보드(화면 설계)를 작업해야 하는지 헷갈리지 않게 충분한 기획 자료를 작성하였습니다.
그리고 스토리보드(화면 설계) 작업 진행을 빠르게 하기 위해 저 또한 일부 화면 스토리보드(화면 설계) 작업은 함께 하고 있습니다.
'소개' 카테고리의 다른 글
| IT 기획 역량 소개 - 요즘 하고 있는 기획 (23) | 2024.09.22 |
|---|---|
| 보유 기획 기술 소개 (17) | 2024.09.18 |
| 온라인 서비스 기획자로 강점과 특징 (1) | 2024.08.17 |
| 온라인 서비스 기획에 있어 강점을 가진 이유 (0) | 2024.06.10 |
| 온라인 서비스 기획 상품 소개 (0) | 2024.06.05 |
댓글