끝은 새로운 시작

기획자 입장에서 프로젝트가 끝나가면 초조해집니다.
프로젝트의 끝은 새로운 프로젝트의 기획 마감과도 같기 때문입니다.
만일 기획이 완료되어 있지 않으면?
그렇습니다.
한순간에 바로 업무의 바틀넥이 되는거지요.
서둘러 끝내야 합니다.
이번 프로젝트는 지난 프로젝트들을 통해 얻은 레쓴런을 기반으로 기획을 진행하고 있습니다.

1. 기획에 더 많은 시간 투자

리소스를 아끼는 것에서부터 갈등이 시작됩니다.
막상 개발에 착수하면 어차피 수정이 불가피한데, 지금 한번 보고 두 번 보는 게, 미래의 작업량을 얼마나 줄여줄까?
담보되지 않은 미래를 위해 얼마큼의 시간을 할애할지 가늠이 되지 않습니다.
솔직한 마음으로는 어림짐작이라고 생각하기도 하는 것 같아요.

기획은 유저의 행동을 예측하고 길을 만드는 일이라고 생각하는데요.
예측의 시간이 길어지면 보완을 하고 있는 건지 겐또를 하고 있는 건지 아리송해지는 시기가 옵니다.
그럴 때마다 만들면서 고치는 게 효율일 거라고 생각하게 됩니다.
이번에는 그러지 않기로 했습니다.

2. 관리자 기획

기획에 더 많은 시간을 투자하는 것의 일환입니다.
이번엔 관리자도 픽스를 하고 프로젝트에 착수할 예정입니다.
관리자 페이지는 저희가 운영을 하는 거니까 더더욱 기획을 하지 않았습니다.
최대한 적은 리소스로 운영하는 게 맞다고 생각했어요.

이것 역시 시행착오를 겪게 됩니다.
운영을 하다 보니 불편한 것들이 많았습니다.
운영으로 풀 수 있는 문제도 개발팀에 부탁할 일이 많았습니다.
그러다가 급기야 관리자 페이지를 서비스급으로 기획해서 만들기에 이르렀어요.
그렇게 만든 관리자 페이지는 편했냐고요?
당연히 그렇지 않았습니다.

관리자는 운영 관점으로 모든 액션이 액션 단위로 나눠져 있어야 하는데요.
그때 해본 기획이라고는 서비스 기획뿐이었으니 관리자를 서비스처럼 기획했었습니다.
서비스는 모든 액션이 유기적으로 연결되어 있고요.
그랬더니 환불이라도 하나 할라치면 엮여있는 것들을 하나하나 따라가서 찾아서 조치를 해야 합니다.
그렇게 현재 구관리자와 신관리자를 모두 쓰고 있어요…ㅎ
어떤 방법론을 채택해야 하는지도 배웠으니..
이번엔 부디 한 관리자 페이지에서, 개발팀에게 많은 요청을 하지 않고, 운영할 수 있길 기대하고 있습니다.

3. 앱과의 병행 X

대혼란을 한 번으로 퉁치겠다는 효율(?)적인 마인드로 비효율을 가중시킵니다.
기왕 만들 때 한 번에 만들어야 한다고 생각했습니다.
기준점이 없는 상태에서 다양한 형태로 구성하다 보면 당연히 정책이 꼬일 수밖에 없습니다.
어떨 땐 웹에 맞추는 게 좋고 어떨 땐 앱에 맞추면 좋은 게 있으니까요.

웹에서는 긴 설명의 경우 i 아이콘을 두고 마우스 호버 하면 툴팁이 뜨는 형태로 처리하곤 하는데요.
앱에서는 마우스가 없으니 호버도 할 수 없습니다.
설명을 간결하게 줄여서 명시해두는 방법밖에 없습니다.
앱을 해두고 나면 웹도 그냥 앱에 맞춰 설명을 명시하는 게 좋아 보입니다.
정책을 통일하는 게 좋기도 하고요.
웹이 이미 유저에게 오픈 된 상태면 건들지 말자는 합리화가 되는데요.
만드는 중일 때는 그게 쉽지 않습니다.

QA도 오히려 더 늘어지는 것 같아요.
웹을 봤다, 앱을 봤다, 웹은 어떻게 되어야 했더라, 앱은 어떻게 되어야 했더라, 계속 모드전환을 해야 합니다.
만들 때맞다고 생각됐던 정책이 막상 쓸 때는 안 맞기도 하고요.
웹 정책과 앱 정책을 같이 갈지 따로 갈지 판단의 경우의 수가 많아집니다.

이 모든 걸 차치하고도 앱을 만들었던 건 동시 출시를 위함이었습니다.
어차피 출시할건데, 늦게 출시하면 좋은 이유가 없는데, 어떤 명분으로 출시를 미뤄야 하나?
이젠 경험으로 압니다.
이번엔 늦더라도 천천히 하나씩 해볼 생각입니다.

돌이켜보면 모든 시행착오는 결국 최대한 빨리 만들고 싶다는 조급함에서 비롯된 것 같아요.
시간을 아끼려다 오히려 더 많은 시간을 쓰게 된 경험이 쌓이니, 이제야 조금은 알 것 같습니다.
그렇다면 최소한 반복되는 실수는 줄여야겠죠.
이번 글은 그 다짐을 기록해두는 메모라고 생각해 주시면 될 것 같아요.
브랜뉴 필름업을 위하여~

---