유저 스토리와 스키마를 통해 커뮤니티 비용을 줄인 경험

빠르게 협업하기 위해서 가장 중요한 점은 뭘까?

 

회사라 함은 하루하루 한주한주 매일 매일 돈이 소모되면서 비즈니스를 이루는 측면에서 창고에 돈을 쌓아놓고 있지 않은 이상  철학만 할 수없는 곳이 대부분의 현업이 가지는 속성이라 그 과정에서 속도를 빼놓을 수 없다는것을 아주 뼈저리게 느끼고있다. 

 

애자일의 '민첩함' 보다도 '불확실성에 대한 대비' 로써의 측면을 좀 더 좋아하지만 애자일이라는 프로세스가 많이 존중받고 사람들이 추구하는 이유 중 하나로 '민첩함' 역시 빼놓고 생각할 수 없다고 본다.  

 

개인적인 경험으로  '빠른' , '애자일한' 협업에서 가장 중요한 점이자 가장 큰 장애물은 각자가 생각하는 지점이 다른 것이고 그런의미에서 가장 어려운 건 모두가 같은 곳을 바라보는 것이라고 생각한다.

  

모두가 OK 사인을 내고 나서 각자 작업으로 들어가고 중간점검을 받았을 때 놀랍게도 모두가 다른 생각을 하는경험을 취업하기 이전에도 수 없이 많이 해봤기 때문에 커뮤니티 소통 비용을 확 줄였을때의 생산성이 얼마나 큰 시너지를 불러오는 지 확신하며 오늘은 협업의 생산성에 대한 경험을 글로 공유해보고자 작성하게되었다. 

 

 

모두가 쓸 공통 언어 : 유저스토리

 

 

유저스토리란 무엇인가? 간략하게 실 예제와 함께 적어보자면 다음과 같다. 

 

학생으로서(어떤 사용자), 나는 모든 강의 자료를 온라인에서 접근할 수 있기를 원한다.(원하는 것) 그래서 언제 어디서나 공부할 수 있도록 하기 위해서이다 (담고있는 가치 )

 

중요한 건 구체적인 사용자 유형(역할), 원하는 행동(목적), 그리고 그 이유(가치)를 포함하여 명확하게 전달한다는 것이다.  

 

 

어떤 부연설명도 없이 처음 유저스토리를 봤을때의 감상은 다음과 같았다. 

 

뭐야 이게? 별거 없어보이는데 

 

나중에 유저스토리는 뭐고 애자일은 어떻게 하는것일까 하고 관심이 넓어져 책을 읽어봤을때 유저스토리에 대해서 별거 없어보이거나 우습게보이면 오히려 유저스토리의 본 목적은 성공이라는 대목이 적혀있었는데. 이제는 그게 무슨 말인지 알겠다.

 

우리는 '공용어' 아니 '소통을 위한 공통 컨벤션'이 필요했다. 그리고 그게 유저스토리였다. 

 

바뀌기 전 유저스토리

사실 내가 들어오기전에도 유저스토리는 작성되어있었다. 그러나 형태가 많이 달랐는데 개발자 친화의 굉장히 어렵게 느껴지는 형태의 유저스토리였다.

 

각 항목은 수많은 분기처리라고 밖에 표현할수없는 분류로 나뉘어져있었고 

 

그 안에 세부적인 상태들이 괄호안에 표시되었다.

 

서버와 통신한다는 문구나 무엇이 이루어진다 라는 적어도 내가 읽어 보았을때는 조금 과할 정도의 설명들이 부연 표시되어있었다. 

 

스토리의 형태였지만 유저입장에서 얻을수있는 가치에 초점이 맞춰져서 작성된 요구사항의 모음이라는 느낌이 아니라  

 

유저는 이런식으로 움직여야되고 그렇게 행동했을 때 어떤식의 경고나 유효성 처리를 하겠다는 선언을 모아둔 유효성 검사 문서 였다.

 

한편으로는  이야기를 들어보면 그럴 수 밖에 없기도 했다 

 

내가 들어오기 전까진 개발자들 밖에없었고 기획자도 없었으니까. 

 

단지 확실히 느낀 건 나 역시도 개발자인데 읽기가 굉장히 힘든 문서였다. 

 

정규식을 글로 적어놓으면 이런 느낌일까 싶었다. 

 

 

바뀐 후 유저스토리

내가 이전 유저스토리에서 바꾼 부분은 다음과 같다.

 

1. 수 많은 분기처리에 대한 메세지 역시 스토리에 녹여내서 전달해줄 수 있는 가치로 표현하여 한문장으로 줄였다. 

 

기존의 유저스토리 : 

(분기처리 페이지 이동) 유저는 ~페이지에 접근한다. 

 

바꾼 유저스토리: 

유저는 ~을 하기위해서 ~페이지로 이동할 수 있다. 

 

2. 다 같이 작성하도록 유도했다. 

 

기존의 유저스토리는 개발자들 위주로 작성이 되어있었고 어떤 피드백도 받지않았었다면 

내가 들어오고 나서는 모두가 인수조건을 완성하는 형태로 진행하고자했다. 다만 어려운 점이 있었으니 개발자외에 몇몇  직군은 프리랜서 형태라서 늘 상주하고있지않았다. 그래서 별 수 없이 다 작성하고나서 이런식의 기획의도가 맞는지 디자인 의도가 맞는지를 다시 물어보는 작업이 연속되었다. 

 

 

3. 스키마 작성 

 

이건 사실 유저스토리는 아니다. 단지 공용어를 정해서 다같이 합의한 상태에서 커뮤니티 비용을 줄였다는 측면에선 내가 도입한 부분이라서 공유하고자하는 부분인데.

 

개발 후 에는 Swagger를 통해서 확인하면되지만. 그 이전에는 대략적으로 이런 형태로 스키마를 짜서 만들겠다는 합의를 통해

 

표 형태로 대략 헤더에는 어떤 값이 들어갈것이고 어떤 식으로 백엔드와 프론트엔드가 데이터를 주고받을지에대한 협의를 정하도록 했다.

 

그 이전에는 이런 과정이없어서 그냥 이렇게 주겠거니 하고 만들수밖에없었다. 

 

다만 스키마 협의 내용은 절대적인게아니라서 각자 구현하면서 스키마는 변할 수 있는 부분임을 인지하고 시작하는게 나름 중요한 포인트였다. 

 

'스키마를 작성하고 난 다음 부터는 스키마를 토대로 다시 이야기를 나누고 개발에 안정성을 더할 수 있어서 좋았다.' 고 동료도 평가해주었다.

 

 

4. 번호 와 인덴팅 구분 

 

기존에는 번호와 인덴팅이 없어서 읽기힘들었다면 그런 세세한 가독성까지 신경쓰고자 노력했다. 

거기에 더해 스크린샷이나 시각자료의 첨부도 귀찮음을 마다하지 않고 작성하고자했다. 

 

 

 

그래서 얼마나 빨라지고 달라졌는가? 

이부분은 사실 절대적인 속도 역시 빨라졌지만 무엇보다도  다 같이 합의한 내용  

그리고 읽기 쉬운 문서 이 두가지 측면에서 오는 안정성과 커뮤니티 비용이 줄어든것이 매우 컸다고 생각한다. 

 

적어도 내가 배웠던 애자일 개념에서는 스토리 포인트라는 일의 처리량 진행 속도에 대한 측정도 이루어져서 그런 부분에서 객관적인 지표로 말할수 있었으면 좋았겠지만

 

나는 PM 도 아닐뿐더러 그냥 보조 역할로 진행한것이라 작업자입장에서

 

가장 좋았던 것은 '심리적 안정감'에 보탬이 되었다는 부분인것같다. 

 

스키마를 정하고 문서를 다시 읽는데에 있어서 거부감도 없었기때문에. 전보다 일하는 입장에서 많이 찾는 문서. 그것만으로도 족하지만 아쉬웠던 점은 

 

여기에서 티켓으로 나눌 만큼의 세분화나 업무 분장에 도움이 되어  구현할때에도 더많이 찾는 문서가 되는 것. 까지가 내 다음 목표이다. 

 

그래서 아마 다음에 유저스토리로 또 한번 더 글을 적게된다면 그때는 '유저스토리라는 시스템을 쓴 경험' 이 아니라 '유저스토리로 업무 분장까지 가능하도록 인수 조건을 나누고 애자일 한 방식으로 진행하기 위해 노력했던 사항' 들에 대한 글이 아닐까 생각해본다.