우리 팀이 일하는 방법
우아한형제들, 상품시스템팀이 일하는 방법
올해 사업실 상품기획팀에서 플랫폼실 광고시스템팀과 합치고 난 다음에 가장 많이 들은 이야기가 "그래서 새 팀은 무슨 일을 하나요?"였다. 팀이 합쳐져서 업무를 하고 있기는 하지만, 팀이 어떤 방향성을 가지고 있는지 어떤 일을 하는 팀인지 정의가 필요하다는 이야기가 스프린트 회고 때 나와서 연말 회고용으로 자료를 만들어 보았다.
팀의 목표가 무엇인지와 팀의 방향성의 정의를 궁금해했지만, 사실 그것보다 중요한 게 있었다. 어떤 아이템을 하는지는 계속 바뀔 수 있다. 우리 팀이 내년 4월 이후에 어떤 업무에 집중해야 할지 지금 알려줄 수는 있지만, 그게 바뀌지 않는다는 보장은 할 수 없다. 그전에 필요한 것은 팀이 단단하게 함께 Product를 만들 수 있어야 했다.
연말 회고 샷 연말 회고 때 아래 내용으로 이야기를 했고, 팀 위키에 적은 것을 공개적으로 다짐하기 위해 여기에도 옮겨본다.
우리는 배달의민족 플랫폼에서 업주가 매출을 올리기 위해 선택할 수 있는 다양한 장치들을 만드는 팀입니다. 개발자, 기획자가 함께 하는 cross-functional 팀이며, 정책을 정의하고, 시스템으로 만들며, 만든 정책들이 의도대로 업주에게 도움을 주고 있는지 확인하고 또 다시 변화를 만드는 역할을 합니다. 아래는 우아한형제들 상품시스템팀에서 좋은 Product을 만들기 위한 3가지 방법입니다.
Feature팀이 아닌 Product팀이 되자
여러 부서가 같이 일하는 과정에서 스펙을 정의하고 정해진 스펙대로 일정 내에 구현하는 것은 물론 중요합니다. 그러나, 사실 가장 중요한 것은 해당 스펙을 시스템에 다 구현하고 난 다음에, 그 시스템이 만들어낼 변화입니다. 우리가 만들어 내는 결과와 변화에 집중하고, 그 생각을 바탕으로 스스로 의사 결정하는 팀이 되어야 합니다. (feat. Marty Cagan의 Product Team vs Feature Team)
- 구현하다 보니 생각한 대로 동작하지 않을 것 같거나, 제대로 만들어내지 못할 것 같으면 누구든지 브레이크를 걸어주세요. 기능을 정의하는 담당자가 정해져 있지 않습니다. 스펙대로, 일정대로 만드는 것보다 진짜 변화에 집중하는 것이 더 중요합니다.
- 스스로 의사 결정하기 위해서는 만들어낸 결과의 효과를 모니터링하고 개선해야 할 부분을 누구보다 먼저 생각해야 할 책임감을 가지고 있어야 합니다. API를 만들고 난 다음, 시스템 개선을 한 다음, 꽤나 시간이 지나서 실제 라이브가 된다고 해도 만들어낸 결과가 가져오는 변화를 놓치지 말고 분석합니다.
우리 스스로 더 치열하게 논의해서 똑똑해지자
현재 팀에서 하고 있는 2주 스프린트를 플래닝 하고, 끝날 때 회고를 하고, 페어 프로그래밍을 하는 과정들은 모두 조금 더 일을 현명하게 하기 위한 방법이라 생각합니다. 이때 먼저 필요한 것은 우리 스스로 솔직하고, 치열하게 의견을 나누는 것입니다. 성장하기 위해서 가장 좋은 스승은 나를 가장 오래 보고 있는 같이 일하는 우리입니다.
- 내가 너무 솔직하게 이야기해서 피드백을 받는 사람이 내가 비난한다고 느끼지 않을까?라고 걱정하지 마세요. 다른 사람을 비난하기 위해서 피드백을 하는 사람은 팀에 없습니다. 조금이라도 인신공격을 위한 피드백을 하는 사람이 있다면, 저한테 이야기하거나 테이블에 꺼내 놓고 이야기를 해봅시다.
- 우리끼리의 기준을 조금 더 높여 봅시다. 이 정도면 되지?라는 마음과 결정들이 1년 동안 쌓이면 아쉬운 1년을 보내게 됩니다. 본인이 생각했을 때 더 잘할 수 있는 방법이 있으면 누구든지, 어느 타이밍이든지 이야기해주세요. 그게 우리의 경쟁력입니다.
기획과 개발의 갭을 줄이자
우리는 Cross-functional팀으로써 일하는 방법에 더 익숙해져야 합니다. 기획자끼리만 생각하는 시간과 개발자끼리만 개발하는 시간이라는 건 점점 줄어들 예정이며, 과거처럼 기획 한 달 동안 진행하고, 개발을 시작하는 프로젝트는 이제 없어질 것입니다. 같은 프로젝트를 하는 사람들이 같이 정하고, 같이 만들어 갈 것입니다.
- 우리가 팀으로 일할 때 기획 기간 내에 요구사항을 완벽하게 정하고, 이후 개발 기간 동안 구현하는 형태로 진행하지 않습니다. 모든 것을 확실히 정해놓지 않아 어려운 부분이 분명 있을 수 있지만, 모호함을 가진 채로 결과물을 더 좋게 만들기 위해 노력하면 더 성장할 수 있습니다.
- 비지니스에 대한 이해, 정책에 대한 이해, 개발 용어에 대한 이해, 시스템에 대한 이해 등 서로를 이해하기 위해서 필요한 것들이 많이 있습니다. 팀 사람들의 이해도를 높이기 위해서 설명하는 시간을 아끼지 마세요. 회의 때 이야기한 것처럼 redis를 써보자 라는 의견이 나왔다면, 그걸 왜 적용하는지 팀의 기획자도 개념적으로는 알아야 합니다.
