퇴사하고 약 한달,,, 혼자하는 건 언제나 한계가 있는법.
협업으로 습관도 잡고 경험도 쌓고, 여러가지로 배울 겸 때마침 진행된 테오님의 스프린트 행사에 참여하였다.
첫 테오의 스프린트를 참여하고 마무리까지.
일단 1일차부터 4일차까진 설계가 진행되었다.
Day1: 아이디어 및 팀결정
기본적으로 스프린트에 대한 소개와 숙제로 있었던 아이디어들을 둘러보며 프로젝트 선정을 하게되었다.
연말이니 만큼 연말을 키워드로 한 아이디어들이 제법 보였고,
그 중 맘 속으로 1,2,3순위를 정한 뒤 재빠르게 투표!
다행히 팀선정은 빠르게 마무리 되었다. 단지 디자이너가 없었을 뿐...ㅠㅠ
(그래도 이건 다행히 후에 해결되었다)
아이디어 컨셉
이번 스프린트에서의 프로젝트 컨셉은 연말 회고이다.
주변 사람들을 통해 나를 돌아본다는 아이디어였는데 주변에서 생각하는 나를 올 한 해로 정해서 알아본다는게 좋아서 선택하게 되었다.
다른 분들 아이디어가 섞여 있다보니 사진 첨부는 생략
참고로 내 아이디어는 개발자들의 목적/직군에 따라 실제로 어떤 언어를 쓰는 비중이 높은지 조사하고자 한 서비스였다.
이건 내가 따로 기획하고 만들어볼 생각이다.
서로 알아가기
우린 4조! 조가 구성된 이후엔 원활한 진행을 위해 MC를 뽑고 서로에 대해 알아보는 시간이 주를 이뤘다.
간단한 자기소개와 팀과 개인의 목표, 각자의 강점과 장점 등을 적고 얘기하는 시간.
무엇보다 중요한건 리액션이었다.
처음엔 어색했어도 서로 리액션하며 분위기가 풀어지고 보다 편해졌다.
그리고 재밌었던건 각 단계마다 시간이 정해져 있다는 것이다.
늘어지지 않도록 5-10분 정도로 각 파트가 정해져 있는데 이게 스프린트의 묘미인가 싶었다.
Day2: 서비스 정의
둘째날의 중점은 서비스 정의와 구체화이다. 이 날이 꽤나 시간이 오래 걸렸다. 큰 스케치에 해당하는 날이라 아무래도 그럴 수 밖에 없었다.
일단 먼저 "우린 어떤 서비스를 만들 것인가?"를 중점으로 크게 다음 목차 순으로 정리 했다.
- 서비스의 목적
- 서비스의 타겟
- 서비스의 핵심 가치
이 과정에서 각자가 생각하는 방향성을 공유하게 되었는데 다행히도 서로 생각하는 방향은 거의 일치했다.
경쟁력 갖추기
이제 해야할 건 우리 서비스의 차별화이다.
사실 시장에 이제 나올만한 서비스는 거의 나와있다. 심지어 이런 토이 프로젝트 수준에선 말할 것도 없다.
그러니, 그래서! 더욱 경쟁력을 갖출 포인트를 잡아야한다. 이때 두가지에 중점을 두고 4단계로 진행을 하게 됐다.
1) AS-IS
AS-IS, 현재는 우리가 생각하는 목적을 이루기 위해 어떤 방법을 취하고 있는가?
즉, 현 소비자들의 주된 서비스 플랫폼을 확인해 보는 것이다.
일단 우리는 "연말에 서로의 마음을 전달하는 것"이 목적이기에 이에 대한 목적 해결 방법은 다음과 같다.
- 편지
- 전화
- 메신저 / SNS
- 오프라인 미팅
SNS에서 디테일하게 볼 건 인스타의 무물같은 서비스이다.
이렇게 추렸다면 다음은?
2) Pain Point
첫번째 중점 포인트! Pain Point이다.
이제 현재 목적에 대한 주된 서비스를 보았으니 해당 유사 서비스들의 아쉬운 점을 보는 것이다.
그 아쉬움은 곧 우리에겐 개선 포인트, 다시 말해 기회가 된다.
그리고 이런 아쉬운 부분들을 우리 서비스에선 어떻게 개선할 수 있을 것인가 고려해본다.
3) Wow Point
위 다른 서비스에서 발견하고 개선하고자 했던 점들 말고 우리만의 포인트는 무엇인가?
이게 바로 wow point이다.
일단 우리 서비스의 기능들만 놓고 보면 크게 특별할 만한 기능이라고 할 순 없다.
그렇다 보니 서비스의 컨셉과 전달하고자 하는 메세지 같은 것들이 중점이 되었다.
다른 서비스에선 느끼지 못했을 혹은 미비했던 감성 등을 강화하는 것.
연말 회고를 통해 스스로를 돌아본다는 메세지를 전달하는 것.
이것이 우리가 큰 관점에서 잡게된 Wow point가 됐다.
4) Feature
이제 위에서 정리된 것들을 가지고 실 기능을 정의해보는 것이다.
개선 포인트를 바꾸기 위해선 어떤 기능이 필요한가?
개성 포인트를 살리기 위해선 어떤 기능이 필요한가?
이를 통해 대략적인 메인 기능 외 핵심 부가기능을 정의할 수 있게 된다.
키워드 & HOW에 대한 고민
키워드
일단 핵심 키워드를 뽑아내 본다. 각자 생각하는 우리 서비스의 핵심 키워드를 뽑아내다 보면 겹치는 부분과 그렇지 않은 부분이 생긴다.
그러면 중복이 많은 것들이 보다 중점이 되어야 하는 키워드라 볼 수 있다.
그 외의 것은 논의 후 중요도를 고려해 볼 수 있다.
How?
이젠 어떻게에 대한 고찰이다. 앞서 목적을 말하고, 포인트를 잡고, 기능을 정리했다.
이젠 보다 구체적으로 "어떻게 ~할 수 있을까?"라는 포맷을 기반으로 다양한 질문을 던져본다.
여기에서 나오는 질문들은 보통 앞에서 고민했던 것들이 많이 기반이 된 것 같다.
질문들이 많이 나왔기 때문에 다같이 논의해봤으면 좋을 것 같은 질문들에 투표를 하고, 다시 비슷한 질문끼리 묶어서 답을 고민해 보았다.
우리 조에서 나온 큰 틀에서 질문은 다음과 같다.
- 어떻게 하면 적은 참여에도 상처받지 않을까?
- 어떻게 하면 우리 서비스의 수명이 늘어날까?
- 어떻게 하면 우리 서비스의 정체성/차별성을 잘 살릴 수 있을까?
- 어떻게 UIUX를 개선시킬 수 있을까?
- 어떻게 하면 로그인을 최소화할 수 있을까?
이때 앞서 언급한 기능들이 어떻게를 해결하기 위해 활용될 수도 있고, 홍보나 운영과 같이 앞에선 생각 못했던 것들에 대해서도 고민해볼 수 있다.
기능과 페이지
아직 끝나지 않은 두번째날의 스프린트... 실제로도 참 길었다..ㅎㅎ
기능 나열
이젠 개발 측면에서 실질적인 기능들을 키워드처럼 나열해본다. 앞서 키워드를 나열해서 진행했던 것처럼 이것도 같은 결의 기능들을 쭉 묶어본다.
페이지 나누기
이제 각 기능들을 배치해 페이지를 꾸려보자.
여태까지 흩뿌려져 있던 기능들을 페이지라는 개념 안에서 묶어볼 수 있다.
이때부터 점차 구상이 시작된다.
Self-UserFlow 점검
이제 가상의 사용자를 하나 정의해본다.
가령 SNS와 유행에 민감한 20대 여성
- 우린 추가로 도파민에 절여져 감성을 찾는, 이란 키워드도 넣었다ㅎ
근데 이때 느낀 점은 아직은 각자 그리고 있는 서비스의 구상이 좀 다르단 느낌을 받았다.
기능 측면에서는 크게 보면 같지만 디테일이 다른 느낌?
예를 들면 질문 생성을 할 때 하나로 제한할 것인가, 한번에 여러 질문을 받을 수 있도록 할 것인가에 대한 것들.
이땐 뭔가 말로 하기엔 다들 생각이 엉키고 복잡해져서 힘들었는데, 다행인건 다음 날 해와야할 숙제였다.
바로 화면 스케치를 해오는것.
이를 확인하면 각자 구상한 화면이 어떻게 될 것인지. 시각적으로 확인하며 접점을 좁혀나가는게 가능할 것이다!
그리고 이와 별개로 아무래도 우리 팀에 디자이너가 없다보니 고민이었는데, 문의 결과 외부에서 디자이너를 뽑아 합류시켜도 된다고 답변을 받아 각자 지인, 홍보 등을 통해 디자이너를 모집해보기로 하였다.
Day3: 스케치와 우선순위
전 날 숙제는 각자 스케치를 자유롭게 해오는 것이었다. 화면을 직접 그려보는 것.
이제 이걸 통해서 각자의 생각을 시각적으로 확인해볼 수 있다.
위 그림은 내 스케치이다.
컨셉은 연말과 겨울을 생각해 보따리에 담기는 답변이라고 생각해 보았고, 답변은 쪽지 내지 선물상자 정도로 생각해보면 좋을 것 같았다.
그리고 서비스의 흐름은 다음과 같이 생각해봤다.
- 로그인한 사람만 질문을 생성할 수 있다.
- 질문은 예시 질문 중 선택 or 직접 작성할 수 있다.
- 생성간에 옵션은 세가지이다.
- 비로그인 회원 답변 작성 가능 여부
- 내 보따리에 담긴 답변을 다른 사람도 볼 수 있게 할 것인지 여부
- 내 보따리에 담긴 답변 개수를 표시할 것인지 여부
- 생성 완료된 질문을 공유한다.
- 담겨있는 답변을 분석해서 키워드를 보따리 상단에 둥실 띄워준다.
- 키워드를 클릭하면 해당 키워드와 관련된 답변들을 보여준다.
- 메인에서는 담긴 답변들에 대한 흥미롤 보다 올리는 방법으로 랜덤한 답변 한 개를 미리보기로 띄워준다. 단, 작성자가 누군지는 보이지 않는다.
- "누가 보낸 답변일까요? 지금 확인해보세요!"
- 답변 리스트에서 답변을 한번에 확인할 수도 있다.
- 시안1) 카드 리스트 방식
- 시안2) 인스타 스토리 방식
전체 팀원 스케치 확인
내 스케치와 별도로 다른 팀원들도 각자 스케치를 해왔다. 나처럼 피그마로 한 사람도 있고, 패드 스케치, 공책 스케치도 있었다.
이를 각 페이지별로 나눈 뒤 같은 페이지끼리 묶어본다.
그리고 여기서부터가 중요하다.
각자의 스케치를 보며 스케치 전체에 대한 평가나 선택이 아니라, 안에 구성하고 있는 요소에 투표를 한다.
그렇게 많은 사람들이 선택한 기능들을 한 데 모아 결합시켜 새롭게 구성을 해볼 수 있는 것이다.
투표를 통해 모인 요소들은 기능적은 면, UIUX적인 면 등 다양했다.
이제 우린 이걸 바탕으로 최종 스케치를 결정할 수 있다!
그 전에!
일단 테오의 스프린트에서 말하는 UIUX 최고 권위자를 뽑아야 했다.
아무래도 사공이 많으면 배가 산으로 가는 법, 그래서인지 디자인/UIUX에 대한 결정권을 지니는 1인을 뽑아 해당 인원의 선택 방향으로 디자인을 결정 짖는 것이다.
- 논의는 같이 할 수 있다.
- 단, 선택은 결정권자의 몫
- 꼭 투표가 많은 것을 채택할 필요는 없다.
- 팀원은 혹여 자신의 생각과 다르더라도 결정권자의 결정을 존중한다.
호오.. 꽤나 무소불위의 권력을 얻게 된다.
그리고 이날 별개로 모집한 디자이너가 참석했다.
뽑는건 당연히 투표였고, 난 당연히 디자이너분이 뽑힐 거라 생각했다.
어렵게 모시기도 했고 일단 '디자이너'자나?
근데 투표 결과,,,
이왜나..? 찐 의문이었다ㅋㅋㅋ(대상혁의 용안을 쓴 건 제가 아닙니다)
아마 스케치해온 내용이나 여러 멘트, 아이디어를 말씀드리고 방향성을 제시했던게 팀원들에게 꽤나 좋게 보였던 모양이다.
내 닉네임이
티제이였다.
약간의 부담과 걱정이 되었다. 그치만..! 그래도 뽑혔으니 열심히 해봐야지!!
이렇게 난 UIUX/디자인 쪽 리딩을 맡게 되었다.
그리고 컨셉도 디자이너님과 논의해봤을 때 내가 가져온 보따리의 컨셉이 좋은 것 같다고 하셔서 보따리를 메인 컨셉으로, 그리고 다른 팀원이 생각했던 답변=구슬이라는 컨셉을 가져와
"보따리에 구슬(답변)이 담긴다"가 최종 컨셉이 되었다.
이렇게 되니 진행을 하면서 UIUX쪽 리딩 뿐 아니라 기획면에서도 리딩을 맡게 되었다.
왜냐하면 메인 컨셉을 내가 가져온 것으로 하다보니,
가령 UIUX를 왜 이렇게 잡았는지에 대해 구상하면서 생각한 방향이 곧 기획이었고, 이를 팀원들에게 설명하고 안내하게 되면서 자연스럽게 기획자 역할까지 맡게 된 것.
뭐 나쁘지 않았다. 이전 직장에서도 기획은 여러 번 해봤고, 리딩도 맡아본 적 있었으니 그때의 경험을 살려 다시금 다듬어보는 것이니까.
최종 스케치 결정
결정권자(나)도 뽑았으니 이제 진짜 최종 스케치를 결정했다.
앞서 언급한 것처럼 요소에 집중해서 팀원들이 좋다고 생각한 요소들을 최대한 반영하는 방향으로 살려 진행했다.
이렇게 서비스 방향의 가닥이 와이어프레임이 정해지면서 보다 구체화되었다.
우선 순위와 계획
흔히 하는 계획 사사분면이 있다.
중요도와 긴급한 정도를 각각 x, y축으로 두어서 중요하면서 빨리 끝내야하는 일을 1순위, 중요하지만 긴급하지 않은 일을 2순위, 중요하진 않지만 긴급한 일을 3순위, 중요하지도 긴급하지도 않을 일을 4순위로 정하여 일에 대한 계획을 세운다.
이걸 아이젠하워 매트릭스라고 한다.
우리의 경우 소요시간과 임팩트를 x, y축으로 삼아 배분을 시작했다.
그리고 이때는 전체적인 일정 관리를 할 PL(Project Leader)를 뽑았다.
이땐 PL역할을 맡아보고 싶어한 팀원이 자발적으로 지원해서 맡게 되었다.
Day4: 최종 일정 결정
개발 진입 전 Last Day 드디어 결정의 날이었다.
이전까지 과정에서 항상 강조된 건 '결정하지 않는다'였다. 그저 많은 의견을 내놓고 공유하는 것!
그것이 포인트였다. 그러나 이 전날 기점으로 결정을 시작하게 된 것.
첫번째는 디자인(스케치)이었고, 이제는 개발에 대한 시기가 온 것.
BDD
이 과정에서 처음 BDD라는 것을 해보게 되었다.
BDD란 Behavior Driven Development로서, 행동에 기반을 두고 task를 정의해 나가는 것이다.
태오 스프린트에서는 이 것을 4단계로 나누었다.
when
첫번째 when에서는 사용자의 모든 행위를 나열한다.
가령 공유하기 버튼을 클릭한다. 뒤로가기를 클릭한다. 설정을 바꾼다. 같은 것들이다.
(사실 거진 버튼 클릭 행위들이다)
then
그 다음엔 then에서 행위에 따른 결과를 적는다.
공유하기를 클릭했으면 클립보드에 복사 혹은 복사가 되었다는 알림창 표시 등이 될 수 있을 것이다.
given
given은 조건이다. 같은 행위여도 주어진 상황 조건에 따라 달라질 수 있다.
예를 들면 우리 서비스의 경우 사용자가 받은 질문이 있는지 여부에 따라 메인 페이지에 표시될 정보가 달라진다.
- 답변이 있다 -> 답변 중 랜덤하게 미리보기를 띄운다
- 답변이 없다 -> 나돌아보기 기능에 대한 추천 멘트를 띄운다.
이런 식이다.
이렇게 모든 기능들을 나열하고 위 세개를 작성하고 이어붙이면 이게 곧 User Flow가 된다.
이 flow는 유저의 니즈에 초점을 맞추고 생각한다.
"사용자가 ~을 하고 싶다면?"이란 생각을 밑바탕으로 위 given-when-then을 쫓는 것이다.
처음해보는 설계방법론이었기 때문에 나를 포함해 모두들 헤매기도 했지만 나름 기획까지 맡고 있던 내가 정리를 하며 가닥을 잡아나갔다.
원래 PL분이 리딩하면 되는 부분이지만 사정상 중간에 가셔야했기 때문에 내가 진행해보고자 했다.
(월권 아님..!)
SDD
이제는 데이터 설계다. 백엔드 업무를 맡아서 하긴 했지만 전문적으로 한 것이라고 할 순 없기에 백엔드 파트의 방법론에 대해선 전무하다 싶은데, 그래서 SDD도 처음 접해봤다.
Schema Driven Development
이름 그대로 스키마를 바탕으로 개발을 하는 것이다.
잠시 테오의 스프린트 피그잼 시트에 있는 한부분을 첨부해보자면, 초점은 변하는가?이다.
화면에서 요소들을 구분하고, 해당 요소에 어떤 행동을 취했을 때 바꾸는게 있다? 그런데 그것이 디자인이 아니다? 그렇다면 모두 데이터인 것이다.
테오 스프린트에선 앞선 과정에서 BDD를 선행했기 때문에 보다 쉽게 SDD를 할 수 있다고 얘기한다.
Why? 우리에겐 정리된 결과, then이 있으니까.
Then은 스키마의 변화이다!
페이지 별로 행동에 대해 변화된 결과를 then에 정리해두었기 때문에 이에 초점을 맞추면 보다 쉽게 SDD를 진행할 수 있는 것이다.
처음 BDD를 할 때 각자 맡은 페이지 파트가 있었기 때문에 그걸 이어서 SDD에서도 각자 같은 파트를 맡아 진행했다.
그리고 다같이 훑으면서 더블 체크.
편안한 마무리.
컨벤션과 스택
이제는 프론트와 백이 나뉘어 각자 편한 방식의 컨벤션과 스택을 선정했으면 됐는데,
일단 PL이 빠져있다 보니 이 부분은 다음 날 개발 진행에 앞서 한번 더 모여 토의하고 진행하기로 했다.
PL이 프론트였기 때문에 백은 별도로 컨벤션과 스택 정리를 진행하긴 했다.
실제로 다음 날 미팅에서 컨벤션과 스택을 정의하고 시작했다.
컨벤션 같은 건 웬만하면 나도 다 겪어본 것이었고, 스택에서 좀 처음 겪어보는 것들이 있었다.
pnpmtailwind.cssshadcn.uizod
대략 이정도? tailwind의 경우 찍먹 정도는 해봤는데 제대로 써본 적은 없다.
물론 이전 직장에서 자체적은 css정리 후 tailwind처럼 클래스로 사용하는 방식을 취했기 때문에 사용법은 꽤 겪어봤다고 할 수도 있겠다.
그 외엔 사실 다 처음 들어봤다. 하지만 새로운 스택을 경험해보는 것은 언제나 환영이다.
설계 마무리
여기까지가 토의와 설계 과정의 마무리이다.
이렇게 4일차까지 화요일부터 시작하여 금요일에 마무리되었고, 주말의 경우엔 정기 미팅 없이 각 팀별 자유 개발 시간이 주어졌다.
그리고 월요일이 데모데이이기 때문에 사실상 실 개발 시간은 약 이틀이 주어져 있는 것.
진짜 스프린트답다ㅋㅋ 좋다 이런 경험!
덕분에 오랜만에 열정도 끌어올리고 개발과 관련된 일에 집중하면서 시간을 쏟고 있다.
이제 이 다음 진짜 개발이 시작됐다.
