정리
제품은 실패했지만 좋은 코드 vs 코드는 별로지만 좋은 서비스
코드의 목적은 예쁜 코드를 짜는 것보다는 팀이 풀고 싶은 문제를 해결해서 고객에게 가치를 제공하는 것이다. 그런 관점에서 서비스의 성공이 더 중요하다고 한다.
또한 프로덕트 스테이지에 따라 다를 수도 있는데,
제품을 빠르게 검증하고 성장시켜야 하는 얼리 스테이지에서는 코드의 퀄리티보다는 빠르게 제품의 이터레이션을 돌릴 수 있도록 지원해야 하는 것이 메이커로써 가져야하는 역량이라고도 한다.
무엇보다 월급은 제품에서 나온다!ㅋㅋㅋㅋ
어떤 요구사항이든지 다 들어주는 개발자 vs 요구사항을 잘 정의하는 개발자
요구사항이 들어왔을 때 그대로 구현하는 것과,
그 문장 안에 내포하고 있는 그 목적을 찾아가지고 구현하는 것은 굉장히 다르다.
기획자들이 A라는 기능을 요구한 이유, 이루고 싶은 목적을 먼저 확인하면 A라는 기능을 안 구현하고도 그 목적을 달성할 방법을 역으로 제시할 수 있어서 정의 부분에 시간을 쓰는 것도 중요하다.
특히 기획자분들은 프론트엔드의 코드 베이스를 정확히 모르기 때문에,
우리는 기술자이기 때문에 실제로 하고 싶은 것을 해결해 주는 것이 중요하지 그 요구사항 자체가 중요한 것은 아니다.
상황을 예를 들어보자.
기획자가 ‘이것 언제까지 돼요?’ 라고 했을 때,
‘네, 일주일이면 될 것 같아요’ 라고 바로 말하기 보다는
‘이거에서 저거로 바꾸기만 하면 개발 시간을 줄일 수 있을 것 같은데 이렇게 한 번 검증하고 성과가 괜찮을 때 디벨롭 해보면 어떨까요?’ 라고 말하면서 이터레이션을 한 번 더 돌려보는 것이 중요하다.
즉 정리해보면, 문제를 그대로 구현하는게 아니라 정의하는 것이 중요하다.
요즘 네부캠 베이직 과정에서 구현 보다는 문제를 정의하려고 시간을 투자하고 생각을 많이 하고 있다.
이러한 사소한 시간들도 굉장히 유의미하게 느껴진다.
다른 팁들
제품을 더 빨리 런칭하고 유저의 목소리를 더 듣는게 중요하다.
토스에서도 그렇고 스타트업에서도 그렇고 타석에 자주 들어가야 안타를 많이 칠 수 있으므로,
빨리 빨리를 자주 언급하셨다고 한다.
나도 소프트웨어 마에스트로에서 PrayU를 개발하면서 1주일 단위로 스프린트를 진행하면서 빠르게 개발한 경험이 있다. 그 때는 유저들을 빠르게 만나고 싶었고, 유저들이 요구사항을 말하면 그것의 문제를 정의하기보다 빠르게 구현하기만 하려고 했다.
어쩌면 이 때 문제를 정의하면서 진행했다면 배울 것도 더 많았을 것이다.
