Place2Page를 진행하면서 배운 것은 개발 속도가 개인 작업 속도만으로 결정되지 않는다는 점이었다. 처음에는 내가 빠르게 정리하고 먼저 만들어두는 방식이 팀에 도움이 된다고 생각했다. 하지만 피드백을 모아보니 병목은 구현량이 아니라 일이 보이는 방식, 디자인과 제품 판단을 맞추는 타이밍, 팀원이 기다리지 않아도 되는 커뮤니케이션에 있었다.
요약
- 문제: 내가 빨리 처리하는 방식이 항상 팀 전체 속도로 이어지지는 않았다.
- 판단: 티켓 수나 구현 속도보다, 일이 시작되는 시점과 판단 기준이 팀에 보이는지가 더 중요했다.
- 피드백: 디자인 플로우, PO sync, 회의 준비, 답장 속도, 지원사업 준비 방식에서 개선 지점이 보였다.
- 배운 점: 좋은 팀장은 혼자 많은 일을 들고 가는 사람이 아니라, 팀원이 덜 막히게 경계를 정리하는 사람에 가깝다.
상황
Place2Page를 진행하면서 개발 자체보다 팀으로 일하는 방식에 대해 생각할 일이 많아졌다. 작은 팀에서는 누군가가 먼저 움직여야 일이 굴러가는 경우가 많고, 나도 그런 방식으로 많은 일을 처리했다.
하지만 혼자 빠르게 움직이는 것과 팀이 같이 잘 움직이는 것은 달랐다. 내가 먼저 처리한 일이 팀원에게 보이지 않으면, 그 일은 속도가 아니라 불확실성이 될 수 있다. 책임감으로 먼저 들고 간 일이 나중에는 방향을 다시 맞춰야 하는 비용으로 돌아오기도 했다.
이 글은 약 한 달 동안 받은 피드백을 기준으로, 내가 일하는 방식을 중간 점검한 기록이다.
시각 산출물은 개발 전에 흐름을 맞춘다
초기에는 내가 앞단을 먼저 만들고 나온 결과물을 나중에 디자인 피드백 받는 흐름이 있었다.
초기에는 21st.dev나 lottiefiles.com에서 빠르게 asset을 찾고 커스터마이즈해서 보여주는 방식이 효율적으로 느껴졌다. 하지만 랜딩페이지처럼 고객이 직접 보는 산출물은 기능만 동작한다고 끝나지 않았다. 플로우, 미감, 카피, 데모에서 보이는 느낌까지 같이 맞아야 했다.
시각적으로 보이는 것은 개발 후에 검수받는 방식보다 개발 전에 디자인 플로우를 먼저 맞추는 편이 낫다. 개발 이후에는 QA를 받는 흐름으로 가져가는 것이 훨씬 더 자연스럽다.
빠르게 만드는 것도 중요하지만, 나중에 방향을 다시 맞추는 비용도 무시하기 어렵다. 다음 스프린트부터는 완성된 기획과 디자인 위에서 작업하고, 개발 이후에는 QA로 확인하는 흐름을 기본으로 가져가려고 한다.
PO에게 일이 보이게 만들기
PO에게 내가 하는 일의 가시성이 좋지 않다는 피드백도 받았다.
나는 할 일이 보이면 일단 먼저 처리하고 어느 정도 정리된 뒤에 공유하는 편이었다. 이 방식은 빠르게 움직인다는 점에서는 장점이 있다. 하지만 팀 입장에서는 내가 지금 무엇을 하고 있는지, 어떤 판단으로 일을 시작했는지 잘 보이지 않을 수 있다.
특히 제품 방향이나 우선순위가 걸린 일은 더 그렇다. 내가 이미 어느 정도 진행한 뒤에 공유하면, PO는 중간 판단 과정을 같이 보기 어렵다. 그러면 우선순위나 방향을 맞추는 타이밍이 늦어진다.
그래서 앞으로는 선조치 후보고처럼 움직이기보다 일을 시작하기 전에 짧게라도 공유한다.
이 부분 먼저 확인해볼게요.
이 티켓은 오늘 P0 기준으로 정리해볼게요.
이건 개발 전에 PO랑 방향만 한번 맞추고 들어갈게요.시각적으로 보이는 것은 디자인 플로우를 먼저 맞추고, 그 외 제품 방향이나 우선순위가 걸린 일은 PO와 sync를 맞추는 식으로 가져가려고 한다.
작은 팀에서는 보고를 길게 하는 것보다 일이 시작되는 순간을 서로 알 수 있게 만드는 것이 더 중요할 때가 있다. 내가 무엇을 하고 있는지 보이면 팀원도 기다릴지, 도와줄지, 방향을 바꿀지 더 빨리 판단할 수 있다.
Discord 피드백을 혼자 꼬아듣지 않기
텍스트로 피드백을 받으면 가끔 말의 의도보다 뉘앙스를 더 크게 받아들일 때가 있다. 특히 바쁘거나 이미 몰입해 있는 상태에서는 짧은 문장도 필요 이상으로 방어적으로 읽힐 때가 있다.
하지만 Discord 텍스트는 원래 맥락이 많이 잘린다. 상대가 나를 평가하려는 것이 아니라, 그냥 지금 필요한 정렬을 요청하는 경우가 많다.
그래서 애매하면 혼자 해석하지 말고 바로 확인한다. "이 말이 무슨 뜻이지?"에서 오래 머무르기보다, "그럼 지금 내가 확인해야 할 기준이 뭐지?"로 빨리 넘어가는 연습을 하고 있다.
회의 준비 요청은 안건까지 같이 공유하기
U300 관련해서 회의 전에 논의할 것이 있는지 물어본 적이 있었다. 내 머릿속에는 U300 진행 방식, 인터뷰 결과, 300개 아웃리치에 필요한 소프트웨어 지원 같은 안건이 있었다.
그런데 그걸 먼저 말하지 않으면 상대 입장에서는 기존 준비와 무엇이 달라지는지 알기 어렵다. 나는 가볍게 물어본다고 생각했지만, 받는 사람 입장에서는 "그래서 뭘 준비해야 하지?"가 될 수 있었다.
앞으로는 회의 전에 아래처럼 나눠 공유한다.
- 논의할 안건
- 확인하고 싶은 질문
- 결정이 필요한 항목
- 내가 지원할 수 있는 부분
회의 준비도 결국 작은 제품 문서처럼 써야 하는 것 같다. 상대가 내 머릿속 맥락을 추측하지 않아도 되게 만드는 게 중요하다.
몰입하더라도 연락을 놓치지 않기
나는 어떤 일에 몰입하면 덜 중요하다고 느끼는 것들을 거의 다 차단하는 버릇이 있다. 개발할 때는 이게 도움이 될 때도 있다. 하지만 팀으로 일할 때는 항상 좋은 습관은 아니었다.
내가 답장을 늦게 하면 상대는 그 시간 동안 기다리거나, 다시 물어보거나, 혼자 판단해야 한다. 반대로 짧게라도 빨리 답하면 상대의 시간을 아낄 수 있다.
요즘은 연락을 잘 보고 가능한 빨리 답하는 것도 기본적인 협업 에티켓이라는 것을 느끼고 있다. 큰 일을 해주는 것만 신뢰를 만드는 것이 아니라, 작게 막히는 시간을 줄여주는 것도 신뢰와 협업 속도에 영향을 준다.
아직 잘 고쳐진 것은 아니지만, 의식적으로 보려고 한다.
지원사업 준비를 혼자 끌고 가지 않기
U300이나 모두의 창업 지원서처럼 발표, 장표, 카피, 사업계획, 팀 전략이 같이 걸린 일은 혼자 다 끌고 가면 빠르게 한계가 온다.
처음에는 내가 글을 엄청 잘 쓰거나 사업계획서를 잘 쓰는 사람이 아니면 크게 기여하기 어렵다고 생각한 적도 있다. 그런데 같이 브레인스토밍에 적극적으로 참여하는 것만으로도 좋은 아이디어가 훨씬 많이 나왔다.
그리고 그 과정 자체가 상대에게 안정감을 주는 것 같다. 혼자 빈 문서를 보고 있을 때보다, 옆에서 같이 생각해주는 사람이 있으면 막막함이 줄어든다.
팀장이라면 모든 것을 혼자 잘하는 사람보다 팀원이 자기 역할을 할 수 있게 같이 생각하고 일을 나눌 수 있는 사람이어야 한다고 느꼈다. 나도 그런 방향으로 더 믿고 의지할 수 있는 팀장이 되고 싶다.
다음에는 이렇게 판단한다
앞으로는 "내가 빨리 끝낼 수 있는가"보다 "팀이 이 일을 기다리거나 추측하지 않아도 되는가"를 먼저 본다. 개인 속도가 팀의 불확실성을 키우는 순간에는 공유가 먼저다.
실행 기준은 이렇게 가져간다.
- 티켓은 많이 만들기보다 목표 기준으로 줄인다.
- 시각 산출물은 개발 전에 디자인 플로우를 먼저 맞춘다.
- 제품 방향이나 우선순위가 걸린 일은 PO와 먼저 sync를 맞춘다.
- 선조치 후보고보다, 일을 시작하기 전에 "나 이거 할게" 한마디라도 공유한다.
- Discord 피드백은 혼자 해석하지 말고 필요한 의도를 확인한다.
- 회의 준비 요청은 안건과 질문을 분리해서 전달한다.
- 몰입 중이어도 팀원의 시간을 아끼는 답장은 놓치지 않으려고 한다.
- U300, 지원서, 발표, 마케팅 실행처럼 복합적인 일은 팀원에게 더 적극적으로 맡긴다.
돌아보면
이번 중간점검에서 많이 느낀 것은 개발자의 속도가 개인 작업 속도만은 아니라는 점이다.
혼자 빠르게 만드는 것도 필요하다. 하지만 팀이 같은 기준으로 움직이지 않으면 다시 정리하고, 다시 설명하고, 다시 고치게 된다. 초기 제품에서는 코드만큼이나 티켓, 디자인 플로우, PO sync, 회의 안건, 답장 속도, R&R이 제품 속도에 영향을 준다.
요즘은 "내가 빨리 처리할 수 있는가"보다 "팀이 덜 막히고 같이 움직이고 있는가"를 더 자주 보려고 한다.
