메이커 중심 팀의 점진적 기능 개발 방법론

제품 개발에서 보통 속도와 퀄리티는 상충된다. 개발 속도가 빠르면 퀄리티가 낮아지고 퀄리티를 높이다보면 개발 속도가 늦춰진다. 그렇다고 기능 개발만 계속 할수도 없고 리팩토링과 디자인을 개선하느라 PMF를 찾아가는 과정에서의 실험을 늦출수도 없다.

기능 개발만 하면 이에 따른 비용이 생긴다.

1. 관리 비용: 새로운 기능은 계속 관리를 해줘야 된다.

2. 인지 비용: 새로운 기능이 추가될수록 프로덕트는 복잡해지고 유저들이 프로덕트를 익히는 것이 더 어려워진다. 이는 신규 유저들을 온보딩하거나 JTBD를 해결하기 위한 기능을 발견하고 사용하기까지 마찰을 가한다.

3. 기능을 덜어내는 비용: 많이 사용하지 않는 기능을 죽일때도 비용이 발생한다. 일부 잘 사용하는 고객들에게 불만족을 주게 된다.

반대로 리팩토링과 디자인 개선에 시간을 너무 많이 쓰면 이에 따른 비용이 생긴다.

1. 가치 누수 비용: 고객이나 비즈니스가 얻을 수 있는 최대 가치가 있는데 기능 추가가 늦어지면 이를 전달하기 위한 비용이 이후에 더 높아질 수 있다. 데이터를 쌓지 못하는 것이 가장 흔한 예이다.

2. 시장 선점 비용: 경쟁사들에게 고객들을 뺏기게 된다.

이 둘 사이에 적절한 균형을 맞춰야 되는데 개개인마다 기준이 달라 정해진 프로세스가 불분명하면 각자 자신만의 리듬과 방향으로 노를 저어 각자 힘은 쓰는데 배의 속력은 나지 않는 상황이 벌어진다.

위의 문제를 해결하기 위해 다음과 같은 순서로 개발 범위를 나누어 점진적으로 프로덕트를 발전시켜나갈 수 있다.

" 기능 개발 → UX 개선 → UI 개선 → 확장성 개선 "

1. 기능 개발: JTBD를 해소할 창구를 만들어주는 것

2. UX 개선: JTBD를 해소하기 까지 마찰을 줄여주는 것

   • 인지 문제: 기능이 있다고 하더라도 유저들이 기능에 대한 인지를 하지 못하면 JTBD를 해소할 수 없다.

   • 유저 플로우 복잡함: 유저 플로우가 복잡하면 유저들이 JTBD 트리거를 느낄때마다 기능을 떠올리고 사용하여 JTBD를 해소하는 습관을 형성하는 것이 어렵다.

   • 버그

3. 즐거움 추가: JTBD를 해소하는 과정에서 즐거운 감정이 느껴지도록

   • UX writing

   • UI

   • Visual Design

4. 확장성 개선: 다음 배포를 더 빨리 할 수 있도록 환경 개선

   • 기술적 개선: 리팩토링, 서버 확장, 코드 모듈화 등

   • 프로세스의 개선: 코드 리뷰, 문서화, 역할 분담 등 개발 과정에서 더 개선할 수 있는 것들을 회고하고 개선

   • 컴플라이언스 개선: 규제, 보안, 안정성 등 개선

디스콰이엇은 PM, 디자이너, 개발자가 따로 분리되어 있지 않고 개발 팀원 모두가 개발 역량을 갖추어 각자의 강점과 부족한 점을 보완할 수 있는 방법으로 개발을 해나가고 있다. 분야를 나누지 않다보니 개발 속도가 빠르다. 하지만 개개인별로 개발, 디자인, PM 숙련도가 다르다 보니 위와 같은 방식을 고민하면서 팀의 개발 리듬을 맞춰나가고 있다.

프로덕트 메이커를 찾습니다!

현재 디스콰이엇은 프로덕트 메이커를 팀원으로 찾고 있습니다. 개발 역량은 필수이며 부족한 PM적 사고나 디자인 감각은 지식 전달 및 상호 보완으로 해결하며 실전을 통해 개개인의 프로덕트 메이커로써의 역량을 높입니다. 관심 있는 분들은 디스콰이엇 개발 직군 채용 공고를 참고하여 지원해주세요. (벡엔드, 프론트로 나누어져 있으며 좀 더 강점인 분야로 지원해주시면 됩니다.)

벡엔드 공고

프론트엔드 공고