[과제 안내]
안녕하세요! UPF와 함께하는 프로젝트의 첫 여정은 어떠셨나요? 
이번 과제는 지난 과제에 담긴 계획을 바탕으로 기획, 디자인, 설계를 통해 프로젝트 구체화를 돕는 과제들입니다.
저희가 제안하는 과제를 수행하다 보면, 점점 더 목표에 가까워지실 수 있을 겁니다!
이번 과제는 지난 과제에 담긴 계획을 바탕으로 기획, 디자인, 설계를 통해 프로젝트 구체화를 돕는 과제들입니다.
저희가 제안하는 과제를 수행하다 보면, 점점 더 목표에 가까워지실 수 있을 겁니다!여러분이 과제로 공유해 주신 내용을 [UPF 2022SS 팀 정보]에 업로드해주시면 포트폴리오나 외부 소개자료로 활용될 수 있게 아카이브 됩니다! 자세한 아카이브 방법은 act.3 활동 안내를 참고해 주세요.
* 아마 이미 서비스를 진행하는 팀들이거나, 다른 커뮤니티에서 활동하셨던 분들은 이번 과제와 동일한 작업물이 있을 수 있습니다. 그렇다면 해당 내용을 조금 더 다듬어서 페어링 시간에 공유해 주세요!
[과제 제출 방법]
페어링 시간에 페어팀과 공유될 수 있는 NOTION, Google Docs, PDF, 기타 링크로
세 번째 활동 날짜인 4월 9일 토요일 오후 1시까지 Discord 팀 페어링 채널에 올려주세요.
제출된 자료는 페어링 시간에 페어팀과 이야기하는 소재가 되므로 신중히 작성해 주세요!
* 관련 문의는 언제든지 upf-question 채널에서 받고 있습니다. 사소한 거라도 괜찮으니 편히 질문해 주세요
* 과제 수행 Tip: 이전시즌 [팀 정보]의 'UPF에서 수행한 과제' 탭을 확인하면 과제 족보를 확인할 수 있습니다.
[과제 상세]
1. 팀 프로젝트 일정 리뷰 및 목표 다듬기 (필수)
act.1 OT 과제로 ‘UPF 참가 목표’를, act.2 과제로 ‘일정 산출 및 간트차트 작성’을 제출하셨을 텐데요.
두 가지 과제를 현재 시점에서 다시 한 번 살펴보고 좀 더 현실적으로, 구체적으로 다듬어주셨으면 합니다!
- 제출 목록
1) 구체적인 정량,정성 목표
2) 최신화된 일정 또는 간트차트
‘UPF 참가 목표’ 과제는 정량적 목표와 정성적 목표 두 가지를 구분해서 작성을 부탁드렸습니다.
그런데, 정량적 목표와 정성적 목표가 잘못 구분되어 작성됐거나 정량적 목표가 UPF를 진행하는 4개월 동안 달성하기에는 어려워 보이는 사례들을 확인했습니다.
두 가지 목표를 뚜렷이 구분하고, 현실적인 목표로 재설정을 부탁드립니다!
정량적 목표의 경우, 단계별로 달성할 수 있도록 페이즈를 나누는 것도 추천드립니다.
UPF 참가 목표 예시
[정량적 (수치화할 수 있는) 목표]
앱 스토어 출시 후, 30명의 유저 만들기 or 오가닉 유저 10명 만들기
웹 배포 후 일별 사이트 방문자 수 100명 이상
업데이트 버전 적용 후 유저 리포트 10개 받기
앱 누적 다운로드 100회 이상
초기 로딩 속도 2분의 1로 줄이기 [50s -> 25s]
[정성적 (수치화할 수 없는) 목표]
기존 유저 리포트 결과를 바탕으로 UI/UX 개선하기
백엔드 기술 스택을 Django에서 Node.js로 변경하기
QA까지 원활하게 이루어질 수 있도록 테스트 서버 구축하기
TDD 개발 방법론 도입하여 개발 방식 고착화하기
JavaScript
복사
‘일정 산출 및 간트차트 작성’ 과제를 통해 UPF를 참여하는 4개월 동안의 계획을 수립하셨을텐데요.
목표가 달라지고, 변동이 생기면서 일정에 변경해야 할 부분이 있을 것 같아요.
(지금까지의 일정을 못 지켰을 수도 있고...)
태스크를 더 작게 쪼개고, 일정을 구체화한다면 계획을 더 자세히 세울 수 있으실 겁니다.
너무 추상적이라는 생각이 들어 어려우시다면, 아래와 같이 생각해 보시는 걸 제안드릴게요!
혹시 지난 act.2의 Session에 원지혁 연사님께서 하신 말씀을 기억하시나요?
- 계획한 일정을 맞추지 못한다면, 우리가 잘못한 것이 아니라 예상을 잘못한 것이다.
- 회고할 때, “일정을 지키지 못했을까?”가 아니라 “왜 일정 산정을 잘 못할까?”를 회고하라.
- 프로젝트를 시작하기 전에, 발생 가능한 불확실성(예상치 못한 학습 기간, 통합에서의 오류, 타 파트와의 협업 등)들을 정확하게 리스팅해야 한다.
- 일정 예상이 힘든 이유는 기능이 많기 때문이다. 그러므로 예상 가능하게 기능을 작게 쪼개고 끊어내서 완성한 후에 연결하는 것이 좋다.
이 조언들을 기억하면서
1. 지금까지 프로젝트를 진행하셨을 때, 계획한 일정에 얼마큼 도달해왔는지
2. 현재 팀의 상황을 보았을 때 해당 태스크에 불확실성을 반영한다면, 일정이 어떻게 변경될지
를 고민해 보는 것도 좋을 것 같아요. 이처럼 프로젝트의 목표와 일정 산출을 다듬어가신다면, 더 명확한 고도화 목표를 완성하고 이뤄나가실 수 있을 거예요!
아래는 애자일 방법론에 많이 활용되는 스프린트 목표 설정에 대한 참고 자료입니다. 프로젝트를 진행하면서 스프린트를 설정하는 것과 이번 과제로 일정 산출하는 것은 조금 다르지만, 일정을 정확하게 예상하려는 최종 목적은 동일하기 때문에 한 번 읽어보시는 것을 추천드려요.
[일정 산출 및 간트차트 작성 관련 참고자료]
- [스크럼 모범 사례] 스프린트 목표 설정
- Sprint Goals — What Do They Really Need (With Examples)
2. 유저 스토리보드 작성 / 기획 (선택)
스토리보드란 보는 사람이 스토리의 내용을 쉽게 이해할 수 있도록 주요 장면을 그림으로 정리한 계획표를 말합니다. 웹/앱 기획에서 정의하는 일반적인 화면 스토리보드가 아닌 유저 관점에서 서비스 플로우를 살펴볼 수 있는 유저 스토리보드를 작성해 주세요.
이전 과제인 '페르소나'와 이어지는 유저 스토리보드(UX 스토리보드) 과제를 진행하며 전반적인 사용자 경험을 이해하고, 서비스의 존재 이유를 스스로 되돌아보는 시간을 가져보길 기대합니다.
여러분이 설정한 페르소나를 통해 사용자가 어떤 상황에서 서비스를 이용하게 될 것인지 생각해 봅니다.
•
서비스 이용 경험이 사용자의 삶을 어떻게 바꿀지
•
서비스 이용 경험 과정에서 사용자가 어떤 기분을 느낄지
위의 두 가지를 유념하여 유저 스토리보드를 작성해 주세요!
3. 와이어프레임 작성 / 디자인 (선택)
이름 그대로 철사(wire)로 틀(frame)을 만드는 과정으로, 화면 단위의 레이아웃을 설계하는 작업입니다. 의사소통 관계자들과 레이아웃을 협의하거나 서비스 흐름을 공유하기 위해 사용하며 UI, UX 설계에 집중되어 있습니다.
손 스케치로 초안을 만들고, 흑백 점/선/면을 활용해 간략하게 화면을 그리고 레이아웃을 잡아 페이지를 점검합니다. 컬러, 폰트, 이미지 등의 디자인 요소를 배제하고 흑백, 기본서체, 박스를 활용해 작업하는 것이 일반적입니다.
와이어프레임을 작성해보며 유저 스토리에 따라 기획된 기능들의 흐름이 어색하지 않은지 점검해 봅니다.
위와 같이 서비스의 UI 구성과 이용 흐름을 와이어프레임 안에 담아주세요!
4. 디자인 레퍼런스 조사 / 디자인 (선택)
서비스 와이어 프레임을 만들다 보면 디테일을 채워야 할 지점에 도달하게 됩니다. 이럴 때 참고할 수 있는 레퍼런스가 있다면 아직 완성되지 서비스의 모양을 예상해 보는 데에 큰 도움을 받을 수 있습니다. 레퍼런스 조사의 방향성을 설정하여 정리해 보는 건 어떨까요? 단순 정리가 아닌, 레퍼런스를 조사를 통해 서비스에 녹여낼 수 있는 인사이트를 발견할 수 있는 기회가 되었으면 좋겠습니다.
- 우리 서비스와 가장 비슷한 디자인 레퍼런스 1가지를 선택한다.
- 색감이 가장 비슷한
- 기능이 가장 비슷한
- 레이아웃이 가장 비슷한
- 유저 플로우가 비슷한
- 해당 레퍼런스의 어떤 부분이 우리 서비스의 디자인과 가장 비슷하다고 생각하는지?
- 우리 서비스에 디자인 레퍼런스를 참고해 녹여내거나 개선할 점이 있는지?
출처: WWIT / 메인페이지
핀터레스트, 노션, 구글 독스를 이용해 조사한 자료를 폴더 또는 카테고리로 분류하고 정리해보는 시간을 가져봅니다.
5. 서비스 DB 설계 / 개발 (선택)
여러분의 서비스는 DB가 필요한 서비스인가요?
단순한 토이 프로젝트가 아니라, 진지하게 운영까지 생각하고 있으시다면 서비스의 DB는 정말로 중요합니다. DB는 한 번 정하고 나면 수정하기가 난감한 컴포넌트이기 때문에 매우 신중하게 결정해야 하기 때문입니다. 중요한 컴포넌트이기 때문에 어떤 과정을 거쳐서 의사결정을 했는지 백그라운드를 기록해두면 새 팀원이 합류했을 때 백그라운드를 이해하기 수월해집니다. DB에 관련된 질문을 몇 가지 질문을 통해 개발팀이 스스로 답하고 기록해 보는 시간을 가져봅니다.
- 어떤 DB인가요? 왜 해당 타입을 선택하셨나요? (RDB, NoSQL, GraphDB)
- 어떤 DBMS를 사용하고 계시나요? 왜 해당 DBMS를 선택하셨나요? (ex: SQLite, MySQL, PostgreSQL, MariaDB, MongoDB, Firebase, Neo4j)
- 클라우드 서비스인가요? 가격은 얼마인가요? SLA가 있는 서비스인가요?
- 어느 정도 성능이 나오나요? 1,000명의 유저가 사용한다고 가정한다면 병목이 예상되는 테이블이 있나요?- ERD를 그려보셨나요? 서비스 DB 구조 중 특이하다고 생각하는 부분이 있으신가요?
위 질문에 대한 답변을 기록해보고 정리해보세요!