행정학과와 논의해야할 사항

[seiyoon]

11/2 수업에서 논의한 사항

1. 로그인 -> 어렵다 -> 개선하는 방향
2. 매너온도 -> ?
3. UI 형태 개선 -> 복잡도 경감 아이디어
4. 화폐 소유권 이전 -> 감사 기능 / 모니터링 | 규정
5. 인프라 -> 운영 -> 규정 // 실제 운영팀이 사용하려면
6. 도움 선정 과정의 개선 (chat, tracking)

[seiyoon]

레벨(포인트) 기능을 도입하고 싶은데 몇 포인트 당 레벨이 올라가게 하고, 그 포인트는 어떨 때 지급하게 할 지

[Choi-Jiwon-38]

아래 내용 수업 이후에 다시 정리하겠습니다

등급


• 5개 정도가 좋을 거 같음


• 기존 아이디어처럼 날씨별로 등급을 책정하면 좋을 거 같음
- 발생할 수 있는 문제점:
 만약에 20을 기준으로 등급이 나누어진다고 하면 19, 20과 같은 경계선에 걸쳐있는 경우 차이가 나보일 수 있음.
 -> 당근마켓은 온도 및 소수점 표현으로 인하여 이 부분은 덜 할 것으로 생각됨.


• 사용자들이 0 ~ 100까지 수 범위가 가장 사람들에게 익숙함 -> 그대로 가져가는 것이 좋을 듯하다.
온도 자체를 그대로 가져가도 괜찮을 거 같음(당근 뿐만 아니라 사랑의 열매에서 사용 중, 체온이라는 단위는 모든 사람들에게 익숙함)

이름의 후보는 아래와 같이 나왔다 -> 성북 온도, 배려 온도, 마음 온도(구, 동 주민들끼리 나누는 것이므로~~)


• 상호평가를 식으로 작성하는 것이 좋을 거 같음.



• 포인트를 올릴 수 있는 수단과 그 가중치의 순위는 아래와 같음.
(상호평가, 대화 응답룰 <- 얘는 조금 어려울 거 같음, 출석 <- 미정, 게시글 업로드)
상호 평가(5할) > 타임페이 거래량의 비례(3할) > 게시물 작성(2할) > 출석(포인트.. 수급 문제로 가야할 것으로 보이기도 함.)

상호 평가를 중심으로 진행을 한다

위 두 가지를 
-> 성실도(친절도)
-> 응답률(응답 속도)

각각의 별점을 받도록 하여 반영한다.

(아예 모두 통합해서 별점 1개만 받도록 / 드래그 앤 스크롤 방식보다는 어르신들은 별점을 주면 좋을 거 같음.)

상호평가 내용은 상대방에게 굳이 전달될 필요는 없을 것으로 판단 -> 온도 계산 용으로 사용하면 될 거 같음.


• 매너 온도 반영 시점
즉각적으로 반영하면 사람이 특정될 수 있음.
갱신 주기를 따로 정한다.

해결해야 할 상황

• 등급별로 나누게 될 때, 그 바운더리에서는 어떻게 진행해야 할지 -> 등급 자체를 빼서 없애는 것은 어떤가.
• 세부적인 등급 나누는 기준

[parksunjin00]

3 UI 형태 개선 논의

합의된 사항

• 네비바 구성 교체, 도움말 토글 제공

• 글쓰기 흐름에서의 페이지 수 도움말 표시와 일반적인 사용자 경험을 고려할 때, 고령자층은 긴 스크롤에 더 큰 부담을 느낀다. →페이지를 3개로 분리 카테고리 / 활동 시작 및 종료, 소요 시간, 장소, 모집 인원 / 제목과 본문

• 시간 숫자 표기 24시 표기 스크롤을 어려워하심. 오전 오후를 따로 선택받고 12시 표기

쟁점

• 활동 시작과 종료를 따로 입력하지 않고, 시작 + 소요 시간으로 자동 계산한다면? 장점) 사용자의 입력 정보수 경감 이슈) 활동 시간과 실제 도움 시간의 불일치 고려 소요 시간 외 시간을 더 사용했을 때, 추가 송금에 대한 논의 필요

[seiyoon]

6 도움 선정 과정의 개선 에 대해 회의한 내용을 정리합니다.

문제점

• 댓글의 지원 버튼이 너무 작다.
• 지원하는 방식이 복잡하다. 한 번에 지원하는 방법이 있으면 좋겠다.
• 댓글이 실시간으로 업데이트 되면 좋겠다.
• 선정이 된지 안 된지 모르겠다.
• 선정이 된지 안 된지 알 수 없다. 지원과정의 간략화

논의한 사항

• 매칭이 완성되면 푸시 알림을 보내기로
• 수락과정은 단순하게 하는 게 좋을 것 같다는 의견에 모두 동의 (지원자 리스트로 지원자 선정)
• 신청과정에 간단한 신청폼 작성을 제안했는데 이에 찬성함. 도움제공은 20-30대가 많을 것으로 보아 신청과정이 복잡한 건 괜찮음
• 채팅 기능의 도입에 찬성 외부 채팅 서비스(ex. 오픈채팅방)를 제안했는데 앱 내에 채팅 기능을 넣는게 나을 것 같다는 의견 ⇒ 성과공유회 결과 주민들은 오픈채팅방을 잘 모르시고, 앱을 바꿔가면서 하는 거 복잡함을 느끼고 거부감이 있다고 하심

요약

• 기존 UI 관련해서 논의, 전체적인 플로우 수정하는 방향으로 회의 진행
• 채팅 기능을 도입하자
• 선정을 할 때 지원자의 선정 기준을 제시해줘야 한다. 방안 : 프로필 보기 프로필에 표기할 최소한의 정보 논의한 사항 : 이름, 나이, 성별, 활동기록

더 논의해야할 사항

• 도움을 요청할 때 타임페이 양을 자율적으로 줄 수 있게 할 것인가?

• 무조건적으로 기능 축소하는 것 보다는 교육하고 이해할 수 있는 방향을 추구하기로 (홍보팀의 역할이기도 함!)

[ssoree912]

5. 인프라 -> 운영 -> 규정 // 실제 운영팀이 사용하려면

문제

• 서비스를 운영하면서 생기는 문제점 다양성 이를 어떻게 받을 것인가
• 뱅크 팀, 커뮤니티 팀에서 발생하는 문제점이 각자 있을 것이며 이 문제점이 유저의 사용실수인지 시스템적 실수인지 유저는 구별해서 알려주지 않을것임
• 신고가 들어왔을때 신고에 대한 검증 절차, 모니터링을 어떻게 할것인가
• 운영팀에서 서비스관리를 위해 필요한 데이터 논의

논의결과

• 신고, 건의는 한번에 받되, 앱 자체가 구동이 멈추는 경우를 대비해 메일, 전화, 문자 등 상시 사용할 수있는 연락 수단 남기기
• 신고 내용을 한번에 받고 행정팀 내에서 문의 내용을 필터링 해주는 부서 생성, 이 부서에서 시스템 적 문제로 판명 나는 경우 시스템 운영자(소프트웨어팀)에게 전달
• 모니터링 방법 : 누적 신고개수, 채팅 기록으로 확인
• 운영팀에서 필요한 데이터 및 기능(어드민 개발에서 고려해야할점) : 신고기능, 채팅 기록확인, 누적 신고개수 확인, 해당 유저를 정지시키는 기능, 벌점제도

** 벌점제도의 경우 규정팀에서 만든 규정 내에 적힌 내용으로 유저 정지시키는 기준으로 사용될수도 있다고 함. 이에 대한 정확한 규정 작성은 계속 진행중

추가 논의 내용

• 어드민 화면 기획을 위해 운영팀에서 필요한 데이터 및 기능을 구체적으로 더 생각해봐야함
• 신고를 한번에 받는다면 어느 화면에서 신고를 받을지도 고려