EEOS - 5월 2주차 진행 상황

근황토크

이번 연휴에는 서울에 가서 잠시 리프레쉬를 하고, 다시 광주에 돌아왔다. 서울에 가면 아무것도 하고 싶지 않은 습관 때문에 푹쉬었다만, 다시 현실로 돌아오니 해야 할 일들이 산더미이다. 아마 PM 스터디가 아니었다면, 블로그 작성도 미루고 미루지 않을까 싶다. 그래서 PM 스터디를 한게 참 다행인것 같다^^

이번주에도 EEOS의 진행상황과 얻은 인사이트들에 대한 글을 작성해야 할 것 같다. 최근 IT 트렌드나 PM 방법론에 대해서도 작성하고 싶지만, 해야 할일이 쏟아지는 이번주에는 불가능할 것 같다.

제품의 탄생 (오이카와 다쿠야, 소네하라 하루키, 고시로 구미코 지음)

좋은 책을 우리 블랙컴퍼니 팀원들에게 선물받았다. 우아한 형제들의 블로그에도 추천하는 책이라고 하던데 조금씩이라도 읽어볼 생각이다. 다음주에는 꼭 책과 관련된 내용을 쓰도록 하자..! (EEOS 진행상황도..)

시스템의 구축

EEOS는 벌써 2학기째 진행하고 있는 프로젝트이다. 우리 에코노베이션은 주로 한 학기에 한 프로젝트를 하고 있지만, EEOS의 연속성과 동아리를 위한 서비스라는 특징 덕에 운좋게 학기를 더 유지하고 있다.
사실 EEOS를 처음 만들때부터 서비스의 지속성을 꿈꿨었다. 대게 대학생의 프로젝트가 그렇듯이, 프로젝트가 목표 지점에 도달하면 (해커톤이나, 동아리 프로젝트) 리팩토링을 약속하고 프로젝트를 가슴 저 편에 묻어둔다. 이전의 내가 했던 프로젝트도 그러했다. 이러한 점들을 개선하고 싶었고, 그렇기에 더 지속 가능한 프로젝트를 하고 싶었다.

"EEOS Must go on!" 라는 거창한 슬로건을 현실로 유지하긴 위해선 PM인 나 뿐만 아니라 현재의 팀원들이 다른 팀원들로 대체되어도 견고하게 유지되는 시스템이 필요했다.
저번 학기에는 사실 이런 시스템을 만들기보다는 당장 눈 앞의 결과물을 만들어 냈기 바빴다. 그렇기에 1기의 팀원들과는 어떻게든 결과물을 만드는 것에 시간을 쏟았고 우리는 결국 서비스를 만들고, 사용자들을 얻을 수 있었다.
2기의 팀원들과 함께 할 때는 나는 앞선 이유들, 내가 학교를 졸업하는 것은 뭐가 되었든지 간에 분명한 사실이라는 것때문에 시스템의 구축을 위해 힘썼고 그 결과 EEOS를 위한 블랙컴퍼니의 Work Process를 만들 수 있었다. 한번 살펴보도록 하자.

Step1. VOC

VOC, Voice of Customer를 수집한다. EEOS를 가장 많이 사용하는 에코노베이션의 회장단과는 한 달에 한번 정도 미팅을 진행하고 있다. 미팅을 통해서 EEOS가 개선해 나가야 할 점들을 노션의 VOC페이지에 기록한다. 또한 매번 새로운 버전이 업데이트될 때마다 Padlet(EEOS 2.0 배포 당시의 자료)을 함께 첨부한다. 패들릿에서 유저의 의견들을 확인하여서, 마찬가지로 VOC페이지에 기록한다. 참고로 유저들의 의견에 조금 더 가까워지기 위해, 이러한 패들릿을 EEOS의 홈화면에 첨부할 예정이다.

Step2. BackLog

VOC를 면밀히 검토한다. 매번 팀원들과 Term (약 2개월)이 끝나고 VOC를 읽고 BackLog를 추출한다. EEOS 내에서의 영향력과 실질적인 구현 난이도 등을 고려하여서 중요도를 부여한다.
VOC만큼 소중한 것은 없지만, 그렇다고 해서 모든 VOC를 다 백로그로 추출할 수는 없다. 예를 들어 우리가 만든 것이 사용자의 의도와 다르게 쓰이는 경우에서는 기능을 개선하기 보다는, 사용자에게 기능을 의도대로 쓰이게 교육시키는 과정을 거치면 된다. 또한 사용자가 우리의 의도와 너무 다른 기능을 요구하는 경우에는 이러한 사용자의 니즈가 모든 사용자가 만족할 수 있는 기능인지를 또 검토해봐야 한다.
사실 이러한 과정에서 데이터의 중요성 뼈저리게 느꼈다. 팀원들과 논의하다보면, 어떤 VOC가 우리 서비스를 올바른 방향으로 가게 하는지 논쟁하는 경우가 있다. 결국 이러한 논쟁을 최소화하기 위해서는 데이터가 필요하다는 것이다. 데이터가 있어야만 의견의 근거가 생기고 수치로 의견을 판단할 수 있다. 그래서 우선적으로 FE가 Vercel(배포)를 통해서 사용자 데이터를 확보해기로 했다.

Step3. Update

Backlog를 추출했다면, 이제 어떤 기능을 배포할지 선택하면 된다. 우리의 스프린트는 주로 2주를 기준으로 하기에, 2주동안 어떤 기능들을 업데이트할지 백로그에서 선택하고, 열심히 개발하여서 배포한다.
나를 포함하여, 우리 팀원들이 현직 개발자가 아니기에 이중에서 어떤 기능들은 학습이 필요한 기능들도 있다. 그럴 경우에는 첫번째 스프린트에서는 어려운 기능에 대한 학습 + 구현할 수 있는 기능을 진행한다. 그렇게 학습이 어느정도 완료되었다면, 두번째 스프린트에서 학습을 진행한 기능을 구현하도록 한다.

EEOS Work Process

그래서 우리의 프로세스이자 시스템은 VOC를 통해 유저들의 니즈를 명확히 파악하고, 이를 토대로 백로그를 추출하여서, 기능들을 선택하여 업데이트를 하는 것이다.

사실 대단한 것은 없다. 누가 보면 당연하다고 생각되는 일일수도 있다. 그러나 지속 가능한 프로젝트를 하고 있는 팀이라고 한다면 한번쯤은 고려해볼만한 문제가 아닌가 싶다.

Next Week, 시스템의 붕괴

1주차 진행상황에도 공유했듯이 우리 프로젝트는 위의 Work Process를 토대로 한 매주마다의 계획이 있었다. 하지만 프로세스가 붕괴되었다..^^

시스템의 붕괴는 너무 거창스러운 말이고, 기존의 버전인 2.2에서 2.3으로의 업데이트가 아닌 3.0을 계획하고 있다. 이러한 내용은 다음 3주차 진행상황에서 적어보도록 하겠다!