드디어(임시저장 글에 하도하도 묵혀놔서 묵은지가 되어버린..ㅎ) 프로젝트의 마무리 회고.
배포했다고 생각했는데, 왜 안올라갔었지..?!😭
사실 이젠 스프린트와는 무관했다고 할 수 있다. 일주일동안 테오 덕에 스프린트를 경험했지만 이후 디벨롭은 별개로 진행했으니까.
스프린트는 24.12.09에 마무리 됐었고, 추가 진행은 그 이후부터 시작됐다.
데모에서 아쉬운 마무리를 했기 때문에 우리끼리 더 디벨롭시키기로 결정한 후가 오히려 본격적인 시작이었다.
디자인 결정하기
원래 데모 구현 기간 동안 디자이너를 구해놨엇는데 개인 일정 때문이신지 원래 얘기했던 일정에 맞춰지지 못했다.
그래서 이번엔 제대로 디자인 기한을 정할 필요가 있었다.
엄밀히 말하면 연장된 프로젝트인만큼 길게 끌고 싶지 않은게 공통 의견이었다.
그래서 개발 기간과 맞추어 최소 기한에 대해 디자이너 분께 가능 여부를 전달드렸고 다행히 해당 기간에 대해 오케이가 되었다.
디자인 미팅
1차: 시안 결정짓기
디자인과 관련된 미팅은 주기적으로 진행됐다.
“질문 보따리에 구슬을 담아준다.”라는 기존 컨셉은 유지되는게 골자이다. 그리고 와이어프레임은 짜뒀었기 때문에 이를 기반으로 디자인 요청을 드렸었다.
데모 기간 디자인 기한이 안 맞았던 만큼 이번만큼은 다들 기한이 확실히 지켜져 나오길 바랐었다.
디자인 없이는 서비스 매력 어필 힘이 떨어지는걸 어쩌겠는가ㅠ 목 빠지게 기다릴 수 밖에 없는 심정..
최초 시안에 대한 기한을 정해뒀었기 때문에 해당 일자에 최초 컨펌 미팅을 진행했는데 이때 변동은 크게 두가지였다.
- 테마 색 변경
- UX 의도와 다른 디자인 수정
최초 색은 좀 따듯한 느낌이었다. 지인에게 서로의 마음이나 의견을 듣는 만큼 최초 생각은 그랬다.
그런데 연말연초에 맞춰 조금 톤다운 느낌의 색으로 의견들이 바뀌어 네이비톤이 베이스 색이 되었다.
부족한 색감은 눈꽃의 색에서 찾을 수 있으니, OK.
이건 어찌 보면 큰 변화는 아닐 수도 있으나(작업량 개념에서? 아닌가 디자이너분이 이 글을 보면 화내려나?),
두번째 사안은 중요했다.
디자이너님이 프로젝트 진행 중 미팅에 참여를 못하는 경우가 많아 기존 기획 의도에 대해 놓치거나 잘 못 이해한 경우들이 있었다.
그래서 이번 미팅에서 해당 부분을 시정하고, 기획적인 아이디어를 맡았던 만큼 해당 부분의 의도를 명확히 다시 설명드리는 시간을 가지도록 했다.
이 과정에서 다시 추가 의견이 나와서 약간 변동점을 반영하기도 했다.
역시 기획은 어렵고 끝이 없다.. 가장 큰 고충도 하나 있었는데 이건 말미 소감에서 적자. 다시 디자인 회고로..!
2차: 서비스 캐릭터 만들기
이젠 부족했던 개발에 대한 추가 진행을 하며 컨펌 완료된 디자인에 대해서는 와이어프레임에 입히는 작업까지 진행되었다.
그리고 중간 디자인 재컨펌. 이때는 거의 마감되었던 것 같다.
하나 더 포인트, 이때쯤 서비스에 중요한 아이디어가 제시됐었다.
서비스 캐릭터를 만들자
구슬을 보따리에 담기는 하나, 이걸 어떻게? 뭔가 스토리적 매개점에 대한 고민이 생겼었다.
그리고 어떤 캐릭터가 이를 담아주는 느낌이 어떠느냐는 아이디어가 제시된 것.
어떤 캐릭터를 하지?
- 부끄러미라는 서비스가 녹아나면 좋을텐데
- 귀여웠으면 좋겠다
여러 제시안이 나오지만 뚜렷하진 않을 즈음에 두두등장..!
팀원 분 중에 디자인 적으로 좋은 아이디어를 가진 개발자 분이 한 분 계셨다.
서비스가 부끄러미니까 북극곰으로 해서 ’부끄‘ 어때요?
유레카! 너무 좋다. 부끄러운 북극곰 부끄! 캐치프레이즈도 너무 좋았다.
심지어 아이디어 뿐 아니라 실제 시안도 어느정도 그려내실 수 있는 분이었다.
(개인적으론 디자이너 출신이신가? 싶었을 정도)
디자인 관련해서는 디자이너 분도 이 개발 팀원분과 많이 소통을 진행했다.
실제 몇몇 시안은 직접 완성해서 디자이너분께 전달하고, 디자이너님이 다듬는 식으로 하기도 했다.
캐릭터를 만들고 나니 서비스에 스토리를 입히기 보다 수월해져서 컨셉을 공고히 하는데 좋았던 것 같다.
Shout out to @쿠리
n차: 추가 디자인 요청
이제부턴 주기적 컨펌과 단기 미팅이었다.
다만 새로운 태스크 발생.
작업을 하다보니 UX면에서 개선되어야 할 부분들이 보였고,
그런 부분에서 새로운, 혹은 수정해야할 부분에 대해 요청을 드렸다.
먼저 가입 유저는 서비스를 알고 가입했다고 친다 하더라도, 공유링크를 받아 들어온 유저는 서비스 컨셉에 대해 이해하기 어려울 수 있다는 것.
“링크로 들어오긴 했는데 이게 뭐죠?”
최초 접근 유저한테 서비스를 설명할 접점이 필요했다.
그래서 이에 대해 필요성을 제시하고, 디자인 요청을 드렸다.
이에 대한 시안도 대략 그려졌어서 와이어프레임으로 먼저 제시 드리고, 디테일한 UX적 부분은 미팅 중에 팀원들의 의견을 더해서 완성했다.
개발 테스크 처리
이제 본업 부분. 개발자니 개발을. 마무리를.
태스크 관리는 디벨롭 과정으로 들어와서 JIRA(이하 지라) 진행됐다.
예전에 사이드 프로젝트로 사용해본 적은 있는데 근래엔 없어서 사실 무지한 상태나 다름없었다.
다행히 지라를 제안한 PL을 맡고 있던 다른 개발자 분이 현업에서 사용하고 있어서 가이드를 받아 진행했다.
Figzam to JIRA
본래 스프린트 동안은 피그잼을 통해 태스크를 확인하고 개발을 진행했지만, 시각적으로 자극을 받고 영감을 얻는 다는 장점이 있는 반면 태스크 관리엔 적합하지 않았기 때문에 여기에 맡는 tool로 옮기는 건 타당한 과정이었다.
옮긴다는게 개발자스럽게 자동화 툴로 스르륵 옮기면 좋겠지만 플랫폼적으로 보다 양식적으로 보나 그건 어렵고;;
기존에 스토리 라인에 맞춰 화면을 쪼개고 태스크를 분리한 것을 지라로 재정리했다.
먼저 유저 스토리에 맞춰 이벤트를 나눈다.
그리고 이제 여기 하위에 기능적 부분을 태그크로 생성하고 각자 할당받았던 것들을 작업자로 지정했다.
이제 각 티켓의 상태를 통해서 미진행/진행중/작업완료를 한 번에 볼 수 있어서 보다 수월한 관리가 가능해졌다 :)
티켓 재조정
개발을 진행하며 어려웠던 점은 작업시간이 다르고 진행도가 다르단 점이었다.
이 부분은 어쩔 수 없는 부분이라고 생각한다.
현재 직장을 다니는 사람과 그렇지 않은 사람이 함께 했으니 다를 수 밖에.
그래서 여기에 대해서는 재조정이 필요하다 느꼈다.
물론 해당 티켓 담당자로써 책임감이나 본인이 진행하고 싶은 아쉬움이 남을 수는 있다.
그렇다면 개인 시간을 더 투자해 마무리하겠다는 확고한 의사 표현이 있다면 문제 없다.
협업 상황에서 책임을 지는 의미에서 이게 베스트지만 현실적인 상황이 안 맞을 수도 있다.
그러면 양해를 구하면 팀으로써 충분히 이해 가능하다.
하지만 담당자분은 이에 대해 확답이 어려운 상황이셨고,
이에 대해 마냥 담당자의 상황을 지켜보고 기다리기엔 기한을 맞춰야할 시점에서 판단으론 맞지 않다 생각했다.
이미 이 시점에서도 전체 기한이 원래 기한보단 조금 딜레이 됐었다.
이건 이 담당자의 책임이 아니라 전체적인 딜레이였기 때문에 팀 전체 책임이고, 이젠 수습할 타이밍이었다고 생각한다..
그래서 해당 담당자에게 말을 하고 업무를 쪼개 가져갔다.
기다리는 동안 해당 태스크를 처리하면서 다 처리되면 좋은 것이고, 만약 중간에 원래 담당자가 다시 여건이 된다면 후합류해서 같이 진행하면 되니까.
실무에서도 담당자의 태스크 마무리에 무리가 있다면 다른 개발자들이 도움을 주는데 이것도 마찬가지일뿐.
일이라는 개념에선 서로 같은 양을 하면 좋겠지만 점점 연장되는 기간을 계속 끌고 갈 순 없는 노릇이니 여유있는 사람이 좀 더 작업을 치는게 맞다고 판단했다. 이게 팀 아닌가?
아무리 사이드 프로젝트라 한 들 약속한 마무리 기한이 있는데 이에 대해 계속 너무 여유롭게 생각하며 기한을 연장하는 것은 프로젝트를 경험하는 의의에서 또 하나 중요한 점이 퇴색되는 것이라 생각한다. 프로젝트라면 기술 경험 외 기한을 맞춰 마무리하는 것 또한 중요한 부분 아니겠는가.
‘더 이상의 기다림은 배려라기보단 방관이다.’가 개인적인 생각ㅎ
더군다나 나같은 (재)취업에 이 플젝을 실고자 하는 입장에선 더더욱 마무리가 중요했다.
다만 아쉬운 점은 리딩과 소통이 좀 더 잘 됐었으면 하는 맘이었다.
PL분이 바빠지다 보니 태스크 체크가 점점 잘 안 됐고,
담당 업무에 대해 기한 내 가능한지, 어려운지, 개인시간을 더 투자해서라도 하게될 것인지, 빠른 전달이 됐으면 좋았을 것 같은 느낌.
점차 현업이 바빠져서였는지는 몰라도 진행과 관련해 소통에 끊어짐과 오류가 있어 이게 후반부의 힘든 점이었다.
그래서 후반으로 갈수록 리딩도 같이 하게 됐는데,
결과적으론 나에겐 좋았다고 생각한다. 이런 경험이 나에게 또 하나의 밑거름이 되는 거니까.
그리고 당시 난 시간 빌게이츠였으니까ㅎㅎ
당연히 당시엔 힘들긴 했다. 멘탈적으로나 체력적으로나
동시에 이런 내 행동이나 판단이 누구에겐 부담이 됐을 수도 있을 거란 생각도 든다.
내 푸쉬가 부담이 되었을 수도 있고, 내 행동이 욕심을 보였을 수도 있으리라.
그러치만 다시 돌아가도 프로젝트를 기한 내에 마무리 해야됐다는 생각은 동일하다.
부가적이지만 필수적인
이제 별개로 서비스가 갖춰야할 추가 요소들을 만들었다.
타이틀처럼 부가적이지만, 필수적인 것들은 아래와 같다.
- 약관 컨텐츠
- 문의하기 기능
회원가입간에 약관 동의 컨텐츠는 당연히 서비스를 운용하는데 행정적(?)으로 필수적이고,
문의하기도 얼마나 회원이 생길진 모르지만 우리는 결국 유저를 유치해서 피드백을 받아보는게 크기 때문에 추가 요소로 얘기가 나왔다.
약관 동의
컨텐츠는 AI로 후루룩 짰다. 물론 컨텐츠의 내용 점검은 했다. 용어나 흐름적으로 제거하거나 추가할 것들 좀 더 넣고.
물론 이게 법률적으로 100% 맞을까는 부가적인...
문의하기
이건 팀원의 의견으로 나왔었는데 좋다고 생각이 들었다. 쓰다보면 100% 괜찮지 않을 텐데 그런 사용자 피드백을 받을 수 있는 창구가 있으면 좋으니까.
근데 후반부에 나온 의견이다보니 새로 화면과 api를 만드는 것 보다는 구글 폼을 쓰는게 효율적이라고 판단됐다.
그래서 간단하게 받아볼 질문에 대해서 컨텐츠를 짜고 팀원 분들에게 공유했다.
팀원 분들의 피드백을 받아 수정하고, 컨텐츠 컨펌을 받아 생성.
화면에서는 버튼을 만들어서 링크를 연결하는 걸로 간단히 마무리했다.
QA/QC 진행하기
당장 해결 불가한 이슈 핸들링
결국 우여곡절 끝에 MVP를 만들었다. 근데 만들 동안 고질적인 이슈가 하나 있었는데,
카카오 로그인에서 White Label 이슈가 뜨는 거였다.
그런데 트러블 슈팅이 참 어려웠던게 몇몇 분들 계정에 한정적이었고, 일부는 또 해결이 됐다..
게다가 카카오 API 쪽을 슈팅해야하니 막막하고,
사실상 마지막엔 한명의 계정에서 발생하니 이걸 어쩔까..하는
근데 방안은 당장 없는..
그래서 제안을 하나했다.
당장 팀 내에서도 한명에서 발생하는 이슈였기 때문에 좀 더 많은 케이스를 모으는 것이 좋아보였다.
막상 다른 유저들에겐 발생하지 않을, 로컬적인 이슈일지도 있지 않을까?
그리고 만약 다른 유저에게도 발생한다면 그 이슈 케이스들을 모아 해결하면 되지 않을까?
이게 내 생각이었다.
슈팅이 되지 않고, 케이스도 한정적인 상황. 그리고 방안이 없는 상황에서는 운영을 먼저 해보자였고,
사이드에서 이런 부분을 실험적으로 해보는 것이 좋은 포인트라 생각했다.
팀원분들도 이것에 OK.
이 부분에 대해서는 일단 운영하기로 결정하였다.
0차 리딩 - 트러블 슈팅
내 기본 기조는 잘하는 사람을 팔로우하며 성장한다. 그런데 없으면 내가한다. 왜냐? 목마른 놈이 우물파는 거니까.
앞에서 계속 언급했듯이 난 이직에 활용할 프로젝트로 생각하고 있었고,
누군가 리딩을 하면 팔로우할 생각이었지만 프로젝트 막바지 딱히 나서는 사람이 없었기 때문에 내가 QA 리더입니다! 결정된 건 아니었지만 주도적으로 나서서 리딩을 했다.
누군간 해야지! 근데 내가 아쉬우니 내가 하자!
처음은 0차적으로 FE팀 내부에서 알고 있던 부분들에 대해 리스트업하고 태스크 처리.
이건 무거운 것들이 없었기 때문에 빠르게 정리했다,, 이 부분은 FE 쪽에 태스크 들이었기 때문에 팀 전체로 진행하는게 아니라 FE팀 내에서 빠르게 쳐내기로 했다.
그래서 0차.
여기도 분배는 아쉬웠지만 항상 이렇게 생각한다.
하면 내 경험이고 이득이야! 그니까 괜찮아!
1차 리딩 - 팀전체 사이클
QA 티켓 확정하기
실질적인 팀 전체 QA/QC 진행은 이제부터였다. 일단 회의를 진행해서 유저플로우를 작성할까 하며 회의를 열었다.
근데 회의 결과 테스트는 기존에 만들어 둔 에픽/티켓을 기반으로 진행하기로 했다.
해당 티켓들이 유저 플로우 기반이었기 때문에 진행에 맞아 떨어졌다.
테스트 진행 방식
진행은 JIRA에서 티켓을 보고 플로우를 진행하고 두가지 라벨을 나눠서 피드백을 댓글로 적는다.
- 에러/버그
- 개선 포인트
1차 진행 결과 미완성 API를 제외하곤 FE쪽 피드백이었다.
해당 업무의 분배는 각자 맡았던 티켓이 있고, 그쪽에 피드백이 달려있기 때문에 그걸 수정하는데 있어서도 각자 담당자가 빠르게 진행할 수 있을 거라 판단해 그렇게 할당하기로 얘기했다.
그리고 진행 상황에 대해서 확인하고, 다시 체크.
그리고 완료 티켓과 일부 누락, 중복 포인트를 체크.
이렇게 1차를 마무리 지었다.
2차 리딩 - 최종 사이클
진행 방식 재설계
1차 QA/QC를 진행한 이후에는 해당 리스트들을 모두 처리하고, 2차를 다시 진행하려 했다.
그런데 1차 진행과정에서 QA/QC 진행 방식에서 아쉬운 점이 좀 있어서 이런 점들을 개선하고, 진행 방식을 좀 더 구체화해서 전달했다.
기존에 티켓 댓글 방식으로 달다 보니 직접 들어가보지 않으면 파악이 어려웠다.
그래서 피드백도 라벨을 달아 하위 티켓으로 발행해 관리하기로 했다.
그러면 타이틀을 통해 이슈 파악도 쉽고, 처리 여부 파악도 쉬웠다.
찐찐막 체크하기
다시 한번 2차 테스트를 진행하고 나서 2차에서 나온 티켓들도 처리가 완료 되어갔고, 추가 논의 포인트만 다시 한 번 짚어드렸다.
그리고 그 와중에 JIRA 무료 기한이 1일 남아 있어 매우매우 쫄렸다..ㅎㅎ
그래서 요것도 한번 다시 상기시켜드리고. 푸쉬 아닌 푸쉬.
그렇게 여차저차(여러가지 우여곡절)하며 진짜 MVP라고 마무리 할 수 있다는 시점이 왔다.
자 이제 남은건..?
홍보하기
이젠 이 연초 시점이 지나기 전에 빨리 홍보해서 유저를 모으는 것! 빠른 홍보를 위해 홍보글도 얼른 작성해서 팀원들에게 공유했다.
글을 아예 못쓰는 편은 아니라 얼추 작성하고 피드백을 받아보았고,
다들 OK! 그리고 팀원들도 그냥 내가 쓴 글을 가져다 써도 되냐길래 그것도 OK해줬다.
글 각자 쓰는게 문제겠는가, 유저 모으고 홍보가 많이 되는게 문제지.
나같은 경우엔 테오 프론트엔드 채널이랑 스터디 팀원들, 개발자 오픈 챗방에 홍보를 진행했다.
모여라.. 제발 모여라..
마무리
프로젝트 진행 결과. 유저는 약 130명 가량 모을 수 있었다. 엄청 많은 유저는 아닐 수 있겠지만 그래도 나는 의미있었다고 생각한다.
트래픽에 대한 고민을 할 만큼의 유저는 아니었을지라도, 홍보 결과로 우리 서비스에 관심을 가져준 사람들이 100을 넘었다는 것에.
그리고 사이드 프로젝트로써 이만큼 모았다는 것에 좋은 결과라고 생각했다.
긍정 마인드..!ㅎㅎ 어쨋든 팀끼리 쓰는게 아니라 그 외 사람들이 사용해봤다는 것에 의의가 든다.
그리고 처음 UIUX 담당자로써 역할을 하며 기획을 했다는 것.
나중엔 의도된 바는 아니었지만 후반부 진행 리딩과 QA리딩을 맡아 진행하며 프로젝트를 마무리할 수 있었다는 것에서 크게 배우고 익힌 것들이 있다고 생각한다.
내가 생각하는 개발자로써의 지향점에 영향이 갔다는 느낌?
너무 회고 배포가 늦어졌지만..(진짜 다써 놓고 배포했다고 생각했는데..흙) 그래도 결국 최종 회고까지 마무리했다.
다시 한번 점검하며 약간 투박하지만 다시 다듬기도 했고 말이다.
글의 마무리는 항상 어려운데. 어쨋든 고생한 만큼 성장했으리라 생각하며 마쳐본다.
