작은 스쿼드에서 빠르게 임팩트 내기
스쿼드가 작을 수록 협업의 밀도는 높아지니까.
나는 기업 교육 전용 플랫폼을 만드는 PM이다. 우리 스쿼드는 나를 포함하여 4명으로 구성되어 있다. PM 1명, 디자이너 1명, 프론트엔드 개발자 1명, 백엔드 개발자 1명.
이 작은 스쿼드의 미션은 무에서 유를 창조하는 것이다. 아무 것도 없는 허허벌판에 건물을 세우려니 - 큰 단위의 배포가 많다. 작년 11월, 기업 교육 플랫폼을 리뉴얼하는 TASK를 맡게 되면서 우리는 처음부터 끝까지 다 새로 만들었다. 백오피스부터, 수강 화면, 관리 페이지까지. 그리고 거기에 굵직한 기능들을 붙여 나가는 중이다.
B2B 프로덕트는 특히나 고객의 요청 사항이 많은 편이다. 사소하게는 어떤 문구가 보이지 않게 해달라는 요청부터, 크게는 딜 수주를 위해 새로운 기능을 만들어 달라는 요청까지 다양하다. 그 덕분에 우리의 백로그는 해야 할 일로 빽빽히 쌓여 있다. 한 기능을 개발하는 데 두 명이서 3개월 씩 걸리는 일들이 로드맵에 잔뜩 적재되어 있다.
그러다 보니 리소스의 한계를 절감하고 있다. 리소스가 부족한 상황 속에서도, 작은 스쿼드가 빠르게 임팩트를 내기 위해서 우리는 효율적으로 협업해야 한다. 그래서, 빠르게 소통하고, 밀도 있게 일하고 있다. 이번 글에서는 작은 스쿼드에서 우리가 밀도 있게 일하는 방식에 대해 소개해보려고 한다.
1. 내가 하는 고민을 들고 가기
함께 일하는 메이커들과 지금 우리 프로덕트가 겪고 있는 ‘문제’와, 이를 해결하기 위한 ‘방향’에 대한 얼라인이 잘 맞는다면 그 다음 일의 얼라인을 맞추기 쉬워진다. 그래서 나는 기획서에 이 일이 왜 되어야 하는 지에 대한 충분한 설명과, 이를 해결하고자 하는 ‘방향’에 대해 작성한다. 그들이 문제를 인식하고 있어야 더 좋은 솔루션이 나올 수 있다고 생각하기 때문이다.
완벽한 기획서를 만들기 위해 혼자 오랫동안 고민하면 내 머릿속 솔루션을 가져가기 쉽다. 그래서 나는 명확한 솔루션이 나오기 전 내가 고민하고 있는 사항들을 메이커들에게 미리 공유한다. 이런 고민을 하고 있는데, 이 방향은 어떻게 생각하는지? 이 방향이 개발하기 더 쉬운지? 이런 경우는 어떻게 구현하는 게 좋을지?
디자이너와 협업할 때는 기획서에 고민 되는 부분을 적은 후 이에 대해 논의하고, 개발자와 협업할 때는 기획하다가 고민되는 부분을 바로 물어본다. 정답을 들고 가야 한다는 부담감을 버리면 더 좋은 솔루션이 나온다. 그러니 풀리지 않은 부분이 있을 때는 더 적극적으로 물어보자.
2. 기획 초기 단계부터 involve하기
디자이너와 개발자들이 로드맵을 이해하고 있다면 조금 더 의견을 적극적으로 주게 되고, 그럼 기획 앞 단부터 참여할 수 있게 되기 때문에 굉장히 효과적이다. 그래서 로드맵 짜는 단계에서부터 아예 메이커들과 함께 일한다.
최근, 실제로 프로덕트 로드맵을 세울 일이 있었다. 해야 할 일이 너무 많고 고객의 요구사항이 쌓여 있는 시점이었는데, 앞으로 어떤 굵직한 기능들을 만들어서 우리 프로덕트는 어떤 방향으로 가야할지를 정해야 했다.
이 때, 생각하고 있는 로드맵 우선순위를 개발자들에게 공유하고, 각 작업이 얼마나 난이도가 있고 리소스가 많이 드는 지를 함께 논의했다. 프로덕트 로드맵 상 필요한 기능이긴 하나 상대적으로 리소스가 많이 드는 작업은 후순위로 두거나, 다른 리소스를 써서 구현할 수 없을지 알아보았다.
또한 디자이너에게는 충분히 권한을 주어 초기 단계부터 involve 시킨다. 예를 들어, 기획서를 쓰다 보면 UI를 가져가기 쉽다. 물론 레퍼런스를 아예 가져가지 않는 것은 아니다. 그러나 UI를 직접 요청하기보다는, 문제를 던지고 어떤 방식으로 구현되는 것이 좋은 지를 충분히 얼라인하려고 한다. 이 기능이 해결하려는 문제가 뭔지를 충분히 공유하면 더 나은 방향을 제시하는 경우도 있기 때문이다.
- 이 페이지에 A 기능을 이런 방식으로 디자인해주세요. (X)
- 지금 이런 문제가 있는데, 이런 기능을 넣어보면 어떨까요? 저는 B 페이지에 넣는 게 좋을 것 같은데, 더 나은 방향이 있다면 제안 주세요. (O)
이렇게 기획 단계에서 권한을 주면 디자이너가 충분히 involve된다. UI를 직접 요청하는 게 아닌, 문제를 던지고 함께 설계해야 한다. 되어야 하는 이유와 방향성에 대한 충분한 얼라인이 된 후, 기능이 해결하려는 문제는 무엇인지 함께 고민하고 나눈다면 더 좋은 협업을 할 수 있게 된다.
3. 심리적인 안정감 제공하기
개발을 하다 보면 정책이 비어 있는 경우가 종종 발생한다. 이 때, 촘촘한 테스트 케이스와 정책서가 있으면 좋다. 그러나 개발자들이 모든 문서를 꼼꼼하게 읽을 것이라 기대하면 안된다. 그래서 고민이 있으면 바로 물어볼 수 있는 환경을 조성하는 것이 중요하다. 개발자들이 고민이 있을 때 알아서 처리하는 것이 아니라, 바로 질문할 수 있도록 하는 것이다.
디자인을 할 때도 마찬가지이다. 완벽한 글을 한 번에 작성하기 어렵듯, 기획안에도 빈 부분이 있을 수 있다. 이 때 정책을 어떤 의도인지, 어떤 방향이 더 나을지를 물어볼 수 있는 환경을 조성하는 게 좋다.
가장 중요한 것은 심리적인 안정감이다. PM과의 심리적 거리가 가까워야, 사소한 질문도 쉽게 할 수 있다. 그래서 업무 외적으로 개인적인 관심사에 대해 공유하기도 하고, 일부러 농담을 던지기도 하며 심리적인 거리를 가깝게 하려고 노력한다. 꼭 서면으로 공유하는 게 아니라, 말로 공유할 수 있기도 해야 한다. 물론 이런 논의 내용은 휘발될 수 있으니 슬랙에 바로 업데이트한다. 그래야 히스토리나 논의 내용을 바로 서칭할 수 있다.
모름을 인정하고, 기획 초기 단계부터 메이커들과 함께 일하고, 심리적인 안정감을 제공하면서 우리 스쿼드는 빠르고 재밌게 협업하며 일하고 있다. 재밌게 일할 수 있기 때문에 프로덕트에 대한 애정도 올라가고, 서로 더 긴밀하게 협업할 수 있게 되었다. 내가 혼자 만든 기획이 아니라 팀이 함께 만든 결정이라는 감각이 쌓일수록 작은 스쿼드는 생각보다 훨씬 멀리, 빠르게 나아갈 수 있다.
