지노_인터뷰
insight
- 생각보다 사이드 프로젝트 인원 모집에 대한 니즈가 있다.
- 다른 프로젝트들에 대한 관심도는 낮다
ㄴ 근데 지노가 다른 프로젝트들에 대한 경험이 많고(JOP이 5개...) 우리들의 타겟
(커리어 초년생)과는 조금 멀긴 하다.
- 역시나 기획>디자인>개발 순서로 깔끔하게 진행되지는 않는다. 디자이너가 전체 과정에 참여하기도 하고 엎기도 하고 그런다. 서로간의 단계없는 협업이 매우 중요하다.
- 결과적으로 적극적인 피드백은 받지 못하고 있다. 정량적으로 판단 할 수 없어 기준도 불명확하다. 피드백을 한다면 주로 칭찬을 위주로 하게 된다.
ㄴ 피드백을 문자로 할 수 있는 부분 아닐까? 칭찬이 주를 이룬다고 해도 의미가 있다고
생각함. 쓴 피드백은....그래도 그것 나름 의미가 있지 않나....?(.....자신없음...약간 마상일거 같
기두)
(여는 질문)
- 사이드 프로젝트 경험이 있는데, 당시 프로젝트 관리를 어떤 식으로 했는지?(어떤 툴 사용 ? 일정 공유를 하는 방식?)
경험이 많다. 저는 지금도 다양한 일을 하고 있는데 투두리스트를 통해서 관리하고 있어요. 다른 사람들의 일정관리는 노션을 통한 정리.
- 당시 프로젝트를 진행할 때, 아쉬웠던 점이 있다면?(ex. 일정 공유가 빠르게 되면 좋겠다 ~ , 우리가 지금 어디까지 와있는지 알고싶다 등)
일단 첫번째는 코로나가 아쉽고, 제 사이드 프로젝트는 산타인데 처음에 안드로이드 개발자가 없었다. 구인을 할 때 사이드 프로젝트는 회사 개념이 아니니까 사람을 모집하는게 어렵다. 이 부분에 대해서는 시니어 개발자와 이야기했을때도 사이드 프로젝트를 원하시는 분이 많지만 기획자와 디자이너를 찾기 힘들다.
- 사이드 프로젝트 관련해서 웹에서는 그런 서비스들이 많이 있었다. 그런 것들을 이용해본적은 없는지?
없다. 제가 생각했을 때 웹은 있을거 다 있다. 네이버에만 시중의 앱 기능을 가진 것들이 90%가지고 있다고 생각한다.
(본론)
- 사이드 프로젝트를 참여하고 있는 팀원들은, 자신들이 현재 어느 단계에 와 있는지에 대해 명확히 인지하고 있지 못할 것이다. -> 포도알 -> 포레스트 -> 시각화를 잘 해주는 방안
- 보통 팀 빌딩이 이루어진 상태에서 하게 되나요?
보통 그거는 캐바캐인거 같아요. 지금 아까 말한 시니어 개발자 분은 중고차 관련해서 앱을 만들고 싶은데 서버를 다 만들어 놨는데 기획자와 디자이너가 구해지지 않아서 아직도 못만들고 있다고 하셨어요
- 그럼 기획>디자인>개발 이렇게 순서로 진행되는게 아닌거네요?
그쵸 그건 아니죠. 근데 보통은 그럴거 같아요. 만약에 팀빌딩이 스무스하게 이루어졌다는 과정 하에.
- 기획/디자이너 → 일반적으로 프로젝트 초반에 바쁘고, 이후에는 개발자가 작업해서 여유롭다고 알고있다. 단, 이럴 때 진행상황은 어떻게 체크하는지?
거진 기획/디자이너 그리고 개발자가 순서대로 앱을 만들긴 하는데 바쁜걸로 이야기하자면 다들 바쁜거 같아요. 개발자가 초반에는 안바쁘다가 후반에 바빠지긴 하지만.. 하지만 디자이너는 계속 바쁘실걸요? 고모모는 계속 바쁠걸요(ㅋㅋ)
기획/디자이너 → 일반적으로 프로젝트 초반에 바쁘고, 이후에는 개발자가 작업해서 여유롭다고 알고있다. 단, 이럴 때 진행상황은 어떻게 체크하는지?
- 기획자와 디자이너 같은 경우는 개발 프로세스가 어떻게 되는지 모르는데 그런 부분에 있어서 진행 상황은 어떻게 체크할 수 있어요?
이거는 저희 쪽에서 준비하고 있는데 애자일 스크럼이라고 있어요. 보통 스크럼을 통해 전문 스타트업은 공유하려고 하고 있고요. 제가 CMC를 할때는 저랑 디자이너가 거의 함께 일했어요. 함께 다섯시간, 여섯시간 함께 일했고. 개발자와 디자이너의 배려를 통한 소통이 되게 중요한데. 홈화면을 개발했는데 어떤 정도를 했냐면 도화지에다 그림을 그려서 뭐 홈화면을 일단 그렸습니다. 쉽게 이야기하려고 노력을 해야죠.
- 기획에 있어서는 단계가 있고, 디자인의 경우 와이어프레임, 스타일 가이드와 같은 차례가 있는데 개발에도 있나요?
있죠. 굳이 말하자면 있죠. 스타일가이드 단계까지는 픽스할 수 있지만 와이어프레임 단계에서 계속 엎어야하는 경우가 있긴 해요. 개발자 입장에서 와이어프레임이 잘 짜졌다하면은 스무스하게 갈 수 있을거에요.
- 와이어프레임까지 간다고 하면은 어떤 부분에서 어려워지나요?
그 이후에는 구현 단계에서죠. 개발과 센스의 영역일거같아요.
- 프로젝트를 진행하며, 현재 우리의 달성률 같은 것을 확인할 수 있는 방법이 있었는지?
사실 산타를 했을때는 제것 하느라 관심이 없었고요. 그쵸 끝은 알고 있어야지, 달성률은 알고 있어야지 제가 그걸 보면서 하는 맛이 있어서. 근데 그것 또한 스크럼을 활용하여 해소가 가능한 부분이여가지고..
- 스크럼이 정확하게 뭐에요?
에자일 스크럼이라고 스타트업에서 주로 사용하는 방법인데요. OKR을 먼저 시작해요. 예를들어 CMC의 O는 사람들에게 많이 알리고 알림으로써 질좋은 아이디어를 모은다인데. 첫번째 KR은 CMC에 인원을 모은다. 두번째는 만든 앱의 갯수 증가에요. 에자일 안에는 스크럼이 있는데... 아마 엄청 길어질거에요. 근데 이거는 아마 제가 멘토링을 해줄거에요. 개발자 들어오기 전에 기획자들끼리 이야기하는 시간을 가질건데 그때 간단하게 이야기해줄거에요.
- 사이드 프로젝트를 참여하고 있는 팀원들은, 상대를 100% 신뢰하지 못할 것이다.
→ 시간 기록 ,, ? 타이머 ,, ? 사진 등, 상대가 신뢰할 수 있는 방법을 추가해 주는 것에 대한 가설
- 프로젝트를 열심히 하지 않는 팀원 같은 경우에는 어떻게 했는지?
- 그런 팀원들을 프로젝트에 참여시키기 위해 어떤 방법을 사용했는지?
사실 스크럼 단계까지가면 열심히 하지 않는 팀원이 보이고 그것에 대해 말할 수 있는 근거가 생겨요. 왜냐하면 하루 일당량에 달성하지 못하면 그게 보이기 때문에. 근데 정량적인 수치로는 판단이 어렵고 정성적인 수치로 물어보는 경우가 많다. “바쁘세요?” 이렇게.
저의 경우에는 디자이너분이 너무 바쁘세요. 지금 디자인이 중요한 시기인데 저는 친해서 채찍질을 하고 있죠.
- 프로젝트를 처음 시작하면 ‘잘 모르는 사람’과 일해야 하는 상황일 텐데, 이 때 걱정/우려가 생긴다면 어떤 걱정일지? 잘 아는 사람들과 팀을 짜는지?
저는 산타가 사이드프로젝트일때는 주로 아는 사람과 팀을 했어요. 저는 그게 제 특성이고.
모르는 사람과 일해본 경험은 첫CMC때가 그렇죠. 그때 당시에 저의 코딩 실력은 정말로 안좋았기 때문에.. 지금의 CMC와는 달랐어요. 그때는 동시 출시가 아니었어요. 그때는 동시 출시일수도 안드로이드, 또는 IOS만 출시할 수도 있는 팀빌딩이었어요. 그래서 4명 팀 구조였기 때문에 저희 팀은 IOS밖에 없었어요. 그래서 제가 못하면 출시가 안되는 상황이었기 때문에 그게 힘들었죠. 제 실력에 대해 자신감도 없었고.
- 혹시 프로젝트를 진행하며, 망한 프로젝트가 있는지? → 그 이유는?
아뇨 전 없어요. 제가 잘한다 이런 느낌이 아니라. 항상 저는 짐이 되는게 싫어서 잠을 안자면서까지 프로젝트를 진행했어요.
- 프로젝트를 할 때, ‘이 사람은 프로젝트에 참 열심히 참여한다!’ 라고 느껴지는사람이 있을 텐데, 이 때 기준은 무엇인지?
열심히 참여한다의 기준은 정량적인 요소가 아니라 정성적인 요소인거 같아요. 열심히 하는 사람은 딱 보여요. 애정을 가지고 있구나가 보여요.
- 계속해서 수정을 요청하거나 그런 것에서 오는걸까요?
그런 액션이 처음에 시작점이 될 수도 있겠지만. 아 이걸 어떻게 표현해야하지? 저희 서버 개발자분은 산타 프로젝트를 하시는게 너무 행복하다고 하고 디자이너분은 바쁘심에도 불구하고 산타가 잘되었으면 좋겠다며 산타만 생각하고 계시고.. 그게 말만이랑은 조금 달라요. 이건 진짜 정성적인, 감정의 영역인거 같아요. 약간 총체적인 합인거 같아요. 디자이너분 같은 경우도 시간을 투자 많이 하지 못하는데 애정을 가지고 있다는 것을 알고 있어요.
- 사이드 프로젝트를 참여하고 있는 팀원들은 다른 프로젝트들의 진행 과정을 궁금해할것이다. (현재진행, 종료된 프로젝트)
→ 추가결제하고 다른 팀원들 프로젝트 구경,
- CMC를 하면서 다른 프로젝트들의 진행 과정이 궁금했던 적은 없는지?
저는 제가 회사를 다닐 때 CMC가 끝나고 취업을 했는데 그 당시에 저에겐 5개의 job이 있었어요. 그래가지고 저는 밥의 도움을 많이 받았죠. 투두 관리나 일정을 관리하고 할 일을 관리하는 것에 밥의 도움을 많이 받았어요.
다른 프로젝트의 진행 상황에 대해 궁금했던 적은 CMC를 했을 때는 진짜로 정신이 없었어서 제가 7시 CMC인데 개발 기간이 4주밖에 안되었어요. 4주에 맞게 물론 기획이 되었지만은 제가 엄청 빡쎄게 했었고. 다른팀에 관심을 가지지 못했었고. 이 프로젝트들이 유지보수 되고 있냐에서부터 진행상황이 되었냐.
- 할때는 너무 바빠서 신경을 못썼다?
근데 그거는 CMC상황이어서 그랬던거 같고 여유로운 상황이면은 다른 사이드 프로젝트들이 뭐가 있냐 궁금할 수 있을거 같아요. 제가 디자인에도 관심이 많아서 디자이너분이랑 이야기한적이 있는데 서로 디자이너들끼리 이야기할 수 있는 시간이 있으면 좋을거 같더라구요? 근데 그럼에도 불구하고 디자이너도 바빠요.
- 사이드 프로젝트에 참여하고 있는 팀원들은, 다른 팀원들로부터 적극적 피드백을 받지는 못하고 있을 것이다. ( → 익명의 쪽지)
- 사이드 프로젝트가 끝나고 난 후, 본인 스스로를 회고했을 때 좋았던 점과 아쉬웠던 점이 있다면?, 이런 이야기를 남에게도 들었는지?
- 사이드 프로젝트를 진행하며, 다른사람에게 좋았던 점과 아쉬웠던 점이 있다면?, 이걸 그 사람에게 솔직하게 말 했는지?
- 솔직하게 말 했다면 → 혹시 부정적인 피드백도 솔직하게 말했는지?
- 솔직하게 말 하지 않았다면 → 솔직하지 말하지 못한 이유는?
- 사이드 프로젝트를 진행하며, 타 팀원들로부터 많은 피드백을 받았는지?
- 피드백을 받고 싶었던 적은 없는지?
- 많은 피드백을 받았다면, 그 피드백을 받은 루트는?(카톡,,, 대면 ,, 등), 혹시 부정적인 피드백도 받았는지? 실명으로 그 피드백을 받았을 때 기분이 상하지 않았는지?
- 피드백의 중요성이 얼마라고 생각하는지?
어.. 못했다. 잘했다.. 잘했다는 사이드 프로젝트를 진행하는 동안 잘했다고 생각하고 뒤돌아보면 항상 못했다고 생각해요.
아쉬운 점을 피드백한적은..사이드 프로젝트를 진행함에 있어서 아쉬운 점을 이야기하기는 쉽지 않은거 같아요.
당연히 감정적인 부분이라고 생각해요. 팀을 폭파되지 않기 위해서. 제가 디자인적으로 컨펌한적은 많아요. 아쉬운 점에 감정적인 요소가 들어가면 애매해지거든요? “이 부분 여기 있는게 어때요?“ 이러면서 제가 찾은 근거를 보여드리면서 레퍼런스는 이거였고 이게 더 이쁜거 같다. 근데 연락이 잘 되었으면 좋겠다. 이런거는 내가 여자친구 남자친구도 아니고 연락이 잘 되는 부분도 하나의 팀의 요소인데 이런 부분에서는 애매하다고 생각해서 잘 못했죠.
저는 팀원들에게 우쭈쭈를 받고 있어서 그런지 잘했다는 피드백 밖에 안들리네요? 아쉬웠다는 점은 거의 못들었어요. 저희 산타는 특이했던게 100%를 기획했다면 120%의 성과를 본 느낌이었어가지고 서로서로에 대한 아쉬운 점이 거의 없었다.
저는 CMC가 운영국장으로서도 피드백은 환영입니다. 너무 좋습니다. 특히 직접적인 피드백. 저 잘 아시는 분들은 직접적으로 잘 피드백해주세요.
저는 직접적으로 해주는게 좋아요. 피드백에 있어 필요한지 필요하지 않은지를 먼저 생각하고 필요하지 않다면 흘려듣기 때문에 기분은 나쁘지 않아요.
피드백은 중요하죠. 개발자로서도 피드백은 중요하죠.