brunch

브런치북 PO의 성장일기 11화

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by kaily Apr 29. 2022

이 프로젝트는 왜 힘들까?

같이 하는 프로젝트가 힘들다면 우리 모두의 책임이다.

프로젝트를 진행해 본 분들이라면 한 번쯤 해봤을 생각인 '이 프로젝트가 왜 힘들까?'에 프로세스 별로 깊게 회고해봤다. 수년간 여러 번의 프로젝트를 진행하며 수많이 했던 생각들인데, 이번에 이 생각이 또 들다니!

보통 과제를 진행하면 어떤 부분에 문제가 있어 이 프로젝트가 힘들게 느껴지는지는 실무자들은 정확히 알 수 있다고 생각한다. 물론 이유가 한 가지는 아닐 테지만, 어떤 부분이 문제였는지를 생각해 보다 보면 잘 챙기지 못 한 부분이 보이기 시작한다. '이 부분을 더 챙겼으면 좋았을 텐데..'라는 생각도 잠깐.

힘들게 프로젝트를 겨우 마무리하고 나면 '드디어 론칭했다'는 행복감에 사로잡혀 힘들었던 프로젝트의 과정을 잊곤 했던 것 같다. 그래서 어떤 상황에 어떤 문제가 발생했는지 정확하게 인지하고, 이후 진행되는 프로젝트에는 반복하지 않기 위해 프로젝트 과정 중 발생했던 문제를 디테일하게 기록해뒀다.

이 글은 프로젝트를 진행하고, 론칭하며 어떤 문제로 프로젝트가 힘들었는지 기록해놓은 나의 회고글이다. 회고에는 잘했던 점과 개선할 점에 대해 써 내려가는 게 맞지만, 이번 글에선 어떤 부분이 문제였고 그래서 어떻게 개선했어야 했는지에 대한 부분을 중심으로 써 내려가려고 한다.

프로젝트를 하며 한 번이라도 '너무 힘들다..'라고 생각해본 PO들이나 Makers들이 읽고 공감하며, 도움받았으면 좋겠다.

상반기에는 여러 개의 과제를 패럴렐(parallel)하게 진행하느라 정말 정신이 없이 흘러갔다.

눈 깜짝할 사이에 4월 말이 되었고, 3개 과제 중 1개 과제를 *릴리즈(앱/웹 소스 배포를 말함)시켰다.

4월 오픈한 과제는 가시적으로 확인할 수 있는 부분이 적었고, 개발 작업이 많은 과제여서 처음 *AC(Acceptance criteria: 인수기준, 즉 요구사항 정리부터 구현 방향이 작성된 기획안) 작성부터 쉽지 않았다. 각 파트별로 개발 구현 방식과 구조가 달라 어디서부터 어떻게 정의해야 각 파트별 개발자가 쉽게 작업할 수 있을지를 최대한 고민하여 문서 내 정의하고 AC리뷰를 진행했다.

프로젝트 진행에 필요한 모든 파트가 모여있는 애자일 조직

리뷰 중 내가 어떤 부분을 우려하고 있는지 Makers분들께 말씀드렸고, 우려스러운 부분을 해소하기 위해선 각 파트별로 누락되었다고 생각하거나, 추가 고민이 필요하거나, AC 내 정의가 잘 못 된 부분이 있다면 의견을 달라고 말씀드렸다.

보통 처음 AC 리뷰를 할 때는 Makers분들이 내용 숙지가 잘 안 되어있거나, 현재 이 과제의 영향 범위 파악을 답하게 하지 못한 상태라 의견을 적극적으로 주시지 못하는 부분에 대해서는 인지하고 있었다.

그래서 AC 리뷰 후 주 2회 *스크럼 미팅(스크럼 방법론에서 사용하며, 날마다 하는 짧은 회의를 뜻함)을 진행할 건데 괜찮은지 의견을 여쭙고 과제 오픈전까지 스크럼을 진행하기로 했다.

스크럼 미팅도 PO마다 다른 스타일로 진행되는데 나는 우선 아래와 같이 진행했다.

각 단계별 공유할 내용이 없다면 생략한다.

AC 업데이트된 내용 공유

Action Item(무엇을, 누가, 언제까지 해야 하는지) 확인

문의사항 질의

파트별 진행 현황/일정 확인

우선 AC 리뷰 때 Makers분들이 '이런 부분 우려된다, 또는 이 부분 빠진 것 같다 또는 이거 맞나요?'라고 물어보셨던 질문에 대해 고민해보고 AC를 수정한다.

AC 리뷰 이후 수정된 사항은 AC 내 붉은색으로 눈에 띄게 표시해놓고, 이를 스크럼 미팅 때 Makers분들께 공유하고 나와 싱크(Sync)가 맞는지, 수정한 부분에 이슈가 없는지를 체크한다.

그 다음엔 Action Item을 체크한다.

AC리뷰 때 '이건 잘 모르는데, 소스 보고 다시 말씀드릴게요.'의 경우가 보통 Action Item으로 잡힌다. 리뷰 때 회의록을 참고하여 Action Item이 어떤 게 있었는지 체크하고 실제 확인이 됐고, 그 내용이 무엇인지 확인되면 완료 처리한다. 만약 누군가 Action Item을 확인하지 못했다면 언제까지 확인할 수 있는지 기한(Due)을 확인하고 다음 스크럼 때 다시 확인한다.

세 번째로는 문의사항에 대한 질의다.

AC 리뷰 후 발생한 문의사항 또는 수정 방향에 대한 개발 문의가 있는 경우에 속한다. 내가 알지 못하는 기술적인 부분에 대해 적어뒀다가 Makers분들께 여쭤보고, 내가 생각한 방향이 맞는지 그리고 이 방향으로 AC를 수정해도 일정상 문제가 없는지, 다른 디펜던시가 없는지 등에 대해 확인한다. 개별적으로 묻지 않고 스크럼 때 공개적으로 묻는 이유는 다른 파트 개발자들도 참고해야 하거나, App파트에서는 문제가 없다고 했지만 실제 API 파트에서는 문제가 있는 경우가 있을 수 있기 때문이다. 각 파트별 디펜던시가 있는 부분에 대해선 항상 모두가 모인 자리에서 한 번에 체크하는 게 좋다.

마지막으로 각 파트별 진행상황에 대해 체크한다.

이번 과제에 같이 진행한 파트는 디자인, App, Web, API 파트였고 각 파트별로 어느 정도 진행되고 있고 언제까지 완료하여 공유 줄 수 있는 지를 체크한다.

이렇게 총 4개의 큰 카테고리에 속한 부분을 체크하는데, 보통 짧게는 10분 길게는 30분 정도 쓴다.

나는 스크럼 미팅을 길게 잡는 것을 싫어하는데, 이유는 모든 Makers들의 작업 시간을 내가 사용하고 있다는 생각 때문이다. 그래서 항상 그들의 작업 시간을 확보해주기 위해 최대한 짧고 간결하게 체크하려고 노력했다.

이렇게 프로젝트 오픈 전 총 10번의 스크럼을 진행했다. 스크럼 미팅을 통해 각 파트별로 크로스 체크하며 꼼꼼하게 챙기려고 노력했다. 다행히 큰 무리 없이 개발 완료까지 스크럼 미팅을 진행했고, 모든 파트의 개발이 완료되었다. 그리고 본격 적인 QA 시작 전 최종 체크하는 *Sanity Test(주요 테스팅 업무를 수행하기에 충분히 적합한가를 판단하기 위해 수행하는 테스트) 전 날 문제가 발생했다.

모든 파트가 개발 완료된 소스를 QA 환경에 배포했고, 이를 테스트하는데 Sanity Test를 수행할 수 있는 충분한 환경이 아니었고 각 파트별로 생각하지 못했던 이슈가 터져 나오기 시작했다. Sanity Test에 작성된 체크리스트를 모두 Pass하지 못 하면 QA 시작 일정이 밀리고, 결국 오픈까지 밀릴 수 있는 큰 이슈였다.

각 파트별 개발자분들이 Sanity Test를 위해 여러 번 소스를 수정해주시고, QA 환경에 재배포해주셨다.

밤 10시가 넘어서야 Sanity Test의 80% 수준을 Pass 할 수 있었다. 20%에 대한 부분은 특정 파트의 개발이 수정 중이고 다음날 오전에 확인하라고 하여 알겠다 하고 안심하며 퇴근했다.

보통 Sanity는 다음날 오전 11시 전까지 체크하는 게 내부 룰이었고, 10시 출근임을 감안했을 때 20%에 해당하는 부분의 체크는 1시간 정도면 충분하다고 생각했다. (~~참,, 오만했다..~~)

다음 날 오전 10시가 됐고, 세니티를 위해 QA 환경에 접속했는데 에러 페이지가 뜨며 접근이 안됐다. 담당 개발자를 멘션 하여 언제 배포가 되냐 물으니, 11시 이후 확인 가능하다는 답변을 받고 다시 초조함에 멘털이 흔들리기 시작했다. Sanity는 11시이므로 무조건 11시 전에 배포하여 테스트할 수 있어야 한다고 강조하여 재차 말씀드렸다. 다행히 11시까지 진행되는 Sanity 테스트가 무사히 완료되었고 마음이 놓이니 이 과제에서 어떤 부분이 잘 못 돼서 이렇게 초조하고, 다급하게 과제 오픈을 준비하게 됐을까를 고민하기 시작했다.

처음엔 자책을 했다.

'내가 더 꼼꼼하게 챙겼어야 하는데...'

'일정에 어느 정도 룸을 갖고 진행했어야 했을까?'

'왜 이런 개발 디펜던시를 챙기지 못했을까?'

생각해보니 모든 게 다 '나' 때문인 것 같았다. 이런 생각이 머릿속을 지배하니 '과연 내가 PO로서 잘하고 있는 걸까?'라는 의문이 들었다. 혼자 생각해봐야 어떤 게 문제인지 잘 모르니 친한 개발자한테 물어보기로 하고 DM을 보냈다.

나: 이번 프로젝트 힘드셨죠? 너무 고생 많으셨어요. 제가 더 꼼꼼하게 챙겼어야 했는데... 혹시 이번 과제하면서 어떤 부분이 가장 문제였다고 생각하시는지 의견을 주실 수 있을까요?

개발자: 각 파트별 개발 완료상태에서, 서로 싱크가 맞는지 미리 맞췄어야 했는데 이 부분이 잘 되지 않았던 것 같아요. 개발 완료된 상태라고 안심하지 말고 Sanity D-2 정도에 개발 완료된 상태에 대해 모든 파트가 QA서버에서 테스트해보고 챙겼어야 했는데 그러지 못한 것 같습니다.

개발자의 답변을 보니, 반성도 되고 안심도 됐다.

우선 반성해야 하는 부분은 내가 개발자가 '완료'했다는 말을 너무 쉽게 믿고, 그들을 무한 신뢰했다는 것이다. 이게 이 과제가 막판에 힘들어진 이유라는 생각이 들었다. 완료가 됐으면 각 파트별 완료된 부분에 대해 최종 체크했어야 했는데 이 부분을 내가 미리 챙길 생각을 못 했다. 사실 배포 가능 여부는 QA에서 꼼꼼하게 체크해주실 거고, 개발은 개발자분들이 알아서 잘해주실 거라고 생각해서 안일하게 생각했던 것 같다.

안심된 부분은 이게 모두 PO의 잘못이 아니라는 것이다. 모두가 같이 챙겼어야 했고 우려되는 부분을 각 파트별 개발자들이 디펜던시 있는 부분들에 대해 한번 더 체크했어야 하는 게 맞았다. 그렇기에 100% 내가 잘 못한 부분은 아니라는 생각에 안심됐다.

프로젝트는 PO 혼자 하는 게 아니고, Makers들과 함께 하는 것이다. 따라서 프로젝트를 진행하며 문제가 발생했다면, 절대 PO만의 잘 못만 있는 것은 아니다. 우리 모두의 잘 못이다.

그렇다고 모두의 잘 못이라고 생각하며 책임을 회피할 생각은 절대 없다.

이번 과제를 계기로 앞으로 어떤 부분을 더 챙겨야 하는지에 대해 배웠으니, 다음 과제에서 이 부분을 잘 챙겨서 점점 성장해 나가면 된다고 생각한다. 모두를 만족시킬 순 없겠지만 적어도 같은 실수는 반복하지 말아야겠다고 생각했다. 또 Makers들이 같이 하면 마음 놓이고, 편한 PO가 되고 싶다는 생각도!