[월간 다노 프론트 – 1호] 다노의 프로덕트 유닛을 소개합니다.
새로운 프로덕트 유닛 시스템을 소개합니다.
다노 프론트엔드 인턴기를 마치고, 앞으로 정규 크루(정규직)로서 어떤 글을 쓰면 좋을지 고민을 했습니다. 기술블로그로만 꾸려나가는 것도 좋겠지만, 그보다 조금 더 말랑말랑한 이야기를 블로그에 더하고 싶었습니다. 개발자도 결국 사람이고, 사람이 하는 일에는 기술이나 숫자만으로는 설명하기 어려운 부분도 분명 있다고 생각했거든요.
현재(2019년 9월) 다노에는 프론트엔드 개발자가 2명이 있습니다. 한 명이 저(이하 👩🏻💻)이고, 다른 한 명은 저보다 1년 먼저 입사하신 H님👨🏻💻입니다. H님에게 월간 다노 프론트에 대해서 얘기했는데, 긍정적인 반응이었습니다(부정적일 줄 알았어요 사실😁). 기세를 몰아 첫 주제로 무엇이 좋을지 의견을 물었더니 다노의 유닛변경된 이야기가 나왔고, 괜찮은 아이디어인 듯하여 첫 주제는 프론트엔드 개발자로서 바라본 다노의 프로덕트 유닛에 대해 이야기해보려 합니다 👏
(서버개발자나 PM이나 디자이너의 입장은 다를 수도 있겠죠..? 아마도..?)
기존의 유닛 시스템
팀은 다르지만, 같은 목표를 바라보고 있는 유닛
다노에는 크게 2개의 서비스가 있습니다. 온라인PT 서비스인 마이다노와 저염/저당/저자극 식품을 판매하는 다노샵이 그것입니다. 서비스가 2개이다보니 크루(직원)들도 팀 내에서 마이다노/다노샵 서비스를 담당하는 크루가 나뉘어 있고, 개발팀도 마이다노 또는 다노샵을 담당하는 개발자가 나뉘어 있습니다. 유닛은 같은 서비스를 위해 일하는 크루들이 모여서 협업을 하기 위해 만들어진 것인데, 다노는 팀단위로 일하기 보다는 유닛 단위로 같은 목표를 바라보고 있는 사람들이 모여서 속도감 있게 진행하는 방식을 선호해왔던 것 같습니다.
그래서 프로덕트 유닛에는 여러 직무의 크루들이 모여있습니다. 다른 회사에서는 Cell 조직으로 프로젝트를 진행하는 회사들이 더러 있는 것으로 알고 있습니다. 유닛은 Cell 조직과 비슷하다고 보면 될 것 같습니다 😀
프로덕트 유닛에는 기획자(PM), 디자이너, 개발자, 데이터 분석가, 마케터, 운영팀원으로 구성되어 있습니다. 여러 직무의 사람들이 모여서 규모가 크다고 생각할 수도 있지만, 실제로 매일 진행되는 스탠드업 회의 때는 기능개발에 필요한 최소인원인 기획자(PM), 디자이너, 개발자(+- 데이터 분석가)가 참석하기 때문에 좀 더 기민하게 움직일 수 있습니다.
“오늘 개발 1도 못했어!”
기존 유닛 시스템이 속도감 있는 업무를 진행하기 위함이었다면, 새롭게 변경된 유닛은 안정적인 배포에 초점을 맞추고 있습니다. 기존에는 빠른 소통을 위해 개발자가 마케팅유닛에도 소속되고, 지금 바로 대응할 hotfix가 아님에도 채팅창에서 멘션되기도 했습니다(꼭 지금 그 이슈를 대응해야할 것 같은 약간의 압박감이 있었어요. 버그가 있는데 해결을 안할 수도 없고…).
개발자의 입장에서는 업무 스위치를 하루에도 몇 번씩 해야하는 상황이 있었습니다. 분명히 오늘 일을 하긴 했는데, “오늘 개발 1도 못했어!”라고 외치는 상황이 왕왕 발생했습니다.
새로운 유닛 시스템
PM의 커뮤니케이션 능력과 유닛 구성원들의 합이 중요해졌습니다.
회의는 PM이 참석하고, 개발자는 개발을 합니다.
새로운 유닛 시스템은 안정적인 배포에 초점을 맞추고 있습니다. 그러려면 개발자가 “오늘 개발 1도 못했어!”라고 말하지 않도록 개발을 할 수 있는 시간이 확보되어야 합니다. 시간이 확보되려면, 여러 회의나 커뮤니케이션에 할애할 시간이 줄어들어야 합니다. 하지만 커뮤니케이션은 반드시 필요하기 때문에 그 역할을 PM이 하게 됩니다.
동시에 PM은 매일 스탠드업 미팅을 하면서 다른 팀에서 요청이 들어온 것들, 진행 중/진행 예정인 사항에 대해 이야기를 나눕니다. 개발자는 어떤 것들이 진행/예정인지 스탠드업 미팅을 통해 파악할 수 있고, PM과 커뮤니케이션을 하면서 개발시간을 최대한으로 가질 수 있게 되었습니다.
무조건 개발자와 운영/마케팅 팀원이 대화를 못하는 것은 아닙니다. 언제든 Slack에서 대화할 수 있고, 만나서 이야기할 수 있습니다. 예전처럼 개발자가 필수로 참석해야하는 회의들이 사라져서 좀 더 개발효율이 높아졌다고 보면 될 것 같습니다.
모든 Jira 이슈는 PM이 할당(assign)받아 검토하고, 적합한 사람에게 재할당합니다.
위와 비슷한 맥락인데요. 예전에는 다른 팀 분들이 업무요청을 주실 때 개발자에게 직접 assign을 하는 경우가 있었습니다. 하지만 이 이슈를 누구에게 줘야하는지 모르겠는 일(R&R이 불분명한 일들)은 ‘착한 마음을 가진 개발자가 선의로 해주어야하는 일’이 되었던 것 같습니다. 빠르게 처리될 수 있는 점은 분명 있지만, 회사 구성원이 많아질 수록 이런 프로세스는 한계에 부딪히기 마련입니다.
하지만 이제는 모든 Jira 이슈는 관련된 프로덕트 유닛의 PM에게 1차적으로 할당이 됩니다. 버그, 개발팀에 대한 업무요청, 제안 등등 모든 Jira이슈를 PM이 받아 검토를 하고, 적합한 사람에게 다시 assign을 합니다. 이 과정에서는 PM 선에서 우선순위를 낮추거나 지금 시점에서는 거절되는 업무도 발생하게 됩니다.
PM이 이슈가 서버 이슈인지, 프론트 이슈인지 알고 있어야하고, 이게 진짜 버그인지, 유저의 특정 환경으로 발생한 이슈인지 구별할 수 있어야한다는 난제(!)는 있지만, 직접적으로 개발자에게 바로 할당되던 이슈들은 앞으로는 없을 것 같습니다.
마일스톤 단위로 업무를 진행합니다.
저는 마일스톤의 개념을 Sprint 단위로 일하는 것이라고 이해하고 있습니다. 비교적 일정한 주기를 갖는 마일스톤(M1, M2, M3, …)에 어떤 것을 만들어서 배포할지를 유닛에서 결정합니다.
그래서 이전보다 우선순위를 결정하는 것이 중요해졌습니다. 우선순위가 높은 것이 다음 마일스톤에 들어가게 되니까요. 우선순위는 한 사람이 결정하는 것이 아닌 유닛 안에서 논의를 통해 결정됩니다.
새로운 유닛 시스템에서 어떻게 보면 마일스톤은 가장 핵심적인 개념입니다. ‘왜 이 이슈가 우선순위가 높은지’에 대해 합당한 이유가 있어야 마일스톤에 들어올 수 있습니다. 그만큼 PM의 중간 역할이 중요해졌고, 개발자는 정확한 개발일정을 산정할 수 있는 능력이 중요해졌습니다.
새로운 유닛 시스템에서 어떻게 보면 마일스톤은 가장 핵심적인 개념입니다. ‘개발자’라는 리소스를 운영/마케팅/다른 팀원이 동시에 사용하고 있다가 모든 요청/이슈는 PM을 통해 처리하기 때문에 ‘왜 이 이슈가 우선순위가 높은지’에 대해 합당한 이유가 있어야 마일스톤에 들어올 수 있습니다. 그만큼 PM의 중간 역할이 중요해졌고, 개발자는 정확한 개발일정을 산정할 수 있는 능력이 중요해졌습니다. 이 이슈를 M2에 배포할지, M3에 배포할지 결정하려면 개발일정을 잘 산정해야지만 정할 수 있으니까요.
H님👨🏻💻이 속해있는 마이다노 프로덕트 유닛도, 제👩🏻💻가 속해있는 다노샵 프로덕트 유닛도 마일스톤의 주기가 아직 확정되진 않았습니다. 몇 번의 배포가 이뤄진 다음에야 우리에게 적합한 배포주기를 알게될 것 같습니다.
보완해야 하는 점도 있더라고요.
새로운 유닛 시스템이 시작된 지 1~2개월이 지났습니다. 올 하반기는 새로운 유닛 시스템에 적응해야하는 과도기가 아닐까 생각합니다. 여담으로 제가 집에서 스파티필름이라는 식물을 키우는데, 분갈이를 하면 며칠 정도는 애가 시름시름 아픈 것 같아보여도 얼마 지나면 언제 그랬냐는 듯이 훨씬 쑥쑥 잘 큽니다. 새로 바뀐 유닛시스템도 분갈이 후 몸살을 겪으면서 더 성장하지 않을까 싶습니다.
같은 일을 한다고 가정했을 때, 새로운 유닛 시스템으로 개편되기 전후를 비교해보면, 이론적으로는 개발할 수 있는 시간이 더 늘어나야합니다. 개발자의 회의참석이나 타 팀원과의 커뮤니케이션이 최소화되었기 때문인데요. 하지만 개인적으로는 개발 시간이 늘어났다고 체험하지는 못하고 있습니다. 왜 일까요? 🤔
회색영역에 있는 업무들이 있습니다.
개인적으로는 Urgent하다기 보다는 Rush한 요청들이 회색영역에 해당한다고 생각됩니다. 이것이 중요하다, 중요하지 않다라는 기준은 사실 주관적인 해석이 따를 수 밖에 없기 때문에 마일스톤에 들어가지 않은 업무 요청은 모두 회색영역이 되어버렸습니다. 회색영역에 있는 일을 hotfix로 볼 지 말 지, 그러면 그 일들은 어떻게 해야하는건지에 대해 고민이 있습니다.
회색영역에 대해서는 얼마 전 PM분과 이야기를 나누면서 얼추 가닥을 잡았습니다. 제가 PM분께 요청드린 것은 어느 팀이든 업무요청을 할 때에는 Jira에 티켓을 등록하실텐데, 반드시 이 때까지는 수정이 되어야한다는 사항에 대해서만 due를 기재하고 그렇지 않은 경우에는 due를 입력하는 칸은 비워서 Jira이슈를 등록해주시길 요청드렸습니다. due가 기재된 업무는 제가 무조건 due를 지켜서 업무를 완료 할 것이고, due가 없는 사항은 PM분이 적절하게 due를 조정해주는 방식으로 진행했으면 좋겠다는 제안을 드렸습니다. 이 정도 선이 모두를 비교적(!) 행복하게 만들 수 있는 절충안이라고 생각했습니다. 앞으로 더 고민이 필요한 부분입니다. 🤔
줄어든 커뮤니케이션 시간
개발자로서 다른 팀 사람들과 대화시간이 줄어든다는 것은 장점이자 단점일 것 같지만, 저는 단점이 좀 더 크다고 생각합니다.
특히 다노의 개발자들은 커뮤니케이션을 좋아합니다(저만 그렇게 생각하는거 아니겠죠?). “나는 개발만 할거야”라는 개발자는 사실 면접단계에서 걸러지는 것 같습니다. 스타트업에서 일하는 개발자분들 중에서 커뮤니케이션 싫어하는 개발자는 없을 것 같긴 하네요!
다노에서는 매주 화/목요일에 랜덤런치라고 해서 다른 팀 사람들과 함께 점심을 먹는 문화가 있습니다. 아마도 랜덤런치 시간이 아니라면, 이제는 다른 팀 분들과 대화할 일은 별로 없을 것 같네요 😢
월간 다노 프론트의 멤버가 되실 분을 모집합니다. (👉 신청하기)
다음 호에서 만나요! 👩🏻💻⚛️👨🏻💻
