<<리빌딩에도 PO가 필요할까>> 많은 서비스들이 그렇듯, 레거시는 쌓이기 마련이고, 어느 시점이 되면 개발팀은 생산성을 높이기 위해 리빌딩(혹은 리팩토링) 작업을 하게 됩니다. 저희 서비스 역시 예외는 아닙니다. 동시에 분산되어있던 관리자 페이지를 통합하면서, 관리자 페이지를 사용하는 운영팀의 생산성을 올리기 위해 요구사항을 받아 개선작업도 같이 병행하고 있습니다.(고치는 김에 개선하자!) 그러던 중 백엔드 리빌딩 팀 회고록에서 기획이 명확하지 않아 반복작업이 발생하여 효율이 떨어진다는 문제점이 자주 언급되는 것을 발견하였습니다. 운영팀의 요구사항이 적힌 기획서를 살펴보니, 와이어프레임에 기능 중심으로 요구사항만 적혀있었습니다. 이러한 상황에서 PO가 리빌딩 팀에 합류하는게 맞을까? 고민했습니다. 분명 PO는 팀원들의 업무효율을 높이기 위해 도움을 주는 게 일인데, 어떻게 도움을 줘야할지 고민이 되었습니다. 리빌딩 팀에 합류하기엔 PO팀 리소스가 너무 부족한 상황이었습니다. 그래서 아래와 같이 오지랖 가득한 제안을 드려봤는데, 저희와 같은 상황에 놓인 분들도 꽤 공감하실 것 같아 공유합니다. [비효율적인 것은 당연합니다] 전략문서나 상위기획 문서 없이 와이어프레임에 요구사항 위주로 정리되어 있는 경우 맥락과 문제를 정확히 알 수 없습니다. 따라서 추가적인 의사결정이 필요한 경우에 개발자는 질문을 하거나, 지레짐작하여 개발을 하게 되다가 다시 되돌리는 경우가 생겨 개발 효율이 떨어지게 됩니다. [제안하고 싶은 내용과 주의해야할 사항] 운영팀과 미팅을 할 때 요구사항이 나오게 된 배경과 현 기능에서의 문제점을 최대한 자세히 물어보시고 문서화 해주시는게 좋습니다. 다만 이때 주의해야할 사항은 요구사항을 작성한 사람에게 너무 공격적으로 Why를 묻게 되면, 당사자가 주눅들 수 있습니다. 그래서 Why보다는 이때의 구체적인 상황과 맥락을 물어보면서 맥락과 문제를 세트로 뽑아낸 다음 구체적인 구현방안은 개발자가 판단하는 것이 좋을 것 같습니다. [예상되는 기대효과] 그렇게 되면 추가적인 의사결정이 필요할 때 개발자가 스스로 생각해서 판단하고 “이렇게 진행하려고 합니다.문제 없을까요?”라고 커뮤니케이션이 이뤄지게 되어 훨씬 효율적일 것이라 기대됩니다.