망하는 프로젝트들의 공통점 3가지

200여개의 프로젝트를 진행하면서 느낀점들

by 포텐랩


브런치를 잘 운영하지 않았지만 새롭게 다시 태어나 개발 인사이트를 꾸준히 전달하고자 한다.

누군가에게는 도움이 되기를 바라면서



망하는 프로젝트들의 공통점 3가지


약 6~7년간 에이전시를 운영하면서 자잘한 외주부터 대형 플랫폼까지 어느덧 200개가 넘는 프로젝트를 거쳐왔다. 오늘은 꼭 문제가 생겼었던 프로젝트들을 회상해보며 꼭 망하는 (망할 조짐이 보이는)

프로젝트들의 공통점에 대해서 이야기를 해보고자 한다.


image.png 미드저니로 생성해본 무한 기능 요청 (생각보다 잘나온다.)


자체 경험 뿐만 아니라 주변 개발사들로부터 이야기를 까지 포함한 이야이가.

망하는 프로젝트들의 주요 공통점들을 한 번 보면 아래 3가지다.


1. 지속적인 변경 요청

2. 얕은 지식을 가진 사람이 프로젝트 리더일 때

3. 사업보다 기능에 집중할 때 (주객전도)


그 외에도 높은 개발 난이도에 비해 턱없이 부족한 예산 , 소통의 부재 등등이 있겠지만

위 3가지만 없어도 90%는 조금 더 프로젝트가 좋게 세상에 나오지 않았을까 싶다.


그럼 위 3가지에 대해서 좀 더 이야기해보자면


1. 지속적인 변경 요청


보통 프로젝트들을 처음 출시하다보면 내가 생각했던 것을 그대로 문서화하기는 어렵다.

그렇기에 기획이 완벽하지 않았을 것이다.

그렇게 프로덕트를 막상 출시했는데 뭔가 아쉽다.

(이 부분은 초기 프로덕트에 애정과 욕심이 많아지면 생길 수 있는 문제다.)


그래서 이거조금 저거조금 수정요청이 들어온다.

사실 작은 수정요청이야 반영가능하다.

하지만 의뢰사가 알아두어야하는 것은 언제나 시간과 리소스가 한정되어있다는 것이다.


한 두번은 좋은 방향성이라 믿고 기꺼이 기능변경을 수정했다.

그래 백번 양보해서 어느정도의 화면/텍스트/Flow 수정정도야 어느정도 수용가능하다.


하지만 DB(데이터베이스)의 변경요청도 들어온다.

어렵다고 아무리 말씀드려도 한번 결정한 마음을 돌리기는 어려웠다.


추가금을 내면서까지 수정하기도 한다.

그렇게 수정해서 나오면 어딘가 또 맘에 안드는 부분이 그제서야 보인다.


그렇게 프로젝트의 기약은 없고 출시는 미뤄진다.

의뢰사 수행사 모두의 흥미도 떨어지고 좋았던 출시 타이밍도 놓칠 수 있다.


물론 완벽한건 없다. 때로는 바꾸는 기획이 더 맞았을 수도 있다.

하지만 가장 중요한건 덜 완벽하더라고 큰 시압 방향성의 수정이 아니라면 빠른 출시 후

시장반응에 따라 유저들의 목소리에 따라 변경을 조금씩 해나가는게 가장 바람직해보인다.


우리가 아는 대부분의 프로젝트가 그렇게 성장해왔다.


image.png


2. 얕은 지식을 가진 사람이 프로젝트 리더일 때


가장 큰 문제는 개발에 대해 깊에 알지 못하는데,

얕은 지식으로 지휘를 해야하기 때문에 자꾸 방향성이 산으로 간다.


예를들면 꽤나 어려운 결제 기능 등을 순식간에 되는 줄 알고 있다.

(쇼핑몰 등에서는 쉽게 붙일 수 있는게 실제 개발에서는 다르다는 것을 몰라서)


이게 반복된다면 수행사 입장에서는 그저 따르면 되는 문제일 수 있긴 하지만

사실 마음이 편치않다. 이대로 가면 안된다는 것을 분명히 알고 있는데

억지로 개발하고 있는 동료들을 볼 수 있다.


만약 내가 스스로 IT에 대해서 깊게 알지 못한다면

어느정도는 귀기울이며 협업하는게 최선의 선택이다.


image.png


3. 사업이 아닌 기능에 집중할 때


사실 고객사들은 의뢰사이기 전에 좋은 서비스를 사용한 user이다.

이는 절대적으로 해결할 수 없는 문제다.


그렇기 때문에 우리가 흔히 쓰는 서비스들은 기능들인 너무나도 많고 잘되어있다

그렇기에 내가 만드는 서비스도 당연히 이정도 기능들은 있겠지 생각하게 된다.


예를들면 커뮤니티의 기능이다.


게시판이 있으면 댓글이 있다.

여기까지는 그럴 수 있다.

댓글에 대댓글도 있어야하고 또 대댓글까지 요구할수도 있다.

(그게 꼭 필요했으면 사전에 정의했었어야 한다.)

사실 초반부터 대댓글까지 필요한 서비스는 많지 않을수 있다.


그러다보면 기능에 집중하다보면 도대체 이 서비스의 PMF는 무엇인지

핵심 기능은 무엇인지 무엇을 위해만들어지는지 모를때가 있다.


즉 이도저도 아닌게 된다.

초기 프로젝트라면 초기 프로젝트 다울때 비로소 아름답다.


이번 글에서는 프로젝트 의뢰 맡기기 전, 또는 내가 프로젝트를 리드하기 전에

꼭 명심했으면 하는 3가지에 대해서 이야기해보았다.


앞으로 개발 경험 및 인사이트를 꾸준히 업로드 예정이다.





해당 글은 인사이트 경험을 작성하기에 AI를 일체 이용하지 않습니다.



keyword
작가의 이전글앱디자인, 개발을 고려한 디자인은 어떻게 하지?