Skip to content

11.8 화 회의록

Min-h-96 edited this page Nov 8, 2022 · 15 revisions

회의 내용 - 기획(기능 정하기)

1. 아이디어 구체화

프로젝트 파트너 찾는 것을 도와주는 커뮤니티 서비스

1.1 사용자 현황 분석

  • 누구를 대상으로 하는가?

    • 프로젝트 팀원을 구하고 싶은 개발자
  • 대상에 대한 특징, 문제, 상황 또는 환경에 대한 분석

    • 대상은 어떠한 특징이 있는가?
      • 직무의 특징(개발자)
        1. 기술 스택이 다양하다.
        2. 개발 방식에 대한 선호도가 다양하다.(코드 스타일, 작업 시간대, 분업/협업 등)
        3. 프로젝트 기반 인력 운영
        4. 업무상 시간과 장소의 제약이 없는 편이다.
      • 사용자의 특징
        1. 연령대 : 다양하다.
        2. UI 에 친숙한 편이다.
        3. 글쓰기에 익숙하지 않을 수 있다.
        4. 오프라인보다는 온라인 커뮤니케이션이 편하다.
    • 대상은 어떠한 문제를 가지고 있는가?
      1. 그룹/토이 프로젝트를 계획할 때, 파트너를 찾는 데 어려움이 있다.
      2. 파트너를 찾더라도, 나와 다른 코드 스타일이나 프로젝트 진행에 대한 개인 선호도가 달라, 시작하기 전부터 논의에 불필요하게 많은 시간이 소요된다.
      3. 현재 대부분의 플랫폼은 수요자(모집자) 중심으로 프로젝트에 대한 인원을 모집하고 지원자가 지원하는 형식이다.
      4. 현재 대부분의 플랫폼들은 프로젝트가 어느정도 구체성을 띈 이후에 참가자를 모집하고 있어 모집자가 진입장벽이 있을 수 있다.
    • 대상은 어떠한 상황 또는 환경에서 사용하게 되는가?
      1. 하고 싶은 프로젝트가 있어서 같이 할 팀원을 모집하고 싶을 때
      2. 아이디어는 없지만, 본인과 맞는 성향의 사람들과 함께 프로젝트를 하고 싶을 때
      3. 본인의 성향과 맞는 다양한 개발자들과 커뮤니케이션을 하고 싶을 때

1.2 벤치마킹

1.3 주요 기능 도출

대상

프로젝트 팀원을 구하고 싶은 개발자

직무 특징

  • 기술 스택이 다양하다.

모집자는 원하는 기술 스택을 바탕으로 등록자를 찾을 수 있어야한다.

-> 모집자에게는 필터링 기능이 필요하다.

등록자는 자신의 기술 스택을 명시할 수 있어야한다

-> 등록자가 다양한 기술 스택 중에서 선택하는 방식으로 기술 스택을 명시할 수 있어야 한다.

  • 개발 방식에 대한 선호도가 다양하다.(코드 스타일, 작업 시간대, 분업/협업 등)

등록자와 모집자 모두 본인이 선호하는 개발 방식을 보여줄 수 있는 기능이 필요하다.

-> 코드 스타일의 경우, 글로 보여주기에는 한계가 있으므로 가장 잘 표현할 수 있는 코드 일부를 보여주면 어떨까?

-> 작업 방식의 경우, 분업/협업, 원하는 시간대 등을 대략적으로 표기하는 것이 좋은 것 같다.(상대적으로 핵심적인 정보는 아니므로, 필터링 조건에서는 제외)

  • 업무상 시간과 장소의 제약이 없는 편이다.

-> 별도의 지역 정보가 필요하지 않다.

사용자의 특징

  • 연령대 : 다양하다.

연령대는 다양하지만, 기본적으로 직무가 개발자이다 보니 UI 에 친숙한 편이라고 생간한다.

따라서 UI 적인 제약사항은 크게 없을 것이라고 예상한다.

  • 글보다는 코드로 보여주는 게 익숙하다.

글로 보여주기에는 한계가 있으므로 가장 잘 표현할 수 있는 코드 일부로 보여주기

한 줄의 코드를 설명하기 위해서는 긴 글을 쓰는 수고와 그 긴 글을 읽는 노고가 필요할 수 있음

코드 하나가 더 많은 뜻을 내포할 수 있음

  • 오프라인보다는 온라인 커뮤니케이션이 편하다. 온라인 커뮤니티 활동을 좋아한다

프로젝트를 하지 않더라도 본인의 성향과 맞는 다양한 개발자들과 커뮤니케이션을 하고 싶을 수 있지 않을까?

문제점

  • 현재 대부분의 플랫폼은 수요자 중심으로 프로젝트에 대한 인원을 모집하고 지원자가 지원하는 형식이다.

우리는 등록자 중심에서 스스로가 인재풀을 등록하고 모집자가 원하는 인재를 찾을 수 있다.

  • 현재 대부분의 플랫폼들은 프로젝트가 어느정도 구체성을 띈 이후에 참가자를 모집하고 있어 모집에 진입장벽이 있을 수 있다.

우리는 마음맞는 사람들을 찾는게 먼저기 때문에 현재 프로젝트 유무와 상관없이 파트너를 구할 수 있다.

주요 기능

  • 등록자 프로필(CRUD)
  • 등록자 프로필 리스트

부가 기능

  • 메시지를 주고받는 기능, server sent event(optional)
  • 모집 공고 리스트(optional)
  • 취향 테스트(optional)
    • MBTI 와 비슷한 개발자 성향 테스트
  • 내 스타일이야(optional)
    • 동일한 주제에 각자의 코드를 적음으로써, 서로의 스타일을 확인할 수 있는 기능
    • ex. 실행했을 때, 하트가 나오게 하라
  • 같이 프로젝트를 진행한 사람 평가 기능(optional)
    • ex. 당근마켓 온도

2. 상세 설계

2.1 제공 플랫폼 선정

2.2 주요 기능 구체화

1) 등록자 프로필(CRUD)

  • 회원 기능
    • 회원 등록, 로그인
      • Google, Github : 보안적인 부분을 신경쓰지 않아도 된다.
      • 회원을 구분하기 위한 필수 정보(ex. Github nickname)만 뽑아오는 걸로
    • 프로필 수정
  • 프로필에 들어갈 내용
    • 기술 스택
    • 본인 스타일의 코드
    • 작업 시간대
    • 작업 형태
    • 이메일
    • 필수 요구 사항(텍스트)
    • 프로필 사진(optional)
    • 소개글(optional)

기술 스택을 프로필에 입력할 때, 항목들을 마련하고 그 항목을 클릭해서 선택하도록

기술 스택을 선택할 때, 우선 순위를 정할 수 있도록 한다.

코드 입력창은 문법을 구분할 수 있으면 좋을 것 같다.

기본적인 코드를 제공하고, 자신의 스타일대로 수정하게 할까?

처음부터 끝까지 다 작성을 해도 되고,

만약 기본적인 코드를 제공하는 언어가 없으면, 본인이 언어를 직접 적고 쓰는 걸로

2) 등록자 프로필 리스트

등록자 프로필 그리드뷰로 보여주기

메인 목록 리스트(1depth)에 노출되는 필수정보 -> 로그인 불필요

상세 화면(2depth)에 노출되는 필수 + 부가정보 -> 로그인 필요

필수 정보

  • 작업 형태
  • 작업 시간대
  • 필수 요청 사항
  • 기술 스택(우선 순위 순으로 보여준다, 3개 이상은 ... 으로)
  • 좋아요 버튼

필터 기능

  • 필터 1 : 프론트 vs 백 vs 안드로이드 vs ios
  • 필터 2 : 기술 스택(프레임워크, 라이브러리) + 언어
  • 필터 3 : 본인이 '좋아요' 를 선택한 프로필
  • 필터 적용 방식 : AND(&&) 조건

2.3 Description 작성

figma 링크

얼리버드

프로젝트

개발일지

스프린트 계획

멘토링

데일리 스크럼

데일리 개인 회고

위클리 그룹 회고

스터디

Clone this wiki locally