240602 한 주 회고
파트너 제안 페이지 개발 중
왜
어떻게
- 리툴에서 개발 진행
- 현재 준비 중인 ‘비즈니스 사이트’와 통합해 인증 기능을 추가 개발하는 공수를 줄임
- 리툴 사용법이 이미 익숙해져서 프론트 개발을 직접 진행할 수 있음 → 개발 리소스 절약
- 추후 유지보수도 직접 가능
- 디자인에 집중
- 고객사 인터뷰 결과, ‘우리한테 맞는 인재인지 잘 모르겠다’는 피드백 있었음
- 기존 프로필에는 너무 일반적인 내용들이 많이 나열되어 있어 그랬다고 판단
- 고객사 문제 상황을 깊이 있게 이해하고 그에 딱 맞는 인재를 제안했다는 맥락을 시각적으로 최대한 강조하는 게 중요하다 판단
진행 상황
프로젝트 제안 페이지 개발 중
왜
- 파트너에게 프로젝트 의사 물어보고 회신 기다리는 데 시간 오래 걸림
- 여러 명에게 제안 보내면 더더욱
- ‘시간 제한’을 명시하고, 파트너가 최대한 빠르게 회신할 수 있도록 만들기
- 파트너를 고객사에게 소개할 때 고객사 요청 사항에 맞는 파트너의 경험을 파악하는 게 중요
- 이걸 프로젝트 제안 단계에서 파트너가 직접 대답하도록 하면 딜 매니저의 공수를 줄일 수 있음
- 이외에도 주당 업무 가능 시간, 고객사 미팅 가능 시간 등을 파악하는 과정을 자동화해서 오퍼레이션 시간을 단축하는 게 목표
어떻게
- 탈리폼으로 프로토타입 구현
- 프로젝트 제안 페이지를 만드는 건 개발-디자인 사이클을 여러 번 돌려야 하는 작업
- 그런데 우리 회사는 개발 리소스가 절대적으로 부족
- 이런 방식으로 프로젝트 제안을 보냈을 때 파트너가 잘 회신할 거란 확신 없는 상태에서, 큰 규모로 개발 시작하기보다는 최대한 간단한 방법으로 구현하는 게 맞겠다
- 하지만 기술적 한계 존재
- 탈리폼에 들어갈 모든 개인화된 내용을 URL Parameter로 전달하고 있는데, 보안 + 길이 제한 등의 한계 많음
- 탈리폼으로 몇 주 운영하면서 개선사항 수합한 뒤 정식 기능으로 이전할 필요 있음
딜 시나리오 기능 개발 중
왜
- 프로필 전달 이후 고객사 회신율 저조
- 퍼널 병목 해소를 위한 가설 중, 주기적 리마인드를 통해 번지 존재감을 지속적으로 어필하자는 의견 나옴
- 인재 서칭이 어디까지 진행됐고, 앞으로 어느 정도 시간이 걸릴 거라는 명확한 로드맵을 제시하면 고객사의 온도가 떨어지는 걸 막을 수 있겠다
어떻게
- 서버에서 배치 돌려서 주기적으로 메시지 발송하는 건 백엔드 개발자분이 진행해주실 예정
- 발송 일정을 조절하고, 발송 내역을 파악할 수 있는 기능은 내가 프론트 작업 진행
회고
화려하고 큰 기능에 대한 환상 버리기
- 딜 시나리오를 관리하는 기능을 너무 화려하게 개발하려 함
- UI도 복잡해지고 프론트 구현에 너무 시간을 많이 써버림
- 그런데 구현하고 보니 사용자 경험이 좋지 않을 것 같다 판단해 기존 작업한 UI는 결국 폐기
- 항상 ‘최소한의 공수로 최대한의 효율 내기’를 잊지 말 것
덩치가 큰 작업을 동시에 진행하는 것이 부담스럽다
- 동시에 진행하다 보니 우선순위 산정에 어려움을 겪었고, 솔직히 이렇게 진행하는 게 최선이었는지 지금도 의문
- 해야할 일을 나열한 다음 타임라인을 더 확실하게 그려봤으면 좋았을 듯
개발자와 잘 협업하기
- 딜 시나리오 UI를 한 차례 갈아엎으면서, 기 개발된 API의 자잘한 수정 요청을 너무 많이 드렸음
- 테스트용 데이터는 굳이 API가 없어도 뿌릴 수 있는 방법이 많으니, 앞으로는 좀 더 UI가 확실히 결정된 이후 개발 요청을 드려야겠다
최소 기능 제품?
- 최대한 빠르게 출시하고 딜 매니저들에게 빠르게 피드백을 구하려다 보니, 오히려 피로감을 줬다는 생각
- 완성되지도 않았고 잘 작동하지도 않는데 피드백을 달라 하니 그냥 난감
- 이 제품을 기획하면서 생각했던 ‘핵심적인 유저 가치’가 구현되지 않은 상태라면 MVP라고 볼 수 없다고 생각
피드백이 필요하다면 내가 직접 유저가 되자
- 그런데 딜 하나 정도를 맡는 건 내가 할 수 있음
- 엉성한 제품 출시해서 바쁜 매니저를 괴롭히지 말고, 그냥 내가 딜을 하나 맡아서 직접 어드민을 써보면 더 느끼는 바가 많았을 듯
- 유저와 멀어지지 말고, 항상 유저 입장에서 경험해보려고 노력하기