200여개의 프로젝트를 진행하면서 느낀점들
브런치를 잘 운영하지 않았지만 새롭게 다시 태어나 개발 인사이트를 꾸준히 전달하고자 한다.
누군가에게는 도움이 되기를 바라면서
약 6~7년간 에이전시를 운영하면서 자잘한 외주부터 대형 플랫폼까지 어느덧 200개가 넘는 프로젝트를 거쳐왔다. 오늘은 꼭 문제가 생겼었던 프로젝트들을 회상해보며 꼭 망하는 (망할 조짐이 보이는)
프로젝트들의 공통점에 대해서 이야기를 해보고자 한다.
자체 경험 뿐만 아니라 주변 개발사들로부터 이야기를 까지 포함한 이야이가.
망하는 프로젝트들의 주요 공통점들을 한 번 보면 아래 3가지다.
1. 지속적인 변경 요청
2. 얕은 지식을 가진 사람이 프로젝트 리더일 때
3. 사업보다 기능에 집중할 때 (주객전도)
그 외에도 높은 개발 난이도에 비해 턱없이 부족한 예산 , 소통의 부재 등등이 있겠지만
위 3가지만 없어도 90%는 조금 더 프로젝트가 좋게 세상에 나오지 않았을까 싶다.
그럼 위 3가지에 대해서 좀 더 이야기해보자면
보통 프로젝트들을 처음 출시하다보면 내가 생각했던 것을 그대로 문서화하기는 어렵다.
그렇기에 기획이 완벽하지 않았을 것이다.
그렇게 프로덕트를 막상 출시했는데 뭔가 아쉽다.
(이 부분은 초기 프로덕트에 애정과 욕심이 많아지면 생길 수 있는 문제다.)
그래서 이거조금 저거조금 수정요청이 들어온다.
사실 작은 수정요청이야 반영가능하다.
하지만 의뢰사가 알아두어야하는 것은 언제나 시간과 리소스가 한정되어있다는 것이다.
한 두번은 좋은 방향성이라 믿고 기꺼이 기능변경을 수정했다.
그래 백번 양보해서 어느정도의 화면/텍스트/Flow 수정정도야 어느정도 수용가능하다.
하지만 DB(데이터베이스)의 변경요청도 들어온다.
어렵다고 아무리 말씀드려도 한번 결정한 마음을 돌리기는 어려웠다.
추가금을 내면서까지 수정하기도 한다.
그렇게 수정해서 나오면 어딘가 또 맘에 안드는 부분이 그제서야 보인다.
그렇게 프로젝트의 기약은 없고 출시는 미뤄진다.
의뢰사 수행사 모두의 흥미도 떨어지고 좋았던 출시 타이밍도 놓칠 수 있다.
물론 완벽한건 없다. 때로는 바꾸는 기획이 더 맞았을 수도 있다.
하지만 가장 중요한건 덜 완벽하더라고 큰 시압 방향성의 수정이 아니라면 빠른 출시 후
시장반응에 따라 유저들의 목소리에 따라 변경을 조금씩 해나가는게 가장 바람직해보인다.
우리가 아는 대부분의 프로젝트가 그렇게 성장해왔다.
가장 큰 문제는 개발에 대해 깊에 알지 못하는데,
얕은 지식으로 지휘를 해야하기 때문에 자꾸 방향성이 산으로 간다.
예를들면 꽤나 어려운 결제 기능 등을 순식간에 되는 줄 알고 있다.
(쇼핑몰 등에서는 쉽게 붙일 수 있는게 실제 개발에서는 다르다는 것을 몰라서)
이게 반복된다면 수행사 입장에서는 그저 따르면 되는 문제일 수 있긴 하지만
사실 마음이 편치않다. 이대로 가면 안된다는 것을 분명히 알고 있는데
억지로 개발하고 있는 동료들을 볼 수 있다.
만약 내가 스스로 IT에 대해서 깊게 알지 못한다면
어느정도는 귀기울이며 협업하는게 최선의 선택이다.
사실 고객사들은 의뢰사이기 전에 좋은 서비스를 사용한 user이다.
이는 절대적으로 해결할 수 없는 문제다.
그렇기 때문에 우리가 흔히 쓰는 서비스들은 기능들인 너무나도 많고 잘되어있다
그렇기에 내가 만드는 서비스도 당연히 이정도 기능들은 있겠지 생각하게 된다.
예를들면 커뮤니티의 기능이다.
게시판이 있으면 댓글이 있다.
여기까지는 그럴 수 있다.
댓글에 대댓글도 있어야하고 또 대댓글까지 요구할수도 있다.
(그게 꼭 필요했으면 사전에 정의했었어야 한다.)
사실 초반부터 대댓글까지 필요한 서비스는 많지 않을수 있다.
그러다보면 기능에 집중하다보면 도대체 이 서비스의 PMF는 무엇인지
핵심 기능은 무엇인지 무엇을 위해만들어지는지 모를때가 있다.
즉 이도저도 아닌게 된다.
초기 프로젝트라면 초기 프로젝트 다울때 비로소 아름답다.
이번 글에서는 프로젝트 의뢰 맡기기 전, 또는 내가 프로젝트를 리드하기 전에
꼭 명심했으면 하는 3가지에 대해서 이야기해보았다.
앞으로 개발 경험 및 인사이트를 꾸준히 업로드 예정이다.
해당 글은 인사이트 경험을 작성하기에 AI를 일체 이용하지 않습니다.