서비스 기획의 업무절차
안녕하세요. 연두씨입니다.
서비스 기획을 하다보면 어떤 일관된 업무의 패턴이 있습니다. 자사 서비스를 하고 있는 회사에서 기획을 하고 있다면 운영업무든, 프로젝트든 이 패턴으로 계속 업무를 하시게 될 거에요. 웹에이전시도 수주를 위한 앞단의 작업이 추가 될 뿐이지, 실제 구축 시에는 비슷하게 업무를 하실 거에요.
첫번째. 요건 정리
이 과정에서는 ① 무엇을 위하여 ② 어떤 작업을 할 것인가 를 명확히 합니다.
프로젝트라면 시장조사, 벤치마킹, SWOT등의 조사와 분석을 하고 목표를 설정하여 컨셉을 정하고, 실행계획을 짜게 되고요, 일반적인 유지운영 업무라면 이 작업에 필요한 모든 배경 내용을 정리 하면 되겠습니다.
예를 들어, 휴면회원 처리를 개발한다면
1. 근거 법령
2. 우리회사 휴면회원 정책
3. 휴면회원 처리 로직 프로세스
를 정리하면 되겠습니다. 이 정리를 기획자 혼자 할 순 없고요, 이 업무에 배경이 되는 부서(IT외 영업팀이나 마케팅팀, 정보보안팀, 사업팀 등등)와 IT 각 파트가 모여 논의를 통해 정리 하면 되겠습니다.
이 때, 대략의 일정도 같이 논의 하세요. 어떤 방향을 어떻게 작업하겠다는 정리 아래 기획공수, 디자인공수, 퍼블리싱공수, 개발공수, 테스트 기간까지 잡으면 대략의 오픈일이 산출 될 거에요. 대략 잡은거니 나중 수정될 수 있는거 감안해주시고.
두번째. 상세 기획
요건을 정리하면서 논의한 디자인 방향이나 개발방법들이 있을거에요. 그 내용을 바탕으로 상세하게 기획을 합니다.이 과정에서 세세한 유저케이스, 서비스 플로우, UI&UX, 개발요건등이 나오게 되고, 그걸 다 정리하면 실제로 개발 되었을 때를 시물레이션 해볼 수 있습니다. 기획서 쓰고 디자인&퍼블리싱&개발과 논의하면서 시뮬레이션 해보고, 그럼 수정이나 보완 사항들이 나올거에요. 그거 추가해서 다시 기획서 쓰고 시뮬레이션 해보고, 쓰고 해보고 쓰고 해보고 계속해서 우리 모두 검토한 기획서가 완성되면 되요. 이 과정에서 상세한 작업분량을 예측할 수 있게 됩니다.
휴면회원에 대해 기획서를 쓰면, 휴면인 상태의 회원이 로그인을 했을 때 화면>휴면해제를 위한 화면>등으로 시나리오를 화면화면 그리다 보면 디자인 및 퍼블리싱을 해야 할 본수를 확인 할 수 있게 됩니다. 또 각 화면 때마다 뱉어내는 값, 제어하는 값들을 정리하면 개발 및 DB에서 해야 할 작업 요건들이 세세히 정리가 되고요.
세번째. 일정 계획
상세 기획을 하면서 각 파트들과 상세한 요건을 확인하고 작업 범위가 확인되었으니 처음 요건 정리 할 떄 보다 세세히 일정을 짤 수 있습니다. 이 때 WBS를 작성하게 되고, 이 작업 외 다른 작업과의 영향도 미리 체크 할 수 있습니다. 여기서도 논의가 계속 되어야 하는데, 우리는 거의 대부분 없는 일정에 많은 일을 해야 하므로 구간별로 조금씩 일정을 더 보수적으로 계획하기도 더 버퍼를 두기도, 혹은 서로 합의 하에 업무 순서를 바뀌기도합니다. 이렇게 최종 일정이 계획되면, 확정된 오픈일이 나오게 됩니다.
보통 이 시점에서 업무에 배경이 되는 부서 또는 요청한 부서, 부서장, 대표님, 클라이언트등에 요건+기획+일정을 합쳐서 보고하게 됩니다. 이 전후로도 보고를 하지만, 이 때가...뭐랄까, 어떤 업무나 프로젝트를 할 때 확실한 보고 시점이 되는 것 같아요.
저는 개인적으로 이 때가 제일 좋아요. 보고해서 좋은 건 아니고, 우리 모두의 설계와 검토가 다 끝나고 이제 이대로 하기만 하면 될 때! 이 때가 뭔가 흐릿했던게 다 명확해지는 때라 그런지 좋더라고요. 뭔가 같이 작업 하는 사람들끼리 거대한 모험을 앞두고 동질감?? 끈끈한 의리?? 같은것도 생기게 되는거 같고요.
네번째. 일정 관리 & 리스크 관리
계획한 대로 이제 디자인-퍼블리싱-개발 작업을 하게 되는데요, 여기서 기획자들은 여러가지를 확인하고, 추가정리하고, 커뮤니케이션 하게 되는데 이걸 그냥 퉁쳐서 관리라고 할께요.
크게 일정과 리스크를 관리하게 되는데요.WBS를 기준으로 혹시 딜레이 되는 구간은 없는지, 오픈일을 기점으로 현재까지의 예상 진척율에 문제는 없는지 체크하고, 계획보다 빠른거야 문제 없겠지만 느리다면 그대로 가다가 뒤에 테스트를 못하거나 오픈이 딜레이 될 수 있으니 미리미리 조치를 해야 합니다.
또, 작업 하다보면 예상치 못한 이슈가 발생 될 수 있는데요. 예를 들면 생각했던 개발방법으로는 안되서 방법을 바꿔야 하거나 어떤 문제가 생겨서 요건 자체를 중간에 바꿔야한다거나 등의 일이 발생되면 수정/보완한 내용을 추가로 협의하고 정리,공유해야 합니다. 그에 따른 일정도 같이 고려 하고요. 오픈 전까지 이 퉁쳐서 관리라고 부르는 업무는 계속하게 됩니다.
다섯번째. 테스트 및 오픈
어찌어찌하여 얼추 개발이 다 되어 간다면 이제 오픈 준비를 하면 됩니다.테스트 케이스, 오픈시나리오, 오픈 후 사용자 가이드가 필요하면 사용자 가이드, 오픈 후 특별히 공지사항을 올릴거면 공지사항 내용 작성 등 오픈에 필요한 모든 만반의 준비를 하면 됩니다.
큰 프로젝트가 아닌 유지운영 성 업무라면 담당기획자가 테스트하고 제때 맞춰 적용 프로세스를 태우면 되겠습니다.
다시 한번 정리하면,
무슨 일을 하게 되든... 제일 처음에는 무엇을 목표로 어떤 작업을 할 것인지 명확히 하는 것 부터 하면 됩니다. 그 이후에 세세히 설계하고 논의 해서 기획하고, 기획 바탕으로 일정 짜고, 일정 내내 문제는 없는지 계속 체크하고 오픈 하면 됩니다. 그러고 나면 또 다시 요건을 명확히 하는 걸로 새로운 업무를 혹은 새로운 프로젝트를 시작하게 되고.
굳이 다섯가지로 나누어서 정리 하였으나, 일반적으로 개선 및 장애 대응등에 대한 운영성 업무에서는 이 모든걸 거의 한 큐에 다 하게 됩니다.
예를 들어 기능 오류를 발견하게되면 개발자와 바로 내용 확인 하고 화면이 필요하면 그리고 화면조차 필요 없는 경우 텍스트로 해당 내용 정리해서 개발에 전달하고 언제까지 수정할 수 있는지 물어보고 개발 다 되면 테스트하고 적용하게 됩니다.
개선의 경우는 개선할 내용들을 정리하고 작업자들과 논의해서 기획서-일정 짜서 작업 하되, 진행하고 있는 다른 업무들이 있으니 전체 작업할 건들의 우선순위까지 고려해서 일정을 정리하면 되겠습니다. 이거 끝나면 저거하고, 저거랑 저거는 영향도가 있으니 같이 하고..뭐 이런 식의 정리.
프로젝트는 각 단계에 고려해야 할 사항과 작업 분량이 많으니 각 단계를 더 deep하게 논의하고 정리하시면 될 것 같아요.
