[Ep 6] 2024년 상반기 회고 : 많이 왔지만, 가야 할 길이 먼 그대에게

 

어느덧 히츠에 합류하고, 하이퍼랩을 담당한 지 벌써 1년이다.

그리고 6월의 절반을 지나가면서 2024년도 절반을 향해 가고 있다.

 

아직 절반보다는 조금 이르지만, 체감은 2024년의 절반 이상을 살아가고 있다는 느낌을 받는 2024년의 상반기 회고를 적어보려고 한다.

Liked & Keep

Sync를 주기적으로 맞추기 위한 Review 형태의 프로세스의 완성

현재 하이퍼랩의 개발 프로세스는 아래의 Review 과정을 수행하면서 정확한 기능 개발을 하기 위해 모두가 힘을 쏟고 있다.

 

 

하이퍼랩 Review 프로세스

1. Backlog 및 PRD Review : 고객 역할을 수행하는 신약개발본부와 기획팀 간의 Review
2. 기획 및 디자인 1차 Review : PRD를 기반으로 작성된 기획서와 디자인에 대한 신약개발본부와 기획팀 간의 Review
3. 기획 및 디자인 2차 Reivew : 1차 Review 된 기획서 및 디자인에 대한 기획팀과 개발팀 간의 Review
4. 개발 Review : 기획서 및 디자인 기반의 개발된 사항에 대한 신약개발본부 및 기획팀의 Review

 

‘도메인 지식이 필요함’이라는 허들로 인해, 서로 간의 커뮤니케이션과 명확한 요구사항을 주기적으로 체크하는 것이 우리가 진행하고 있는 프로세스에서 가장 중요한 부분이다. 고객에게 제공되기 전에 최대한 많은 형태의 Review 과정을 거치면서 가장 완성도 높은 형태로 고객에게 제공되도록 노력하고 있다.

 

Sprint 계획서 기반의 소통

Sprint 계획서를 통해서 팀 전체가 진행되는 상황에 대한 Sync를 일치시킬 수 있게 되었다.

 

명확한 Backlog로 인해 Sprint 진행에 대한 논의를 할 때 Sprint 계획서를 기반으로 우선순위를 선정 후 소통을 하고 있다. 어떻게 보면 Waterfall 형태로 인해 Agile 하지 못하고, Top Down 형태로 부정적으로 보일 수 있으나, 명확한 고객의 니즈가 있다면 가장 효과를 볼 수 있는 형태라고 생각하고 있다.

 

Sprint 계획서는 확정되면 고칠 수 없는 문서가 아니다. 누구나 작업을 하다보면 알 수 없는 변수가 생기고, Backlog를 작업하는 것보다 더 중요하게 처리해야 할 작업이 발생할 수가 있다. 그럴 때는 누구든지 그 상황을 알려주면 다 같이 논의 하에 Sprint 계획서를 수정한다.

이를 통해 Sprint 기간 진행되는 모든 상황에 대한 기록을 계획서에 남기고, 모두가 한 곳에서 다른 사람들의 진행상황을 확인할 수 있다.

 

나아지고 있는 QA 프로세스

지금과는 차원이 다른 QA 시자아아악 합니다~ (출처 ; 클래시 로얄)

드디어, 하이퍼랩에도 전문 QA를 담당하시는 분이 감사하게도 와주셨다. 그동안 주먹구구식으로 작성한 Full TC와 Sanity Check, QA 프로세스를 이제부터 개편하려고 하고 있다.

Full TC도 개편되고, QA와 효과적으로 협업할 수 있는 방법에 대한 Workflow도 구축하려고 한다. 이에 대한 QA 프로세스 개선 후기는 추후 새로운 콘텐츠로 소개하고자 한다.

 

Lacked

그래도 아직은 미흡한 Review 프로세스

출처 : KBS

최대한 Review를 많이 하는 과정을 거치고 있지만, 그래도 어느 한 부분에서 Review에 대한 Sync가 맞지 않으면, 의도하지 않은 방향으로 흘러가는 일이 종종 발생한다. 사소한 기능에는 큰 문제가 없을 수도 있지만, 새로운 기능을 크게 만들어야 하는 것이라면, 그것이 누군가의 노력을 헛되이 할 수 있는 부분이 된다.

 

그런 부분에 있어서 기획인 나부터 최대한 꼼꼼하게 챙겨야할 것 같다.

 

Sprint 계획서가 정답은 아닌 것 같다

그래도 아직 '땡'까지는 아닐지도...(출처 : 출장 십오야)

좋았던 부분에 작성했던 것이 Sprint 계획서 기반의 소통이지만, Sprint 계획서가 정말 완벽에 가까운 관리 방식이라는 것에는 아직 확신이 없다. Waterfall을 어떻게 받아들이냐의 차이일 수도 있다고 생각한다. 명확한 Backlog로 인해 개발의 우선순위가 정해진다는 말은 결국, 누군가에게는 이미 정해진대로 의견 없이 개발과 디자인 작업을 순차적으로 진행한다는 말이 될 수 있다.

 

Waterfall은 좋지만 Top Down은 지양하고자 하는 이 고민이 매번 Sprint를 시작하고, 매주 개발팀, 기획팀과 Sprint 계획서를 기반으로 논의할 때 계속해서 발생한다.

 

모두가 납득할 수 있는 Sprint의 방향성을 어떻게 개선하여, 긍정적인 Sprint 계획을 완성할 수 있을지 PM으로써 매일 퇴근하면서 고민을 하는 중이다.

 

또다시 발생하는 급건 처리 이슈

출처 : JTBC

Sprint를 진행하다 보면, 예상치 못한 이슈들이 추가적으로 발생해서 진행 중인 업무들에 대한 중단이 발생하고 그에 대한 컨트롤이 원활하게 되지 못한 순간들이 이번 상반기 때는 유독 많았던 것 같다. 이건 매번 꼼꼼하게 챙기지 못한 나의 불찰과 더불어 여러 가지 이해관계에 얽혀서 명확하게 정리하지 못한 우유부단함이 환장의 콜라보를 이루었던 것 같다. 매번 반성하고 다짐하면서도 늘 발생하는 이 사고에 대해서 항상 주의하고 경계해야 한다. 

 

Try

버그 상황 재현을 위한 Tool 사용

QA를 하다보면 꼭 순간적으로 발생한 버그를 재현하기 어려워서 디버깅을 하지 못하는 경우가 발생한다. 이런 상황을 대비하여 QA를 위한 실시간 화면 녹화 및 로그 기록까지 녹화해 주는 기능들이 꽤 있다. 이러한 Tool들을 활용해서 Edge Case들까지 완벽에 가까운 커버리즈를 잡을 수 있도록 QA 엔지니어 분과 시도해 볼 예정이다.

 

Sprint 계획을 모두가 모인 자리에서 만들어보는 건 어떨까?

다른 기업들의 Sprint 관리 방식을 보다보면, Sprint를 시작하는 Kick off 미팅을 하루 종일 하는 회사들도 본 적이 있다. 정말 Backlog들의 리스트를 기반으로 Jira의 스토리포인트를 활용하고, 이를 기반으로 그 자리에서 Sprint 기간 동안 해야 할 일들을 정하는 것이다.

 

대부분 Agile 조직에서 이러한 방향을 해보지만, Waterfall 형태라고 해서 마냥 불가능한 이야기는 아니지 않을까라는 생각도 해본다. 이번 Sprint를 기획하지만, 다음 번에는 어떤 작업을 이어서 해야 할지 메이커들 스스로 개인적인 작업 계획을 세워보는 데에도 도움이 될 수 있을 것 같다.

 

이에 대한 Sprint 계획 개선기도 추후 콘텐츠로 제공할 수 있도록 노력해보겠다.

---

2024년 절반을 보내며

많이 왔지만, 가야 할 길이 먼 그대에게

많이 변화를 줬다고 했는데, 아직도 많이 부족하다.

 

그래도 2023년보다는 더 빠르게 성장하고 있는 모습이 하이퍼랩의 서비스 변화과정만 봐도 눈에 보인다. 그만큼 모두가 열심히 쉬지 않고 달려와서 그런 것임을 알기에, 감사하면서도 미안함 마음도 갖게 되는 것 같다. 매번 배포까지의 험난한 과정을 늘 디버깅해주시고, 예상치 못한 일정에도 묵묵히 해주시는 분들이 있어서 복을 많이 받았다 싶으면서 더 잘 챙겨야겠다는 생각도 든다.

 

2024년의 마무리 회고를 할 때 즈음에는 하이퍼랩을 모두가 만족스럽게 제품을 기획하고, 개발하고 일할 수 있는 최적의 프로세스가 구축되었으면 좋겠다. 그러기 위해서는 나부터 더 많이 공부하고, 반성하고 꾸준히 노력해야 할 것 같다.