전제 조건
1.
‘팀’형태여야 함
2.
팀 멤버가 IT 커뮤니티 경험이 있어야 함
3.
고도화 시키고 싶은 프로젝트가 있어야 함
선발 기준
1.
전제 조건의 엄격함 정도
a.
2번의 기준에 대해서는 너무 엄격하게 보지 않기로.
b.
4명이 넘어가는 팀의 경우 팀 멤버 중 1,2명이 IT커뮤니티 경험이 없어도 프로그램 참여에 큰 문제 없을 것으로 판단됨.
→ 팀원들이 그 부분을 인지하고 해당 멤버를 섭외했을 것이기 때문.
→ ex) 2021FW 바프플래너 팀 : 중간에 다른 개발자를 섭외했지만, UPF에 가입하진 않았음.
2.
페어링: 플랫폼 or 도메인
a.
학생 
직장인
직장인i.
2021FW : 학생 직장인 페어링으로 진행. 학생팀의 경우 학교 일정에 따라 프로젝트가 용두사미가 되는 경우가 많았음. 후반으로 갈수록 페어링시 학생팀과 직장인 팀의 진행도 차이가 벌어져서, 페어링의 질이 떨어지는 문제도 발생.
⇒ 프로젝트 진행도와 참여 텐션의 차이 등, 변수가 존재하기 때문에 다소 아쉬움 있는 페어링 기준이라고 판단.
직장인 페어링으로 진행. 학생팀의 경우 학교 일정에 따라 프로젝트가 용두사미가 되는 경우가 많았음. 후반으로 갈수록 페어링시 학생팀과 직장인 팀의 진행도 차이가 벌어져서, 페어링의 질이 떨어지는 문제도 발생.
⇒ 프로젝트 진행도와 참여 텐션의 차이 등, 변수가 존재하기 때문에 다소 아쉬움 있는 페어링 기준이라고 판단.b.
플랫폼 or 도메인 (앱 앱 / 웹 웹 / 웰니스 헬스케어, 광고 커머스) → 결정
앱 / 웹 웹 / 웰니스 헬스케어, 광고 커머스) → 결정i.
같은 도메인 형태의 팀끼리 페어링할 경우 더 디테일한 기술적 피드백 가능하다는 장점 있음.
ii.
1차 페어링: 플랫폼 or 도메인 → 2차 페어링: 랜덤 페어링 → 3차 페어링: 1차 페어링 조합으로 다시 돌아오기.
iii.
랜덤 페어링 장점: 다양한 팀과의 친목 도모 가능 / 다른 도메인 형태의 팀이 만날 경우 순수한 유저 테스트 가능. 기술적인 피드백이 아닌 진짜 “유저"로서의 피드백.
c.
추가 기준 도입 (지원팀의 종류와 수가 딱 맞아떨어지지 않을 경우)
i.
프로젝트 분야 or 프로젝트 진행 단계
⇒ 1차 기준은 “도메인 형태”로 두고, 남는 팀들은 추가 기준을 활용해 페어링.
3.
프로젝트의 특징
a.
불법적인 프로젝트가 아닐 경우 모든 프로젝트 OK.
b.
최대한 기존에 없던 형태의 서비스일 것.
→ 유사성을 피하기 위해 중간에 기획 단계로 돌아가는 문제가 생길 수 있기 때문.
→ 기존에 있는 서비스를 개발하고자 할 경우, 기존 서비스와 차별점이 확고해야 할 것.
c.
프로젝트 고도화의 목표가 명확할 것.
→ 지원서의 자료를 보고 목표 명확도 파악. (ex. 기술스택 변경, iOS 끝내고→안드로이드 어플을 만든다.)
4.
팀 멤버들의 실력
a.
실력을 알 수 있는 방법?: github를 통해서 어느 정도 유추 가능
*고도화가 목표면 멤버들의 실력이 좀 좋아야 되지 않나? (은빈)
⇒ 스스로의 목표만 달성할 수 있다면 OK. 대단히 훌륭한 기술 혹은 디자인 수준이 아니어도 무방. (하얀)
5.
지원서의 퀄리티
a.
지원서와 발표 자료 작성의 정성 정도에 따라 팀의 참여 의지를 알 수 있음.
b.
기본 전제조건만 맞는다면, 이 외의 요소에 대해서는 팀의 참여 의지를 가장 중요시 여겼으면 좋겠음.
6.
서비스 도메인 다양화
a.
하나의 도메인 형태에만 몰리지 않게 할 것.
정리: 선발 기준의 중요도 순서
1.
지원서/자료의 내용 (참여 의지, 고도화 목표 명확도 등)
2.
프로젝트의 성격
3.
서비스 도메인 다양화
4.
팀 멤버들의 실력
→ 크게 중요하지 않지만 최소한의 실력(자체적으로 프로젝트 수행할 수 있음)은 있어야 함.