[SOPT] 나도선배 릴리즈 회고(하) - 아쉬웠던 점, 개선점 중심
이전 회고 글에선 좋았던 점 중심의 글이었다면, 이번엔 팀원들이 말했던 아쉬웠던 점들 바탕으로 어떻게 개선해야할지를 적어보고자 한다. 팀원들이 언급한 아쉬운점을 먼저 말하겠다.
2. 아쉬웠던 점 및 개선점
1) 팀원들이 언급한 아쉬운점
1. 첫 릴리즈 목표로 잡은 범위가 있는데, 릴리즈 후 추가업데이트를 결정하는 상황에서의 미숙함.
실제 피드백 내용:
- 릴리즈가 됐는데 릴리즈 직후 나온 피드백을 바탕으로 추가업데이트를 빠르게 결정했던 것.
- 릴리즈 이전에 기획적으로 고민되는 것들을 팀내에서 같이 고민하고 갔다면?(이걸 같이 고민하고, 서비스에 대해 점검하는 시간을 가졌다면, 베타테스트를 진행해서 사용자의 의견 들어보는 방법 있었을 것)
- 예측으로 기획한 것이 실패하더래도, 이를 뒷받침하는 근거나 이유에 대해 오래 고민해 보는 문화가 됐으면 좋겠다.
- 기획적, 서비스적인 부분도 중요하지만, 코드에 대한 유용성을 고민해서 매끄러운 서비스 되도록, 개발자 작업시간 보장. 모두가 충분히 고민하고 서비스 만들 수 있을 스케줄 잡기
- 이젠 좀 더 기획-> 디자인-> 점검-> 개발의 프로세스로 개발했으면 좋겠다.
느낀점 및 개선할점:
1) 릴리즈 이전에 기획적인 애매함을 검증할 수 있는 방법들이 더 있었을 텐데 이걸 검증하지 못했던 점
아마 이런 피드백이 나왔던 가장 큰 이유가 1차 릴리즈는 3월 12일 경에 마무리가 되었는데, hotfix로 추가 업데이트를 진행한 부분 때문일 것이다.
릴리즈 직후 팀원 내에서 후기작성 뷰 글자수 및, 후기작성 완료버튼 활성화 지점 관련 피드백이 들어왔었다. 본격적 홍보를 하긴 직전이었는데, 실제 이부분에 대해서 기획적으로 많이 생각을 못했던 지점에 대한 피드백이었다.
피드백의 요지는, 현재의 글자수 및 후기작성 완료버튼 활성화 지점으로 가져갈시 후기작성에 대한 허들 증가 및, 짧게라도 적을 수 있는 항목(ex. 향후진로) 가 안 적혀지게 될 수 있을 것이고, 본격적 홍보 직전에 이부분 변경을 진행해 초기에 유입되는 데이터의 질을 높이자는 의견이었다.
실제 이에 대해서, 팀원들간에 의견이 갈렸고 엄청나게 정량적으로 검증할 수 있을만큼의 수를 대상으로 무언가를 할 순없겠지만 최소 5~7명 대상 사용자 인터뷰 및 사용성 테스트를 진행해보려 했다.
(조금이라도 근거가 있는 상태에서 변경을 하더라도 하는게 맞다고 생각해서)
해당 인터뷰 및 테스트에서, 어느정도 변경에 대한 이유가 생겼다고 판단해서, 추가 업데이트를 진행하기로 결정했으나 이 과정자체가 조금 미숙했다고 생각한다. 기획자 입장에선, 이런 정성적인 인터뷰 결과면 되겠지라고 안일하게 생각할 수 있으나 기능변경 하나하나가 추가적인 인풋투입인 개발입장에선, 정말 이 방향이 맞다는 정량적인 검증, 논리에 대한 확실한 설득이 되어야한다고 생각한다. 그런면에 있어선, 기획자인 내입장에서도 빠르게 인터뷰를 진행하느라, 이부분에 대한 논리력이 확실히 있다고 생각하진 않기에 그런면은 굉장히 나 자신에게도 아쉬웠던 거 같다.
후기작성뷰 글자수라든지, 후기작성항목의 워딩 등 여러가지에 있어서 실제 릴리즈 개발전에 사용자의 피드백을 바탕으로 개선할 수 있는 부분들이 있었을 거라고 생각한다. 테플이나, apk를 가지고 베타테스트 돌려보면서 실제 고객 목소리를 듣는 방향이라든지. 혹은 디자인 프로토타입을 가지고 사용성 테스트를 하는 방향도 있었을 것이다. (이런 방법에 대해서 릴리즈 전까지 생각을 못했던 내 잘못이 크다.)
일단은 이대로 가도 아주 큰 문제는 발생하지 않겠지라는 안일함이 조금 작용했던 거 같다. 그리고 일단 해보고, 사용자들이 피드백 주면 그때 수정하자는 생각이 있었다. 하지만, 진짜 내가 고객목소리 바탕으로 기획을 할려 했던 것이라면, 릴리즈까지 시간이 있을때 기획적으로 애매한 부분에 대해서 좀 더 자세히 물어보고, 실제 고객들대상으로 테플로 베타테스트라도 실시를 하면서 릴리즈 기간을 조금 더 여유를 가져 갔으면 어땠을까 하는 생각이 들었다. 실제로 기획 거의 막바지에 이런 방법으로 할 수도 있었겠구나를 깨달았던 바라 이부분이 정말 아쉬웠다.
실제 이제는 앱이 나온 상태이기 때문에, 그리고 어떤 사항에 대해 고객 목소리 들을 수 있는 방법은 꼭 개발이 아니어도 되기에, 현재 버전의 앱이든, 테플이든 바탕으로 실제 사용자 인터뷰, 사용성 테스트를 진행해보려 한다.
어떤 기능을 삽입, 변경하려고 할 때 최대한 개발자들이 설득될 수 있을 정성, 정량적 데이터를 수집해야 겠다고 생각했다. 추가적인 인풋을 들일 가치가 있구나, 이 방향이 정말 맞구나! 라는 생각이 들도록
내 논리가 아닌, 좀 더 진짜 객관적인 수치를 바탕으로 개발자들을 설득할 수 있도록 바뀌어야 된다고 생각한다.
정말 사소한 기능 하나더라도, 그냥 뇌피셜로 추가하지 않도록 노력해야겠다고 생각했다.
2) 개발자의 시각에서 생각하지 못한것
실제로 나는 기획자의 시각에서만 생각했던 것 같다. 실제 창업팀에서 하는 기획이 아니라 앱을 만드는 것임에도.
그냥 서비스만 생각한다면, 릴리즈 이후 고객인터뷰 사용자 테스트 약 8명정도를 바탕으로 패턴을 찾아내고, 거기서 이 업데이트를 가져갈만한 근거가 있다고 생각했었다. 그리고 기획파트에서 배운, 그리고 창업하면서 느낀 서비스를 만드는 것은 이렇게 조금씩 조금씩 계속 수정을 하는 것이었으므로.
하지만, 개발자가 서비스를 바라보는 관점, 이 서비스를 통해 얻고자 하는 것, 서비스에서 하고자 하는 것은 조금 다를 수 있다는 것에 대해 미흡했던 거 같다.
이런 린스타트업 같은 시각은 개발자가 아닌 나에게 익숙한 것이라는 것.
개발자들은 더 클린한 코드, 더 매끄러운 코드를 만들면서 사용성을 높이고, 코드의 완성도를 높이는 것. 그리고 불완전한 상태보다 최대한 완성된 상태로 앱을 내고 싶다는 것.
어쩌면 지금까진, 개발자들이 기획자의 시각, 가치관에 많이 맞춰주고 배려해줬다는 생각이 들었다.
기획자의 시각, 서비스의 시각에서 개발자들이 기획자를 배려해주는 것에 비해, 나는 개발자들이 어떤것을 원하는지 개발자들의 시각은 어떤것인지에 대한 고민이나 생각이 아쉬웠던 거 같다.
이점을 좀더 반성하고, 과연 이 일을 할때 개발자들은 어떻게 바라보고, 뭘 원하고 있을지에 대해서 좀 더 생각하고 물어보면서, 서로의 시각을 이해하고 그 간극을 좁혀갈 수 있도록 노력해야겠다는 생각이 들었다.
결국 개발자든 기획자든 "서비스의 성공"이라는 대 전제 자체는 같기에, 다만 그것을 이루려는 방식이나 가치관의 차이가 있을 뿐!
3) 충분한 시간을 보장하지 못한것, 그리고 충분하지 못하다고 느끼는걸 더 세심하게 판단하지 못한점
어찌보면, 릴리즈만 되면 좀 쉬겠지, 릴리즈까지만 어떻게 달려보자 하면서 처음 정한 1차릴리즈 기한을 맞추려고 개발자들이 무리해서 더 열심히 해줬다고 생각한다. 이 기간도 엄청 타이트 했을텐데, 그걸 해냈는데, 그 직후 바로 급하게 업데이트를 하자고 결정했으니(물론 어쩔수 없는 상황이었긴하지만) 어찌보면 휴식 시간 없이 또 하나의 업무를 준 것이었다고 생각한다.
또 바꾸는 것 자체는 그렇다쳐도 이렇게 사용자 유입이 미뤄질거면, 처음부터 좀 더 여유있게 릴리즈 기간을 잡았으면 더 편하게 완성도 있게 개발하는 거 아니었나라는 피드백이었다. 굉장히 맞는 말이었고, 물론 릴리즈 이후에야 후기작성뷰에 대한 기획적 의구심이 제기된 것이라 어쩔 수 없긴 했지만, 이부분은 내가 크게 잘못한 부분이라고 생각한다.
또한 나름 고객인터뷰와 사용자테스트를 해서 특정 패턴과 이 기능 개선의 필요성을 검증했다고 생각했지만,개발자분들은 이정도 수치 이정도 규모가 아닌 좀 더 확실한 데이터를 바탕으로 햇으면 하는 아쉬움을 나에게 남겨줬던 거 같다.
특히 정성적 의견에 대해 받아들이는 정도가 당연히 기획자와는 다를 수 밖에 없다는 것에 대한 예상을 많이 못했다고 생각한다.
위에서도 많이 말했지만 기능의 변경에 있어서 이게 진짜 필요하고 개발해달라는 것을 설득하기위해 좀더 확실한 근거를 가지고 할 수 있도록 노력해야겠다고 생각햇다.
2. QA에서의 미숙함, 하고 싶은 것과 해야하는 것을 구분하기
- 아요 QA가 늦게 진행됐던 것 QA기간에 대한 아쉬움
- QA는 기능개선이 아닌 개발중 생긴 버그수정의 목적이라는 것)
- 하고싶은 것은 목록화해서 정리하는 게 필요
- 목표를 3월초로 잡고, 그에 맞춰 개발하기로 했는데 QA 때 미세하게 계속 기능이 추가됐었다.
느낀점 및 개선할 점:
QA 기간에 대한 부분은 같이 일하는 PM이 그 당시 인턴일로 바빴어서 연락이 안되었던 것 자체도 있지만, 어찌보면 내 책임도 크다고 생각한다. 같이 일하는 PM에게 이때쯤이 기획자들이 빠르게 QA를 해줘야하는 기간이고 이때가 바쁠것이다 라는 언지를 조금더 빨리 줬다면, 이런 상황자체가 발생하지 않지 않았을까? 같이 일하는 PM 형은 자신에 대해 자책을 했지만, 그 원인을 제공한데에 나의 책임이 없지 않다고 생각이 들었다. 실제 장, 단기 타임라인에 대한 부분을 주 초, 혹은 주 말 등에 짧은 회의나 서면 공유를 하는 방식으로 일주일에 대한 계획을 좀 더 잡을 수 있게끔 하려고 한다.
QA라는 것을 처음해보다 보니, 물론 버그나 오류를 잡아낼라고 한 피드백도 있었지만, 쓰다보니 느낀 처음기획에서 놓쳤던 아쉬운 점들을 말했던 요청사항들도 있던 거 같다. "이런거 이렇게 변경하면 어떨까요?"가 되어버린것이지. 버그만으로 벅찬데, 미세한 기능이 조금씩 추가되기도 했던거 같다는 생각을 했다.
이번 업데이트 사항때는, 작게나마 반영 우선순위 항목을 기입할 수 있는 칸을 만들어두고 그에 따라 QA 반영필요사항의 우선도를 구분함으로써 개발자들의 인풋을 좀 아껴볼 수 있도록 해야겠다는 생각을 했다.
또, 필요한게 아닌 나중에 하고 싶은 것들은 목록화 할 수 있는 페이지 혹은 표등을 밑으로 만들어야 겠다고 생각했다.
정말 서비스 빨리 출시하는 것에 맞춰 QA를 타이트하게 가져갔었는데 다음에 추가적으로 또 이런작업을 하게 될떄는 최대한 이 QA라는 것을 타임어택 치지 않도록, 여유갖고 반영할 수 잇도록 전체 팀 타임라인을 조정해야겠다고 느꼈다.
그래서 실제로 QA 관련되어서 이렇게 깨진 덕분에 QA관련 공부를 열심히 한뒤, 추가 QA 시 활용했다.
https://m.blog.naver.com/gwaei324/221663243837
언제나 어렵네요, 이슈의 우선순위와 심각도
#QA #Engineer #Tester #Issue #우선순위 #심각도 #Priority #Severity #주저리주저리 #어려움 1. ...
blog.naver.com
실제, 우리 QA가 버그 및 오류 수정이 목적이라는 점을 강조하려고 했고, QA사항 기입시 우선순위(서비스 측면)
, 심각도(기술측면) 양쪽을 기입한뒤 우선순위 기준으로 Phase를 기입해달라고 부탁했다.
실제 피드백으로 나왔던 부분 외에도 느꼈던 부분이, 개발자 입장에서 여러개의 QA 사항이 들어왔을때 그중에 먼저 작업할 사항과, 업데이트 이후에 고려하면 될 사항을 정하는 것이 어렵다고 생각했다.
그래서 이런 부분들을 조금 더 원활하게 가져가기 위해 아래 사진 같은 방식을 이용했었다.
실제 릴리즈 이후, 서비스를 사용해 보면서 혹은 지인들로 부터 피드백 받은 내용에 있어서 버그 수정, 오류 수정이 아닌 기능 추가가 필요한 부분에 있어서도 중요도를 다음과 같이 설정해서 기능 제안을 자유롭게 할 수 있도록 만들어보았다.
2) 내가 생각한 아쉬운점(팀원에서 언급 덜 된 부분중)
1. 문서화에 있어서의 아쉬움
정리 자체는 나쁘지 않게 했던거 같지만, 한곳에서 볼 수 있으면 더 좋겠다는 생각을 자주 했던 거 같다.
이슈용칸반과 그것의 표정리 같은 경우는 의도자체는 나쁘진 않았는데, 겹치는 기능끼리 좀더 보기좋게 묶는다던지,
더 좋은 방식이 있을 거 같다고 생각한다.
혹은 아예 페이지를 판뒤에, 목차를 만들어둔다던지! 그럼 좀더 보기 좋지 않을까 싶었다!
시간날때 정리를 한번 이런식으로 해야겠다는 생각!
혹은 정책은 정책끼리, Q&A는 Q&A 끼리, 변경사항은 변경사항끼리 뭔가 더 좋은 방식이 있을 거 같은데 이부분은 좀 더 공부도 해보면서 정리를 해봐야겠다는 생각이 들었다. 특히 스프린트 단위로 움직이는 조직이나, 애자일 프로세스로 진행되는 조직들은 기획문서를 어떻게 관리하는지에 대한 공부가 좀 더 필요하다고 느꼈다. 아무래도 지금 익숙한 것은 워터폴 방식 혹은 SI 에서 주로 쓰는 기능명세서와 같은 방식이니까! 지금 이슈용칸반 만들어놓은것은 실제 기업에서 쓰는 방식은 고려하지 못하고, 감으로 만들어버린 것이니!
기획파트 5차세미나 마침 기획문서니까, 한번 이부분에 대해서도 추가적으로 책 읽으면서 공부를 해봐야겠다고 생각이 들었다.
2. 일정관리나, 팀원 세세하게 챙기는 것
노션메인에 있는 캘린더, 타임라인을 좀더 명확히 챙기지 못했던 거 같다. 결국 팀원들이 가장 자주 보게 될 공간인데, 이공간에 일정을 더 보기좋게 정리해야한다고 느꼈다.
그래서 실제 홍보일정, 지원사업 일정, product 관련 일정, 팀 운영 관련 일정 관련 투명한 공유를 위해 노션 메인에 주기적으로(최소 1주에 1회이상) 타임라인 업데이트를 진행하고 있다.
또한 팀문화,핵심가치등을 좀 더 잘 메인에 잘보이게 만들면, 팀원들이 오고가면서 보게 되지 않을까? 라는 생각을 했다.
그렇게 되면, 좀 더 하나의 목표를 향해 달려갈 수 있겠다는 생각을 했던 거 같다.
그래서 실제로, 릴리즈 회고를 거치면서 팀문화, 목표 측면의 것들도 다시 의견을 수합받고 정리를 하려 노력했고, 노션 메인에 해당 내용을 잘 보이게 걸어두려 했다.
팀원들을 하나하나 세세하게 챙기는 것을 많이 못했다고 생각이 드는데, 이부분 해결을 위해 미뤄뒀던 전화데이트, 그리고 VC 만나는 김에 팀 전체 회식도 하려고 한다.
3. 기타 하고 싶은말
2월 6일부터 3월 25일까지 한달 반정도의 시간동안 모두가 달렸다. 실제 앱잼을 할때보다 개인적으론 더 힘들었던 것 같다. 앱잼때는 1차적으로 기획해놓은 내용들에 대해서, 디자인과 개발이 들어가는 상황이었기에 내가 신경쓸 부분이 그렇게 많진 않았었다.
하지만, 실제 앱을 출시하는 과정에서 이것저것 준비해야할 사항들이 굉장히 많다는 것을 느꼈고, 앱잼땐 미뤄뒀던 것들을 특정 기한내에 처리할 수 있도록 적정선을 조정하는 게 쉬운 일은 아니었던 거 같다.
실제 각 포지션의 사람들이 어떤 마음을 가지며 일을 하고 있을지, 각 상황에서 어떤 감정을 느끼게 되는지 조금 더 알아갈 수 있던 상황인거 같다.
정말 짧은 시간 내에, 지식적으로도, 정신적으로도 많이 성장할 수 있던 거 같다. 이제 실제 서비스를 운영하고 확장해나가는 작업이 남았는데, 이 작업에서도 지금까지 처럼 부족하지만 차근차근 배워가면서 잘 이뤄내면 좋겠다.
그래도 열심히, 그리고 잘 했다 라고 오글거리지만 나 자신에게 말해주고 싶다.
이렇게 오기까지 스트레스도 많이 받고, 육체적으로도 많이 힘들었을텐데 잘 끌고 왔다고, 그 과정들도 정말 충실히 잘 해줬다고! 그리고 그 일련의 과정 재밌게 해나간 것 정말 잘했다고! 앞으로도 잘해보자구!
나도선배라는 서비스를 얼마나 키울 수 있을지 모르지만, 적어도 단순히 출시 후 끝!은 아닌 서비스로 발전시켜보자!
앞으로도 잘해봅시당!!