앱잼때는 바빠서. 앱잼이후에는 기팟장과 임원진일, 그리고 다시 시작된 릴리즈 준비, 3주간의 휴가를 끝내고 돌아와 다시하는 공익근무로 정말 쉴틈없이 살아서 블로그를 멈추고 있었다. 물론 이 릴리즈 회고 내용에 앞서서 적을 내용들이 많지만(기디 팀빌딩 후 작업내용, 앱잼 3주간 첫 개발자와의 협업 내용, 릴리즈 준비과정에서 주차별 느낀점 등) 일단 릴리즈회고를 한 직후의 것들을 바탕으로 까먹기 전에 적어보고 싶어서 이렇게 글을 적게 되었다. 또, 피드백을 받았던 것중에 정말 고쳐야 겠다고 느꼈던 것도, 꼭 기억해야겠는 피드백도 있었기에 글로써 내 감정을 정리해나가고, 좀 더 기억해나가려 한다.
글은 아래 순서로 진행될 것이며, 1. 좋았던 점과 2. 아쉬웠던 점 같은 경우에는
1)내가 회고내용으로 적은 것, 2)타인이 나에게 적은 것 3)기타 사항 으로 소항목을 나눠서 진행해보려 한다.
1. 좋았던점
2. 아쉬웠던 점 & 개선방향
3. 기타 느낀점 및 하고 싶은 말
1. 좋았던 점
1) 내가 적은 것
1. 팀이 처음에 정한 타임라인을 지킬 수 있던 것
처음에 기획경선에 나갔을 때부터, 4월 초 전엔 릴리즈가 목표였다. 실제 솝트에서 나온 앱서비스의 경우, 아무리 빨라도 신학기 시작후 거의 1달반 이후에 (지금으로 따지자면, 4월달은 넘어야) 앱잼 팀 중 첫 서비스가 릴리즈 됐었다. 29기때 키핀이 제일 빨리 나왔는데 약 11월달 정도 였었다.(1학기 기준 5월 경). 그나마 빠른 나머지 팀들도, 다음기수가 끝나기 전 릴리즈가 되는게 빨리 나오는 편이었던걸로 기억한다.
그래서 3월 내 릴리즈라는 목표를 처음 기획경선에서 세웠을 때도, 앱잼이 끝나고 다시 이 목표를 설정했을 때도 과연될까? 라는 걱정이 조금 있긴 했다.
하지만, 팀원들 모두가 이 일정에 대한 인지를 계속 하고 있었고, 이 일정을 이룰 수 있게 분위기가 만들어졌던 거 같고, 어찌보면 좀 불가능해 보이고 타이트한 일정이더라도 한번 해보자 하게 되는 결과가 나왔던 거 같다. 또한, 욕심을 내고 싶은 부분들이 각 파트에 있을 수 있지만, 그것보단 가장 유저입장에서 핵심적인 기능위주로 서비스를 구성하려 노력했던 것 같다. 우리팀에 한정된 기한이 있으니까!
기획자로서 메인 PM으로서 가장 중요한게 어찌보면 팀의 일정, Product 일정을 수립하고 그 목표를 향해 팀원들이 같이 나아가게 하는것. 처음에 정한 Product 일정 및 목표를 팀원전체가 인지하게 하고 이를 기한내에 이루는 게 중요하다고 생각하는데, 이 기한을 지켰다는 점에선 어느정도 성공을 한 것 같다.
(물론 뒤에 서술 하겠지만, 이렇게 진행하는 과정에서 문제점도 있었다..)
2. 기획자 뿐만이 아닌, 개발 디자이너들도 기획에 대해 같이 고민할 수 있는 팀분위기
물론 이부분에 대해선 뒤에서도 서술하겠지만, 장- 단이 같이 존재했던 부분인거 같다.
그래도 장점을 먼저 서술하자면
앱잼때까진, 내가 먼저 짜온 기획에 대해 납득을 하고 진행을 하는 편이었다면,
릴리즈를 진행하는 과정에선 개발자들도 디자이너들도 지속적으로 만드는 과정에서 생긴 의문이나, 더 좋은 방향에 대해 제시를 많이 해줬던 거 같다.
예전 앱잼땐, 개발자들의 분위기가 "기획이 많이 고민한걸텐데 내가 기획의 역할을 침범, 권리 침범하는 거 아닌가?" 라고 생각 하면서 질문에 대해 많이 주저를 하는 분위기가 초반부에 있었다. 하지만 계속 슬랙을 통해서든, 갠톡을 통해서든 회의를 통해서든 이런 상황들이 나올 때 오히려 좋고, 고맙다고 어필하려 했던 거 같다.
어쨌든 내가 혼자하는 서비스가 아닌, 혼자하는 기획이 아닌 "우리팀 전체"가 만들어나가는 것이라고 생각했기 때문에!
항상 생각하지만, 기획이라는 것이 처음 기획자의 머리에서 기획했을때와 실제 만드는 과정에서만 알 수 있는 부분들이 다르다고 생각한다. 그렇기 때문에 실제 이 Product을 만드는 주체인 개발자 디자이너 단에서 작업을 시작해야 알 수 있는 부분들(사용성 측면이든, 세부적인 기능 구현 측면이든) 이 있다고 생각하고, 그 과정에서 생각나는 기획적인 부분, 의문들을 자유롭게 제안하고, 그에 따라 유연하게 기획을 변경하고, 논의할 수 있는 것은 중요하다고 생각한다.
또, 기획자는 자신의 기획에 대해 더 고일수(?) 밖에 없는 존재라고 생각한다. 그렇기에 기획에 대한 제3자의 시선은 언제나 필요하다고 생각하기에, 개발자, 디자이너와 같이 상대적으로 이 서비스의 기획에 대해 덜 고인(?) 사람들의 시선이 어찌보면 사용자의 시선에 더 가깝기에, 이에 대해서 많이 들을 수 있을수록 좋다고 생각한다.
그리고, 어찌보면 기획 디자인 개발로 포지션이 나눠져 있긴 하지만, 결국엔 서비스의성공, 좋은 서비스를 만드는 것이라는데에선 목표를 같이하고 있다고 생각한다. 그런 면에 있어서, 단순 주어진대로 디자인 개발하는 것이 아닌 "더 좋은 서비스는 뭘까? 더 좋은 방식은 뭘까? 사용자라면 어떻게 할까?" 라는 시각은 기획외의 다른 포지션의 팀원들에게도 필요한 시야라고 생각하고, 이렇게 됐을때 더 좋은 팀, 더 좋은 서비스가 만들어진다고 생각한다. 이번 앱잼이후 릴리즈 준비에선 이런부분, 이런 분위기가 그래도 이전에 비해 만들어진 거 같아서 다행이라고 생각했고, 이런 분위기를 만들기 위해서 노력했던 과정들이 그래도 의미가 있었구나 라는 생각이 들었다.
서비스에 대해 같이 고민하고 토론할 수 있는 분위기를 만들었다는 점에선 그래도 잘한 부분이라 생각한다.
아래 사진이 그 하나의 예시인데, 우리 서비스의 후기탭에서의 필터기능이 다른 서비스와는 조금 다른 형태로 움직이고 있었다. 이부분에 대해, 기획적인 변경이 필요하지 않을까? 라는 개발단에서의 의견이 나왔었다.
이에 대해 가볍게 응 아니! 우리는 이런 의도로 기획해서 안돼! 라고 짧게 대답할 수도 있었겠지만
이렇게 개발자들이 먼저 의문을 가지고 제안을 해줬다는 것은 그만큼 왜 이렇게 기획을 했는지에 대한 기획의도를 잘 전달할 의무가 있다고 생각했고(설득을 떠나서)
그래서 답하는 데 좀 시간이 걸리더라도, 아래 사진 처럼 노션에
1) 우리서비스에서 필터기능을 쓰는 이유 2) 다른 서비스들이 우리서비스와 다른 필터 기능을 가지고 있는 이유 3)부가적인 이유를 여러 레퍼를 예시로 들면서 정리 및 전달하려 했다.
이런 일련의 과정들이 하나씩 모여서, 개발자들이 좀 더 기획을 믿을 수 있는 그리고 좀 더 편하게 질문할 수 있는 분위기가 만들어진다고 생각한다.
3. 앱잼이 끝나고 합숙하는 와중이 아님에도, 다들 열심히 참여한것. 소통도 잘된 것
가장 걱정했던 부분이, 앱잼처럼 합숙을 하는 것도 아니고, 여기에 앱잼처럼 투입할 수 있는게 아닌 사이드로 하는 상황에서, 이전과 팀분위기가 달라지거나 열정도가 크게 차이나면 어쩌나 였다.
그런데 앱잼과 큰 격차를 느끼지 못했던 거 같다.
물론, 완전 여기에만 투입할때와는 달랐겠지만, 슬랙으로의 소통에도 큰 문제가 없었으며,
처음 릴리즈 개발을 시작할때부터 <시작과 끝> 채널의 중요성을 더 부탁드렸었다. 각자 개인 일정이 있다면 그걸 기입해줌으로써, 아 이친구 오늘 뭐있으니 연락이 안되겠구나 등을 파악할 수 있도록. 이 점이 잘 적용됐던 것.
그리고 팀원들도, 단순 우리 목표는 앱잼 잘해내는게 아니라 릴리즈까지 잘 마무리하는 것이라는 목표가 있었기에, 서로 의쌰의쌰 하면서 잘 마무리 했던 거 같다.
이 부분도 장단이 공존하긴 했다. 뒤에서 서술 하겠다
4. 같은 기획인 영훈이형과의 파트 분배
앱잼 때는 계속 같이 붙어있었고, 실시간으로 역할 분배가 가능했기에, 조금 비효율적이게 움직이긴 했었다.
(비효율적이라기 보단, 그때 그때 할일을 분배해서 나눴던 듯)
하지만 앱잼이후 릴리즈 준비 단계에선, 좀 더 효율적인 분배가 필요하다 생각했다. 형도 인턴을 하게 되었고, 나도 임원진 일, 공익일로 안바쁜 상황은 아니었으니까. 그로 인해 그렇게 자주 회의할 수 있는 상황이 아니었기에.
아예 프로덕트/ 지원사업 등의 것은 내가 책임자로서 진행을 맡고, 마케팅/데이터 분석을 영훈이형이 책임자로 진행하도록 했었다. 예전에 프루팅을 할때도, 회장단을 할때도 각 책임자로 역할을 맡겨 각자 주체성을 가지고, 업무 분배를 시도하고, 업무공유를 할시 좀 더 효율적인 시간관리도 가능하고 각 팀원의 주체성 및 효율성도 높아지는 것을 알았기에 다음과 같이 나눴던 거 같다.
확실히 이렇게 진행한 것이 효율적이었고, 다 해보고싶다. 다 주도해서 하고 싶다라는 욕심을 부리는 것보다 이렇게 진행하는 것의 효율성을 다시한 번 느꼈던 거 같다.
실제로 각자가 좀 더 전문성을 나눠서 일할 수 있었고 그 부분들이 프로덕트 전체적으로 좋은 방향이 되었던 것 같다.
5. 여러가지 기획 관련 경험을 해볼 수 있던것. 확실히 성장했다. 하지만, 많이 미흡했었다.
1) 서비스 이용약관, 개인정보 처리방침
이런 서비스 릴리즈를 위해서 꼭 필요하지만, 어떻게 되는지를 잘 모르기도 하는, 이것도 기획의 역할이야? 싶기도 한 것들을 직접 주도해서 만들어봤었다. 구글링도 하고 타 서비스 레퍼를 참고하면서, 실제 약관을 작성해보며, 아 실제 서비스들은 이런점 까지 고려하는 구나, 아 이서비스는 약관 ux 라이팅에서도 이런 무드를 느끼게 할라고 어투와 그래픽까지 이렇게 쓰는구나. 각 앱의 카테고리에 따라서도, 약관에 추가적으로 쓰는 항목들이나 어투도 엄청 다르구나를 많이 배웠다. 완전 어투까지 신경써서 만들지는 못했지만, 이 프로세스가 어떻게 이뤄지는지 알게된 것만으로도 타 기획자는 못해본 경험들을 해봤다고 생각한다.
2) QA (개선해야할 사항들을 많이 느꼈던..)
앱잼땐 후다닥, 하기도 했고 큼직큼직한게 잘 돌아가나 위주로 봤었는데, 실제 앱출시를 위해 QA 사항을 작성하는 과정을 거치게 되었다. 이 과정에서 처음엔 그렇게 까지 효율적이진 못했는데, 성공적인 QA가 되기 위해선 어떻게 해야하나를 조금 많이 느꼈던 거 같다.
실제 어떤 부분을 어떻게 고쳐줬으면 하는지를 잘 표현하기 위한 형식적인 측면 뿐 아니라, QA 사항들의 우선순위를 잘 지정하는 것의 중요성, 또 회고를 하면서 또 느꼈지만 QA는 사용성을 개선하기 위해 기능추가가 아니라 버그수정이라는 것.
최대한 버그수정에 가깝게 하려고 했지만, 그 과정에서 계속 미세하게 기능이 추가 됐던 거 같다. 물론 그과정에서 개발자들의 동의 없이 이뤄진 것은 아니었지만, 동의를 하긴했어도 그렇게 좀씩좀씩 추가되는 상황들이 달갑진 않았으리라 생각된다. 이런 QA가 처음이었고, 서비스를 내는게 처음이었기에 어찌보면 무지와 더 좋은 서비스가 됐으면 하는 욕심이 생겨서 그런 결과가 나왔다고 생각한다.
솔직히 QA라는 시스템 자체가 개발을 미흡하게 한 부분, 기획의도를 반영 못한 부분이 들춰지는 것인데 그것자체가 쉽진 않을거라 생각한다. 내가 개발자라고 생각하면, 물론 QA해주는게 고맙긴하지만, 이것까지 해야해? 라는 생각도 들었을 거 같다. 좋은 의도로 해준 피드백도 그걸 달게 받아들이는게 사람인지라 쉽지 않은건데, 어찌보면 자신의 결과물에 대한 이렇게 바꿔주세요, 이거 잘못됐어요 하는 피드백이
QA의 본질은 무엇인지, 더 효율적인 QA 방식은 뭘지, 또 개발자들의 입장에선 이 QA라는게 어떨지를 좀 더 생각해보게 되는 계기였던 거 같다.
3) 각종 정책
내가 만드는 앱이 커뮤니티 앱이다 보니, 신고,차단 등이 필수로 들어갔어야 했고, 또 후기를 작성했냐를 기준으로 권한을 나눠야 했기에 그부분에 대해서 정말 많이 고민하고 케이스들을 나누고 정책을 짜내려갔던 거 같다.
실제 이렇게 진행했을때 예외케이스는 없을지 정말 많이 고민을 했었고, 한번 짰어도 어 근데 이런경우는 어떻게라고 서버개발자가 질문을 날리면 그에 맞춰서 적절히 변경하는 과정이 어려웠다.
또 이게 각각 따로노는 정책이 아니라 서로 맞물려 있고, 기능들이 맞물려 있다 보니, 뭘 못하게 한다 했을때 어 그럼 이거 알림탭에서도 글로 못들어가게 만들어야겠네, 이땐 그럼 어떤 알럿창을 띄우지 등등 의 것들이 많았다.
단순히 신고하고 땡이 아니라, 그럼 그 유저에게 신고당한걸 언제 어떻게 보여줄거고, 언제까지 신고처리가 되며, 무엇을 못하게하고 무엇을 하게 할건지, 그게 기존에 있는 정책이나 방식과 충돌하진 않은지, 정책끼리 겹칠떈 뭘 우선시 할건지 등등. 많은 어려움들이 있었던 거 같다.
하면서, 와 커뮤니티앱 이래서 하지 말라그러는건가 싶기도 했었는데, 그래도 이정도 규모, 이정도 복잡성을 가진 앱을 기획해볼 기회가 있었다는게 참 다행히 였다 라는 거 같다. 그 과정에서 여러 커뮤니티 앱서비스들도 많이 공부하게 됐던 거 같고.
4) 온보딩 화면 기획, 랜딩페이지 기획, hotjar GA를 활용한 데이터분석, 앱 핵심 성과지표 공부, 각종 컨택문구작성, 앱심사시 필요사항 서치 및 작성, 초기마케팅 작업을 체계적으로 하는법, ASO, 앱단축링크 통한 유입분석
이런 자잘하다고 보면 자잘할 수 있지만 정말 많은 것들을 배우고 시도해볼 수 있었다.
각각에 대해선 기회가 되면 정리한 블로그글을 따로 써보려 한다. 그중 몇가지만 간략히 적어보겠다.
특히 데이터 기반 의사결정 과정
랜딩페이지를 설계- 배포하는 하는 과정에서 GA, hotjar를 잘 활용했다.
퍼널설계, 인스타 유료광고 집행에 GA, hotjar를 통한 히트맵 분석 등을 바탕으로 데이터 기반의사결정을 내릴 수 있던 것. 유료광고 효율보다, 인스타 선팔작업의 효율이 좋다는 것도 볼 수 있었고, 실제 CTA 전환율이 어느정도 찍히는 지 보면서 처음에 설계한 퍼널이 어느정도로 찍히는지 알수 있었다.(찐 xyz가설로 수요검증 해보는 경험)
5) 앱잼 때와는 달리 이슈용 칸반을 활용했다.
앱잼 때는 기능명세서에 계속 업데이트 사항을 정리하고, 색깔 표시를 통해 변경사항을 정리하려 했다. + 슬랙공지
이 방식의 경우 물론 한 문서에 정리되는 장점은 있었으나, 왜 이런 사항이 나왔는지, 현재 어떻게 진행되고 있는지 누가 이 사항을 알아야하는지에 대해서 파악이 어려웠었다. 실제 재용이형 팀에선 이런식으로 일을 진행한다는 것을 앱잼 이후 메인 PM 회고에서 알 수 있었고 이부분을 적용해보려 했던 것 같다.
실제 뭔가의 변경사항, 질문사항과 같은 이슈가 생겼을때, 작업상태, 담당자, 뷰, 뷰 상세, 담당 파트 등을 표기한 칸반 및 표를 통해 해당 내용을 정리하려 했다. 이런 부분이 편했던 부분도 있지만, 원하는 정보를 찾기 어려울 때나 한 기능에 대한 내용이 분산되어 저장될 때도 있었던 것 같다.
그래서 다음 부턴 실제 정책과 같은 부분들은 언제든지 찾기 쉽게 별도의 하나의 통합된 문서에 저장하는 방식이 필요하다고 생각했으며, 이슈용칸반에 올려 두더라도, 최종적으로는 하나의 문서에서 특정 기능 개발시 참조하기 쉽게 만드는 것이 필요하다고 생각한다. (아마 스토리 보드 형태가 될 듯하다. 뷰 옆에 기능명세를 적는 방식)
이미 디자인 뷰는 다 나온 상황에서 추가적인 변동이나, 정책적인 부분의 진행만을 이번 릴리즈시에 진행했기에 이런 스토리보드 형태를 추가적으로 만들진 않았지만
이제 추가적인 기능 업데이트/개편을 하게 되는 상황에선 좀 더 발전된 형태의 기획문서를 작성해보려 한다.
결국 기획문서는 개발자들이 "개발을 하기 편한방식"으로 만들어져야 하니까!
이내용이 어디에 있지 하면서 찾지 않도록 최대한 효율적인 문서를 작성해보려 노력해야겠다고 느꼈다.
2) 남이 적어준 내용
1. 슬랙 및 노션을 잘 활용 -디잔
:슬랙에서 회의하고 노션에 꼼꼼히 정리해줘서 왜 이게 이렇게 된 것인지에 대해 이해가 잘 되었다고 적어줌.
최대한 결정사항 뿐 아니라, 실제 슬랙 대화내용도 링크로 걸고, 논의 배경 및 결론이 도출된 로직을 정리해주려 했던 것 같다. 이 부분을 좋게 봐준 거 같다.
2. 근거와 이유있게 기획 설명(문서화를 통해) -아요
: 왜 이런 기획이 나왔는지에 대해 최대한 문서화를 통해 이유와 근거를 가지고 해줘서 좋았다
아마 위에서 언급했던 후기 필터 사례 같은 부분일 것 같다. 그 외에도, 슬랙에서 나오는 질문 하나하나에 최대한 성심성의껏 이유를 설명해주려고 혹은 이유를 같이 만들어가려고 했다.
3. 개발자 의견을 들어주려고 하고, 기술적인 부분에 대해 이해하려고 노력하는 점- 아요
실제로 슬랙에서 뭔가의 질문이 들어왔을때도, 기술적으로 각 구현방식의 난이도 차이와, 현실적인 마감기한, 각각의 방식으로 구현했을때의 장단 등을 따지려 했던 거 같고, 기한이 타이트한 만큼 이 기능구현이 필수적인지를 계속해서 점검했던 거 같다. 이렇게 최대한 물어봐가면서 해나간 부분을 좋게 봐준것이라고 생각한다.
4. 확정된 부분이라도 자유롭게 의견 나눌 수 있어서 좋았다, 궁금한것들 자유롭게 의견 공유할 수 있는 분위기 - 안드
실제 기획적으로 픽스 되었더라도, 이대로 무조건 가야해가 아니라 상황에 따라 유연하게 변동할 부분은
5. 정리된 노션글 놓쳐도 슬랙으로 리마인드 해줬을 때 있어서 좋았다 -안드
만약 이슈용칸반에 정리를 해뒀다 하더라도, 이런식으로 지속적으로 변경사항을 슬랙으로 재 리마인드 해주는 작업이 필요하다고 느꼈다. 혹은 노션에 이번주 변경사항, 몇일자 변경사항! 등을 적어놓는 공간을 만들어두는 것도 좋겠다는 생각이 든다. 이부분 추후 기능 업데이트 할때 해봐야지!
여기까지 좋았던 점에 대한 것을 기록해봤다. 한 글로 써볼라고도 했는데, 생각보다 분량이 많아서.. 아쉬웠던 점 관련 내용은 다음 "하"편에 이어서 작성해보려 한다.
'SOPT(IT 연합동아리)- Side project(나도선배)' 카테고리의 다른 글
| [SOPT] 나도선배 릴리즈 회고(하) - 아쉬웠던 점, 개선점 중심 (1) | 2022.05.25 |
|---|---|
| [SOPT] 나도선배 앱잼 회고 3_개발자 팀빌딩 (1) | 2022.05.25 |
| [SOPT] 나도선배 앱잼 회고 2_기-디 브랜딩 기간(2주) (0) | 2022.05.25 |
| [SOPT] 나도선배 앱잼 회고 1_기-디 팀빌딩 (0) | 2022.04.14 |
| [SOPT] 기획경선 준비 및 합격 (0) | 2021.12.16 |