brunch

라이킷 13 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 수수 Jul 02. 2022

IT 스타트업 마케터가 개발자와 소통하며 배운 것

개발 요청할 땐 WHY뿐만 아니라 IMPACT도 함께 공유하자.

IT 스타트업 환경에서 오래 일을 한 것은 아니지만 마케터로 개발자와 커뮤니케이션하며 배운 것들을 적어보려한다. 이 글이 누군가에게 소소한 도움이 되었으면 좋겠다.

기록해 둔 회고 중 일부 캡쳐

이전에 주로 하던 콘텐츠 마케팅 업무에서 영역을 확장해 IT스타트업에서 그로스 마케터로 일하게 되며 처음 하게되는 것들이 많아졌다. 잘하고 싶은 마음에 [회고 ▶️ 액션플랜 찾기 ▶️ 업무 적용 ▶️ 회고]를 반복하며 일하는 나의 하루를 매일 들여다봤다. 좀 더 단단한 내가 될 수 있도록 큰 힘이 되어주고 있다. 오늘은 이 기록들 중 개발과 관련된 것 몇 가지를 풀어보고자한다.

1. 개발요청을 할 땐 WHY 뿐만 아니라 IMPACT까지 이야기하자.

나는 다른 사람에게 업무 요청할 때 WHY를 이야기하는 것이 기본이라고 생각한다. 상대방의 업무 스케줄에 나의 요청사항이 들어가는 일이기에 상대에게 필요한 일이라는 공감을 얻기 위해서다. 업무 요청을 받은 담당자가 WHY에 따른 WHAT으로 더 좋은 방안을 간혹 제안해 주시기도 해 더 좋은 결과물을 만드는 데 도움이 된다.

여기까진 배운 점이라기보단 기본이라고 생각했던 것이었는데, WHY뿐만 아니라 해당 업무에 대한 기대효과까지 개발팀에 이야기하면 좋다는 것을 이번에 배웠다. WHY만으로도 요청할 때 담당 부서에 필요한 정보가 충분하다고 생했는데, 기대되는 IMPACT가 큰 요청사항이라면 기존의 개발 우선순위를 바꿀 수도 있어 일정 조율에 중요한 요소가 된다. IT 특성상 항상 개발 거리는 넘쳐나고 우선순위에 따라 개발이 이루어지기 때문이다. 그 기대효과를 나만 알지 말고 개발 요청할 때 함께 공유하자.

2. 개발자에게 '안된다'는 이야기를 들었다면, 안되는 이유를 정확히 파악하자.

앱 상단배너 상세페이지에 어떤 기능 추가를 요청드렸었는데, 개발자분으로부터 이번 앱 배포 때는 반영이 안될 것 같다라는 이야기를 들었다. 그래서 '아 이번엔 안되는구나, 다음번엔 반영되겠지'하고 자리에 와서 앱 배포 때 반영될 기획을 수정하던 중 아차 싶었다. 왜 안되는지 내가 구체적으로 이해되지 않은 채로 자리에 왔기 때문이다. 또한 이번에 반영이 안된다고 해서 다음번에 반영되리라 100% 장담할 수 없다. 다시 개발자분께 가서 같은 생각을 하고 있는 것이 맞는지 확인하고, 안되는 이유를 정확히 여쭤보았다. 안되는 이유에 맞는 최적의 조율을 하려면 원인 파악을 정확히 하는 것이 중요하다. '아차'싶었던 순간에 스스로 너무 아마추어같았단 생각에 마음이 괴로웠는데 '지레짐작 하지말자'는 교훈을 얻었다.

3. 개발 코드명을 정할 때 이름은 개발자와 상의해서 정하는 것이 좋다.

페이스북 픽셀, 채널톡 함수, 배너 데이터로깅 등 개발자에게 요청할 일이 있을 때 처음엔 이름까지 정해서 요청 문서를 공유드렸었다. 그 이유는 꼭 그 이름을 고집해서는 아니였고, 이름까지 적어서 공유드리는 것이 업무 요청자가 해야할 일이라고 생각해서였다. PO분의 피드백을 통해 개발자분들이 특정 코드에 대해 네이밍 규칙을 정해놓았을 수 있다는 걸 알게 되었다. 내가 이름을 정해서 공유하면 개발자분들은 꼭 그 이름으로 해야만 하는 것으로 생각하실 수 있어 그 이후 요청서에 이름은 제가 직관적으로 임의로 설정해둔 것이며 개발 규칙에 따라 더 좋은 네이밍으로 해주셔도 무관하다고 기재해두었다.

4. 개발 요구사항을 전달할 땐 나름의 학습과 정리를 꼼꼼히 해서 공유하자.

4번은 배운점이라기보단 내가 잘했던 점이다. 개발자 분이 '개발 요구사항을 전달주실 때 나름의 학습과 정리 후에 주셔서 개발에 들어가기 수월했습니다.'라며 내게 긍정적인 피드백을 주셨던 부분이다.