첫 스프린트 회의 회고: 기획해보기

재취업을 준비하고 6개월 만에 새로운 회사에 입사하게 되었다.

나는 신규프로젝트에 투입되었다.

신규프로젝트팀에 확정된 인원이 나포함 프론트엔드 2명이라 기획, 백엔드, 디자이너가 공석인 상태지만 여러 가지 경험을 해볼 수 있는 기회라 생각했다. 아직 초기단계라 주 2회(월, 금) 스프린트 방식으로 윗분들과 상황을 공유하기로 했다.

사업성과 예비 고객은 기존에 잡혀있는 상태였기 때문에 첫 임무로 기획의 대략적인 스케치를 구상하는 임무를 맡게 되었다. 기획안 스케치 툴은 피그잼을 활용하기로 했다.

기획을 어떤 식으로 구성하면 좋을까?

프로젝트는 총 3개의 프론트 어플리케이션으로 구성된다. 나는 기존 회사에서 어드민을 개발한 경험이 있어 어드민서비스 개발 스케치를 맡았고 선임 개발자분은 객실 쪽 서비스를 맡게 되었다.

처음에는 둘 다 기획스케치를 초반부터 잡았던 적이 없었던 터라 무작정 서로 구성해 보는 방식으로 접근했다.

접근했던 방식으로는

결제, 하드웨어가 연관되어 있고 3개의 어플리케이션이 지리적으로 독립되어있다 보니 실제유저가 어떤 식으로 사용하는지를 파악해야 시작할 수 있다고 판단했다.

피그잼에서는 도식화할 수 있는 툴이 제공되고 있었고 도형과 화살표 등을 통해 나름대로 구체화하여 확인을 요구했었다.

과거로 돌아가 다시 시작한다면?

-> 항상 그렇지만 초기에 좀 더 구체적인 확인을 요구했어야 핬다는 생각을 했다. 예를 들어 "객실 --결제요청--> 어드민" 이런 식의 구체화를 설정하기 전에 각 하드웨어 간에 상관관계 or 어떻게 동작하는지를 먼저 파악했어야 했다.

A라는 기기가 동작하면 B라는 기기에 출력이 발생하는지, 아니면 서로 독립되어 있는 관계있는지 등을 먼저파악하고 흐름을 파악했어야 했음을 의미한다.

어떤 기능은 외부적으로 알릴필요가 있는 기능들이 있을것이고 반대로 내부적으로만 처리하는 기능이 있을것이다. 예를 들어 주문같은 기능은 객실에서 발생했을때 어드민에서 처리를해줘야하지만 어드민페이지의 다크모드설정같은것은 외부에 알릴필요가 없다.

여기서 주문처리 같은 플로우는 각 애플리케이션끼리 의존성이 있기 때문에 이를 먼저 정리하지 않은 상태에서 각각 스케치를 진행하면 나중에 수정사항이 분명히 발생하게 된다.

어떤 문제가 발생했었는가?

의존성이 있는 주문처리단계를 구상하는 단계에서 공유하여 작성하지 않고 각자 작성하다 보니 주문처리 뎁스를 각각 다른 방식으로 정의하게 되었다. 자연스럽게 세부구현이 어긋나게 되었고 처리단계에 있는 ui가 각자 생각하는 방식이 달라지게 되었다.

상품을 관리한다던지, 유저를 관리한다던지 등 어떤 기능을 제공할지 내비게이션에 들어갈 항목리스트를 작성해 보자

그러고 나서 예를 들어 상품관리에서 어떤 기능을 제공할지, 실제 이 애플리케이션을 이용하는 사용자가 어떤 행위를 할지를 생각해 보자(검색을 한다 던 지, 상품을 수정한다던지 등등)

어떤 문제를 미리 방지했는가?

상품을 수정하는 기능을 제공한다고 했을 때 "이 카테고리의 상품을 여기서 수정해도 되는가?"와 같은 문제점을 발견하여 카테고리를 분류하는 기준을 다시 한번 확인할 수 있게 되었다.

예를 들어 결제과정이 객실 <-> 어드민과 의존성이 있다면 어드민 or 객실내부에서 발생하는 구체적인 플로우를 다시 정의해 보는 것이다.

어떤 문제를 미리 방지했는가?

주문처리단계를 너무 세부적으로 나눈 것은 아닌가? 어드민에서 이를 관리하는 데 있어 피로감이 있지 않을까 와 같은 문제를 발견하여 적당한 주문처리단계를 정의할 수 있게 되었다.

- 애플리케이션의 의존성을 확인하기 전에 좀 더 윗 단계인 실제 유저 및 하드웨어 자체의 기능이 어떻게 동작하는지 확인하자

- 무엇인가 확실히 정의되지 않았을 때는 탑다운 방식을 지향하는 게 좋지 않을까라는 생각이 들었다

- 내가 바라보고 있는 방향이 상대방과 일치한 지를 수시로 확인해 보자

- 같은 공간(피그잼)을 활용하여 남의 작업물을 볼 수 있다는 생각이 깔려있어 오히려 다른 사람이 어떻게 작업하는지를 신경을 안 쓰게 되는 상황을 만들지 말자. 수시로 확인하자.