분류 전체보기 60

04. 더 나은 유저보이스 시스템 만들기 - 上

이전 글 B2B기업에서 유저보이스가 중요한 이유에서 언급했다시피, 페이히어는 대부분의 기능 개발을 사장님들의 유저보이스 기반으로 하고 있었다. 그 정도로 유저보이스가 정말 중요한 회사에서 가장 처음 맡게 된 업무는 바로 "채널톡 태그 개편" 작업이었다. 이번 글(上편) 에선 해당 업무를 왜 하게 되었는지, 그리고 해당 업무의 중요성에 대해서 적어보고자 한다. 1. 채널톡 태그? 1) 채널톡 채널톡은 쉽게 말하면, 고객센터에서 쓰는 상담용 Tool이라고 볼 수 있다. 각종 채널(ex. 카카오톡, 전화)에서 들어온 상담이 "1) 채널톡이라는 플랫폼 한곳에 모이고, 2) CX(CS) 상담사 분들이 이 플랫폼 내에서 한 번에 상담관리" 를 할 수 있다. 2) 페이히어에서 채널톡의 역할 페이히어 CX(CS)부서에..

03. B2B 기업에서 유저보이스가 중요한 이유 (feat. 왜 우리 회사는 멋들어진 데이터 분석을 하지 않을까?)

Intro 회사에서 본격적으로 받았던 첫 업무인 "채널톡 태그 개편 작업"에 대해 이야기 하기 전, 그 업무가 회사에 "왜 중요했는지"를 설명하고자 한다. 이를 위해 먼저 기능개발에 있어 B2C와 B2B의 차이를 먼저 설명하면서, 이야기를 시작해보고자 한다. (*물론 페이히어는 B2B SaaS를 하는 기업이긴 하지만, 소상공인(ex. 식당 사장님) 한명한명을 대상으로 한다는 점에서 약간은 B2C 적인 성격도 존재하긴 한다.) (** 회사마다 특징이 다르므로, 모든 B2C/B2B기업을 일반화할 수는 없고, 경험한 기업들을 바탕으로 정리한 것임을 참고바란다.) 회사에선 어떻게 기능 개발을 할까? (B2C vs B2B) B2C 일반적인 B2C IT 기업에서는, 사용자들의 앱/웹에서의 행동 데이터(ex. 클릭률..

02. "네? 카드 단말기를 직접 연결해보라고요?"

페이히어 첫 입사날 가장 인상 깊던 것 누군가가 페이히어라는 회사에 처음 입사했던 22년 11월 가장 인상 깊었던 게 뭐냐?라고 묻는 다면 무조건 말할 수 있는 게 있다. 바로바로 결제 하드웨어 보통의 사무실은 컴퓨터와 책상으로 이루어져 있다. 하지만, 페이히어의 사무실엔 컴퓨터와 책상 외에도 각종 태블릿과(모바일 pos 및 각종 태블릿 기반 앱을 제공하기 때문), 키오스크, pos, 각종 카드단말기, 주방용 프린터 등 처음 보거나, 식당에서 본 적은 있어도 유의 깊게 봐본 적은 없던 여러 기계들이 자리하고 있었다. 페이히어는 pos를 기반으로 오프라인 매장에 필요한 모든 것들을 공급하는 회사이기에, 어찌보면 이게 회사입장에선 당연한 풍경이었다. 더 신기했던 건 모든 직원분들 자리에 최소 태블릿과 신용카..

01. 2번째 회사로 더 작은 스타트업을 선택한 이유

이전 글은 링크 참고(https://doobeom-coding.tistory.com/40) [대학생! 핀테크 스타트업 PO가 되다] 00. Prologue - 연재 배경 연재 배경 22년 8~10월 첫 번째 인턴(번개장터 플랫폼 전략기획) 후, 바로 11월에 2번째 인턴(페이히어 PO(인턴))의 기회가 생겼었다. 22년 11월부터, 23년 8월 말까지 거의 10개월간 일상의 대부분을 회 doobeom-coding.tistory.com 때는 22년 9월 번개장터 전략기획 인턴 3개월(22년 8월~10월)이 끝나기 직전, 우연한 기회로 페이히어라는 기업에게 채용 제안 메일을 받게 된다. 22년 5월 IT 벤처 연합동아리 SOPT의 운영진(기획파트장)을 하면서, 페이히어에게 해커톤 후원금을 요청한 건이 있었는..

Prologue - 연재 배경

연재 배경 22년 8~10월 첫 번째 인턴(번개장터 플랫폼 전략기획) 후, 바로 11월에 2번째 인턴(페이히어 PO(인턴))의 기회가 생겼었다. 22년 11월부터, 23년 8월 말까지 거의 10개월간 일상의 대부분을 회사에서 PO 업무를 하는데에 보냈다. 인턴...이라는 명칭이었지만, 실제로는 정규직 그 이상의 업무를 진행하며 이전부터 해보고 싶었던 PO 업무를 진득하게 해볼 수 있던 시기였다. 이전에 회사를 다니기 전 대학생 친구들과 사이드 프로젝트를 하면서 PM 역할을 해봤던 것들과 같았던 지점들도, 또 새로 배웠던 지점들도 굉장히 많았다. 일을 하면서, 이쪽 업계로 계속 가는 게 맞을지에 대한 고민들이 오히려 더 생겼던 것 같기도 하다. 일을 하면서도 와, 이건 진짜 블로그 소재로 괜찮겠는데? 라는..

[SOPT] 나도선배 릴리즈 회고(하) - 아쉬웠던 점, 개선점 중심

이전 회고 글에선 좋았던 점 중심의 글이었다면, 이번엔 팀원들이 말했던 아쉬웠던 점들 바탕으로 어떻게 개선해야할지를 적어보고자 한다. 팀원들이 언급한 아쉬운점을 먼저 말하겠다. 2. 아쉬웠던 점 및 개선점 1) 팀원들이 언급한 아쉬운점 1. 첫 릴리즈 목표로 잡은 범위가 있는데, 릴리즈 후 추가업데이트를 결정하는 상황에서의 미숙함. 실제 피드백 내용: 릴리즈가 됐는데 릴리즈 직후 나온 피드백을 바탕으로 추가업데이트를 빠르게 결정했던 것. 릴리즈 이전에 기획적으로 고민되는 것들을 팀내에서 같이 고민하고 갔다면?(이걸 같이 고민하고, 서비스에 대해 점검하는 시간을 가졌다면, 베타테스트를 진행해서 사용자의 의견 들어보는 방법 있었을 것) 예측으로 기획한 것이 실패하더래도, 이를 뒷받침하는 근거나 이유에 대해 ..

[SOPT] 나도선배 릴리즈 회고(상)- 좋았던 점 중심

앱잼때는 바빠서. 앱잼이후에는 기팟장과 임원진일, 그리고 다시 시작된 릴리즈 준비, 3주간의 휴가를 끝내고 돌아와 다시하는 공익근무로 정말 쉴틈없이 살아서 블로그를 멈추고 있었다. 물론 이 릴리즈 회고 내용에 앞서서 적을 내용들이 많지만(기디 팀빌딩 후 작업내용, 앱잼 3주간 첫 개발자와의 협업 내용, 릴리즈 준비과정에서 주차별 느낀점 등) 일단 릴리즈회고를 한 직후의 것들을 바탕으로 까먹기 전에 적어보고 싶어서 이렇게 글을 적게 되었다. 또, 피드백을 받았던 것중에 정말 고쳐야 겠다고 느꼈던 것도, 꼭 기억해야겠는 피드백도 있었기에 글로써 내 감정을 정리해나가고, 좀 더 기억해나가려 한다. 글은 아래 순서로 진행될 것이며, 1. 좋았던 점과 2. 아쉬웠던 점 같은 경우에는 1)내가 회고내용으로 적은 것..

[SOPT] 나도선배 앱잼 회고 3_개발자 팀빌딩

이번 글에서는 개발자 네트워킹 과정과, 실제 개발자 팀빌딩을 거쳐 개발 팀원들을 모셔왔던 과정에 대해 이전 글들에 비해선 간단히 적어보려 한다. 3. 개발자 팀빌딩: 개발자 네트워킹 및 개발자를 모셔오는 과정(12/27~1/2) 1) 개발자 네트워킹 이전(~12/27) SOPT에서 준비해주는 개발자 네트워킹 이전에도, 개발자 분들 중 열정 넘치는 일부는 포트폴리오를 먼저 보내주기도 했었다. 이런 포트폴리오를 받아보면서, 왜 이사람들을 우리 팀에 오고 싶은지 파악을 해보려 했다. 실제 기-디 팀빌딩에서와 개발 팀원을 뽑는 가장 큰 기준은 다르지 않았다. 물론 개발적인 실력, 우리가 구현하려는 걸 구현해줄 수 있냐. 이것도 중요한 요소였지만, 우리 팀의 전체적인 팀분위기와 잘 맞을지, 우리가 전체적으로 가져..

[SOPT] 나도선배 앱잼 회고 2_기-디 브랜딩 기간(2주)

2. 기디 팀빌딩 이후 기디 작업과정(개발자 팀빌딩 전까지. 개발자 네트워킹 내용 제외) 0) Pre Meeting(12/18) 팀빌딩 당일 첫 회의일정을 잡으면서, 간단하게 "나도선배에 들어온이유"와 "나도선배에서 하고 싶은것"에 대한 기디 팀원들의 의견을 들었었다. 실제로 어떤 팀플을 하던 내가 리더로서 가장 중요하게 생각하는 부분은 팀원으로 들어온 사람들이 이 팀에서, 이 서비스에 들어온이유와, 여기서 얻어가고 싶은 건 무엇인지 파악하는 거라고 생각한다. 사람들은 자기가 원하는 것을 얻을 수 있다고 생각이 들 때 그 팀이나, 그 팀에서 하는 일에 더 열정이 생긴다 생각하기 때문.! 또 이사람들이 원하는 것과, 팀이 해야하는 것간에 조율을 잘 해나가는 것이 필요하다고 생각했다. 그래서 이 작업을 처음..

[SOPT] 나도선배 앱잼 회고 1_기-디 팀빌딩

SOPT 길고긴, 앱잼이 끝났다. 앱잼 땐 정신이 없어서, 그 과정들을 일일이 적어두진 못했지만, 더 까먹기 전에 기록을 해둬야겠다는 생각에, 이렇게 블로그글을 작성한다. 순서는 크게 아래와 같다. 1. 기디 팀빌딩: 디자이너, 기획자를 모셔오는 과정 2. 기디 팀빌딩 이후 개발자 네트워킹 이전까지의 기디 작업과정 3. 개발자 팀빌딩: 개발자 네트워킹 및 개발자를 모셔오는 과정 1. (12/11~12/18) 기디 팀빌딩(디자이너, 기획자를 모셔오는 과정) 1) 기획경선 이후 심정 기획경선이 12/11일에 끝나고, 쉴틈없이 다음 일정이 몰려왔다. 어찌보면 이 앱잼에서 가장 길게 함께 하게될 팀원인 기, 디 팀원을 뽑는 일. 그리고 지금까진 기획을 혼자 해왔다면, 함께 기획할 팀원을 뽑는 일이기도 했다. 솔..