🔥 7월 8일 회의

유강스 조 편성

• 프론트, 백 각 2명씩 총 4인조로 2팀 결성!
  • 테, 아, 쑤, 바
  • 산, 커, 에, 올

커비의 제안: 개발 외적인 이야기를 하는 시간을 갖자

• 사유: 서로 친해지면 좋겠다.
• 구체적인 제안
  • 매주 수요일 점심을 같이 먹자 [O]
  • 매일 점심 먹고 나서 약 10분간 아이스 브레이킹 [O]
    • 1시 20분 ~ 1시 30분
      • 단, 위 시간은 대략적인 제안임. 유동적으로 바뀔 수 있음
  • 간단한 페어 매칭 -> 마니또 [X]

서기 부담 줄여주기 프로젝트

• 사유: 서기가 기록하면서 의견을 내고 회의를 따라가기가 어렵다.
• 제안
  • 서기를 위해 회의를 조금씩 끊고 정리하는 시간 가지기
  • AI + 녹음 이용하기
  • 팀 노션으로 실시간 기록하기
  • 캔버스에 기록 -> 팀 블로그에 업로드 -> 이후 캔버스 초기화 [O]

각 분야별 기술스택 픽스 및 환경설정 일정

• 내일까지는 기획을 최대한 픽스 [O]
• 수요일에 기술스택 픽스 [O]
  • 선택한 이유 작성하기 [O]
• 목요일에 환경설정 시작하기 [O]
• 이번 주에 끝내야 하는 다른 일들 (기획 이후)
  • 사이트 디자인 회의
  • 로고 정하기

슬랙 구조 개선

• 분야별로 채널 파기

기획 회의

플랫폼

• 반응형 웹

약관

• 이메일 수집 [O]
• 사용자 정보 수집 => 코치들에게 조언 구하기 [O]
  • 분야, 현재 재직 상황(학생, 취준생, 현직자 등) 정보 등
  • 목적
    • 사용자 추적 -> 그에 따른 기능 개발 등 추후 확장 용이
    • 사용자가 우리 서비스를 사용함으로써 얻은 이득을 보여줄 수 있음
      • 예) 타인과의 비교 기능 제공 가능
    • 위 이점을 통한 사용자 유입 및 이탈 방지 효과
  • 이슈
    • 개인정보를 다루는 것에 대한 문제
      • 단, 캐주얼한 정보라 심각한 논의가 필요하지는 않음
      • 필요한 개인정보 목록
        • 재직 상황 (학생, 재직자(+연차), 구직자)
        • 직무 (AI, 백, 프론트...)
        • 우리 서비스를 사용하는 이유, 기대되는 것
    • 현재 상황에서 필요한 기능인가?
    • 정보 수집을 통해 이루려는 목적이 뚜렷하지 않음

요구사항

• 숫자 제한 (공백 포함)
  • 한 줄 소개: 0 ~ 80자 [O]
    • 배너에 한 줄 소개가 필요한 경우 default 문구를 띄우는 등으로 활용해보기 [O]
  • 레포지토리 추가 설명: 0 ~ 50자 [O]
  • 상위 키워드 노출 수: 일단 최대 3개
  • 리뷰어가 리뷰이에 대해 선택할 수 있는 키워드 수: 1 ~ 5개 [O]
  • 상위 리뷰 노출 수: 최대 3개 [O]
    • 레이아웃 후보
      • 슬라이더 + 모달
      • 해당 리뷰를 눌렀을 때 아래로 내려가게끔
      • 깃허브 참고
• 전체 레이아웃 => 추후 더 논의하기 [O]
  • 상단 탭으로 카테고리 관리
    • 프로필 일부(프사, 한줄소개 등)를 탭 이동 시에도 유지할 것인가?
    • 탭으로 어떤 카테고리들을 제공할 것인가?
  • 프로필 화면
    • 사진 참고
• 그룹 레포지토리에 띄울 정보
  • 프로젝트 진행 기간 [O]
    • 형식: n년도 x월
    • 리뷰이가 기입
  • 프로젝트 소개 [O]
    • 코치에게 우테코 크루들의 정보가 어떻게 넘어가는지 묻기 [O]
    • 목적: 레포지토리 이름에 이 프로젝트가 무엇인지는 드러나지만, 어떤 상황에서 개발했는지(어떤 회사에서 개발한 프로젝트, 학교 동아리 프로젝트 등)
    • 리뷰를 보러 들어갔을 때 리뷰 자체가 궁금하지 어떤 프로젝트에 대한 리뷰인지까지 궁금하지는 않을 것 같다.
    • 입력해야 하는 사항이 많을수록 사용자 부담이 커질 수 있다.
    • 자동화할 수 있는 부분이 있지 않을까?
• 프로젝트 그룹에서 분야별 추가 그룹을 생성할 수 있게 만들 것인가? [X] => 부가적인 기능이므로 추후 다시 논의
  • 필요성
    • (긍정) 같은 분야에 있는 팀원과 다른 분야에 있는 팀원을 분리해 리뷰를 보고 싶다.
    • (부정)
      • 리뷰를 쓸 때 소프트, 개발 스킬을 나눠서 리뷰하므로 굳이 분야를 나눠야 하는가?
      • 기입해야 하는 정보가 늘어난다.
      • 리뷰가 늘어남에 따라 리뷰어의 직무 정보가 같이 기입되어 있으면 정보 과부하가 올 수도 있을 것 같다.
  • 직무 선택 방식
    • 처음에 받은 정보로 구분 -> 풀스택 개발자와 같이 분야가 고정되지 않은 사람은 사용하기 어려움
    • 직접 기입
      • 리뷰어가 기입
      • 리뷰이가 기입
    • 추상화: 리뷰이와 같은 분야에서 일한 사람과 그렇지 않은 사람으로 나누기
• 리뷰 활성화 유효기간 [O]
  • URL 유효기간: 7일
  • 시작: URL을 생성한 시점
    • 해당 그룹에 늦게 팀원을 추가한 경우
  • URL 유효기간 내에서는 수정이 자유롭지만, 이후에는 수정 불가
  • URL 유효기간 중에는 등록된 모든 리뷰어가 자신의 리뷰를 approve해야 리뷰이가 리뷰를 볼 수 있음
  • 유효기간 만료 후에는 모든 리뷰어의 approve 없이도 나머지 리뷰를 볼 수 있음
• 그룹에서 리뷰어 지정하기 [O]
  • 레포지토리 연동하기, 깃허브 유저 검색하기 모두 적용
  • 리뷰어는 최소 1명 이상이어야 함
  • 최대 리뷰어 제한은 추후 논의
• 리뷰 숨기기 [X] => 추후에 논의
  • 리뷰는 숨길 수 있지만 데이터(통계)에는 반영됨
  • URL 만료 이후에는 삭제 대신 숨기기만 가능
• 수정, 삭제 [O]
  • URL 만료 이전에는 수정 및 삭제 가능
  • 단, 리뷰이는 받은 리뷰를 삭제할 수 없음
  • 그룹 전체 삭제는 가능
    • 그룹 전체 삭제 -> 해당 그룹에 속한 리뷰 모두 삭제됨
  • 개별 리뷰어를 추가 및 삭제할 수 있음
• 탈퇴 회원 [X] => 추후에 논의
• 임시저장 기능 [O]
  • URL 만료기간 전에는 임시 저장이 가능하나 만료 이후에는 해당 내용이 자동으로 제출됨
  • 임시 저장 버튼을 누른 경우 위 내용을 사용자에게 안내
• 리뷰 정렬 => 내일 이야기
  • 프로젝트 시작일 최신순
  • 리뷰 작성순