비개발자의 개발 분투기 #7 - 사이드프로젝트 주의점 | 퀘스트에 참여하세요

인사이트/로그전체 대상

비개발자의 개발 분투기 #7 - 사이드프로젝트 주의점

#문송합니다 #개발자가되고싶어요 #사이드프로젝트주의점 #두명이상의팀세팅하기 #개발분투기

작성일 : 21.05.09 11:14

👉 본문을 50%이상을 읽으면 '여기까지다' 퀘스트가 완료됩니다(로그인 필수)

안녕하세요 개발분투기를 쓰고 있는 문돌입니다.

사이드프로젝트를 4년동안 네개를 진행했고, 모두 오픈 했습니다.

올해 2월까지 프로젝트 리뉴얼을 마지막으로, 잠시 쉬면서 다른 아이템들을 구상하고 있습니다.

사이드프로젝트를 시작하시면서 조금 주의할 점을 추려서 전달해보면 어떨까 합니다.

지금껏 진행하면서 , "아 이랬으면 좀 더 쉽고 빠르게 개발할 수 있었을 텐데" 혹은

"이런부분이 지속적으로 지켜져서 계속 할 수 있었다"라고 생각해주시면 될 것 같습니다.

이전 글들은 아래에서 참고하실 수 있습니다.

1편 비개발자의 개발 분투기 #1 바로가기
2편 비개발자의 개발 분투기 #2 바로가기

3편 비개발자의 개발 분투기 #3 바로가기

4편 비개발자의 개발 분투기 #4 바로가기

5편 비개발자의 개발 분투기 #5 바로가기

6편 비개발자의 개발 분투기 #6 바로가기

1. 구성원은 최소한으로

커뮤니케이션 비용라고 들어보셨나요? 의사소통 비용이라고 한글로 번역하기도 하는데요

사전적으로 정의된 내용은 별로 없네요. 사전적 정의 찾으신 분있으시면 알려주세요.

제가 임의로 정의를 해보자면,

커뮤니케이션 비용은 , 구성원간의 완전하고 충분한 의사소통을 하기위해서 지불해야 하는 비용입니다.

커뮤니케이션 비용은 구성원의 제곱에 비례한다고 알려져 있습니다.

의사결정에 참여할 사람이 많으면 많을수록 , 이 비용은 상당히 높아집니다.

사이드프로젝트는 , 회사를 다니면서 하시는 분들이 많기 때문에,

1) 주말 하루만으로는 충분하게 커뮤니케이션을 하기 사실상 어렵습니다.

2) 또한 새롭게 조인되는 분들도 많아서 이분들의 대화 스타일을 아는것도, 솔직한 대화를 하는것도 사실 어렵습니다.
3) 대화나 토론을 했어도 일주일뒤에 다 까먹을 때도 많고요.

이러한 사유때문에 , 사이드프로젝트에서의 커뮤니케이션 비용은 정말 상상을 초월합니다.

커뮤니케이션 툴을 이용해서 기록 및 대화를 많이 하는 것도 방법이긴 하지만,

가장 좋은건 구성원을 최소화 하는것이 가장 좋은 방법입니다.

사이드프로젝트를 전업으로 하면 좋겠지만, 우리모두 그게 안된다는 것 아시잖아요

사이드프로젝트는 자신을 포함해서 5명이 넘어가면 좋지 않습니다.

저는 항상 인원은 저 포함해서 4명을 넘기지 않았습니다.

1) 5명이 넘어가면 약속을 잡기가 힘듭니다.

2) 의사결정 포인트가 너무 늘어나고, 이는 사이드프로젝트 멤버분들의 불만족을 야기합니다.

3) 5명이 넘어가면 , 의견은 개진하지 않는 소극적 참여자(?)가 나오기 시작합니다.

그러면 적절한 구성원 몇명인가? 총인원 3~5명입니다.

사이드 프로젝트별로 다르긴 하지만, 우리가 엄청난 것을 첨부터 만들려는 것 아니잖아요

조그만 것을 만들고 수정하고 , 그래도 시장이 반응안하면 포기할 수도 있는 것 아닌가요?

인원이 없어서 시간이 더 걸릴 수 있습니다. 그러나 출시 못하는 것보는 훨씬 낫습니다.

개발/출시 속도는 인원수와 정비례 하지 않습니다.

1) 3명 시작 : 개발자에게 가장 부담가는 모델, 개발이외의 부분은 다른 멤버분들이 모두 책임져주셔야 합니다.

- 기획/PM 1명 :

: 화면/서비스/BM 기획을 하면서 , 전체 프로젝트 관리를 해주셔야 합니다.

: 각 단계별로 방향성을 잡아주셔야 합니다.

: QA를 기획하고, 기획 변경을 최소화하셔야 합니다.

: 비용 관리도 하실 수 있어야 합니다.

- UI/UX 디자인 1명

: 전체 컨셉 및 디자인

: UI/UX을 빠르게 만들어주시고, 피드백에 빠르게 대응해주셔야 합니다.

: 기타 나오는 이슈에 대해 기획분과 일을 나누어서 진행해주셔야 합니다.

- 프론트엔드/백엔드 1명

: 요즘에는 가능하신분들 요즘에는 많습니다.

: 개발업무가 부담가지 않도록 , 개발 스펙을 많이 줄여서 최소한으로 구성하는 것이 중요합니다.

: 중간에 기획이 변경되거나 디자인이 많이 변경되서는 안됩니다.

2) 4명 시작 : 변경이나 수정에 조금 더 자유롭습니다. 역할 분화가 가장 잘 되어있는 상태입니다.

- 기획/PM 1명, UIUX디자인 1명 , 프론트엔드 1명 , 백엔드 1명

3) 5명 시작 : 완전체라고 볼 수 있습니다. 더 이상 멤버를 늘이셔도 효율이 올라가지 않습니다.

- 기획/PM 1명, UIUX디자인 1명 , 프론트엔드 2명(IOS/Android) , 백엔드 1명

2. 기획은 최소한으로 ...(유저의 입력을 줄여라)

유저의 인풋이 많이 들어가는 프로젝트는 시일이 많이 소요됩니다.

보안적인 요소도 신경을 써야하고, 로그인, 인증 등도 부가적으로 엄청 신경써야 하는 부분이 됩니다.

가장 좋은건 단순 터치/클릭만으로 앱의 과정이 끝나는 기획이 가장 좋습니다.

유저에게 받을 부분은 최소화하고 , 터치 등으로 인터랙션을 모두 잡아주거나

단순 조회 기능 정도만 제공해줘도 의미하는 사이드프로젝트가 되실 수 있습니다.

유저의 입력이 없으면 서비스가 뭔 의미가 있겠어라고 하시는 분들은, 키오스크를 한번 생각해보세요 , 차량용 네비게이션 생각해보세요

입력이 많지 않습니다. 거의 모두 터치로 끝나지만 모든 것을 다 하실 수 있죠.

입력을 넣는 것은 사실 우리가 넣고 싶은거지, 사용자가 원하는게 아닐 수 있습니다.

중간에 기획을 줄이면 줄이되, 늘리지는 마십시오. 간결하고 직관적일 수록 좋은 서비스라고 생각합니다.

3. 일정은 짧게 ( 4개월 이내로 돌아가는 것을 하나 만들자)

마일스톤은 3개월 단위로 끊으시는 것이 좋습니다.

안 예뻐도 됩니다. 돌아가는 모습을 보면 구성원들이 동기부여 됩니다.

사람들의 인내심은 그렇게 대단하지 않습니다.

계절만 지나가도 이게 뭐 하는 건가 회의감을 가지시는 분들도 많습니다.

3개월단위로 내부에서 사용하실 수 있는 서비스를 만들어내세요

그리고 작은 성공 이벤트(회식 등)를 여세요. 모두가 같이 한 프로젝트라는 것을 상기시키세요

너무 오픈이 늦어지면 안됩니다. 최종 산출물은 최대 6개월을 목표로 잡으세요

6개월안에 결과물이 나오지 않는다면

- 기획이 너무 크거나, 잘못되어서 계속 수정이 되었거나

- 필요한 사람을 잘 못 모았거나,

- 커뮤니케이션이 잘못되었거나,

세가지 중 하나의 실패라고 생각합니다.

결론

너 이거 다 지키고 사이드프로젝트 했어라고 물어보시면 "아니오" 라고 말씀드리고 싶습니다.

회사도 일정이 밀리는 마당에 , 사이드프로젝트가 일정 지키기는 사실 쉽지 않습니다.

다만 구성원의 인원을 3~4명으로 계속 유지했고, 기획은 줄이는 노력은 항상 했던 것 같습니다.

점점 만들어가는 서비스들이 완성도가 높아지고 있다는 건 체감이 되고 있습니다.

모두 성공적인 사이드프로젝트 하세요!!