CODE_PLAN

기획에 필요한 해상도관련 공부를하면서

해상도때문에 사용자가 불편하게 보이거나 사용에 불편함이 생길수 있다는것을 깨달았습니다.

- statcounter 라는곳에서 나라마다 웹사이트에서 해상도를 몇으로 쓰고있는지 확인가능합니다.

(신규사이트를 제작하면서 어떤 통계데이터가 필요할때 statcounter 추천)

- 개발자도구에서 웹사이트에 대한 해상도설정을 좀 더 정확히 할수있어서 추천합니다

- 기존에 운영하던 사이트를 새롭게 리뉴얼하는 경우에서는 그동안 축적되온 통계데이터를 참고하는게 좋습니다.

-> 이때 GA(Google Analytics)에서 브라우저 해상도의 통계 확인가능 

실전 tip) 브라우저의 해상도 확인하는경로는 잠재고객-> 기술-> 브라우저 및 운영체제 

최초로 어떤 브라우저를 많이사용하는지 볼수있음, 화면 해상도를 클릭하게되면 7일간 방문했던 유저들의 해상도 통계를 확인할수있습니다. (desktop/모바일 둘다 확인가능한데 웹사이트를보고싶다면 모바일을 뺴고 보는것이 가능합니다) 

방법: 보조 측정기준 -> 자주 사용됨(기기카테고리) -> 고급 -> 기기 카테고리에서 desktop 검색후 + (포함) 밑에 적용을

누르면 desktop만 볼수있습니다. 

-> 결과적으로, 해상도의 기준을 세울수있습니다.

(통계로 나오는 0.7% 이정도는 버려도됨)

참고> 기획자 데이먼님 

tip) 파워포인트/노션/엑셀/스프레드 시트 에서 본인이 편한방식으로 정리하기 

기획자가 서비스를 설계하다보면은 정책을 결정해야되는 경우가 많습니다.

파워포인트같은곳에 한눈에보기 쉽게 표로 적어놓고 비교하면 이해하기 쉽습니다.

1. 회원가입 옵션 

ex)

1안 이메일인증 2안 휴대폰인증  3안 이메일+휴대폰인증 

방식

장점

단점

2. 결정을 위한 판단 기준

ex)  배달서비스를 만든다고하면은 

1. 주문확인 및 배달을 위해 정확한 고객 연락처 필요

2. 40.50대도 쉽게 가입할 수 있어야함

3. 신규 가입자 프로모션을 적극 활용하기위해 중복 가입자를 필터 해야함

참고> 기획자 데이먼님

Summary

- IA는 정답이 없습니다. 어떻게 해야되다는것이 없기에 데이먼님 IA설계를 참고하였습니다.

- SI, 에이전시여서 산출물이 필요한경우에는 산출물을 작성할수있습니다. 

Product 전체 규모 파악 

짜임새 있는 Product 구축

데브옵스/에자일 방식으로 바로 피드백받고 바로 product 만드는경우에는 IA가 필요없을수있음

근데 프로젝트 사이즈가 크고 협업하는 관계자가 많아질수록 IA가 필수적으로 필요하다고 생각하면됩니다

참고> 기획자 데이먼님

애자일 조직에서 주로 사용하는 프로덕트 매니저의 문서 살펴보기

=> 주로 Word로된 문서를 많이작성  ( 이럴때 많이 사용하는게 EPIC/USERSTORY 기반으로 작성)

Title(ex.호텔 예약관리 시스템)= 테마개념

대단위의 묶음들을 에픽이라함 

유저스토리는 고객의 니즈를 바탕으로 고객이 무엇을 원하는지 기능을 문장으로 정리한것 

스토리보드

- 해외에는 거의없고 국내 에만 거의있는 형태의 문서

(UI/정책/기능명세 등이 담기게 됩니다)

기획자가 스토리보드를 만들고 

디자이너가 디자인/ 개발자가 개발 

그래도 디자이너, 개발자는 주로 제작단계에 참여하게됨 

- 중간중간에 기획자가 기획리뷰를 하긴하지만 그때는 주로 이제 기획안에 대해서 가능여부와 궁금한점을 물어보는 

형태로 끝나는경우가 많다.

- PM, PO는 고객의 목적, 행동 <= Needs 를 주로 정리

Epic , UserStory 

디자이너 - 개발자 - PM, PO 설계 함께 진행 , 제작에도 모두가 참여 

cf) 미디엄-> userStory 검색후 내용확인가능

 프로덕트 매니저는 UI를 직접 그리지 않고 고객의 니즈를 바탕으로 

표 처럼 글로 유저스트로리를 작성함

-> 아이데이션 -> 다음단계 형식 

유저스토리를 달성하기 위해서 필요한 항목들을 정리 

-> Accpetance Criteria (완료기준or통과기준) == 줄여서 AC

Epic단위로 보게되면 내용들이 많기때문에 문서만으로 정리가

잘 안되는경우가 있음 

Flow chart가 필요한경우가 있음

=> 이때 EPIC과 유저스토리 사이에 넣어주면 좋다 

에픽을 요약한 플로우차트 

참고> 기획자 데이먼님

잘 알려진 IT 프로젝트 방법론으로 

워터폴/에자일방법이 있습니다. 

워터폴 방식 : 프로세스에 따라 단계적으로 구현하는 방식 

에자일 방식 : 최소단위 제품(MVP)을 빠르게 출시해서 고객 피드백을 바탕으로 제품을 개선하는 방식

프로젝트 성격에 따라서 워터폴이 적합한경우/ 애자일이 적합한경우가 있습니다

금융 플랫폼, 운영체제와 같이 한번에 완제품을 출시해야 하는 경우- 워터폴 방식 적합

고객을 사로잡아야 사업의 성패가 결정되는 프로덕트의 경우 - 애자일방식 적합 

EX) Backlog 

1. 경영진과 커뮤니케이션에서 나오는 Roadmap

2. 개발하다 나오는 내부이슈, 기술부채 

3. 고객 요구사항

-> 전체적인 일정관리 

cf) 많은 회사들이 Atlassian JIRA 로 Task 를 관리하고 Confluence를 wiki로 이용하지만 

다르게 Notion과 Asana를 사용할수 있습니다. 

- 빠르게 출시하다보면 -> 기술부채가 존재할수있습니다.

Asana에서 

이 단계에서 발생하는 모든 task들은 Inbox에 정리하고

검토필요한것 -> Pending에 올려서 정리(정리,분류,그룹화)

product 관련한 모든 요구사항은 backlog에서 관리하게됨 

요구사항을 작업을 할수있는 형태로 변이시키는것이 pending단계 (정리, 분류, 그룹화)

- Inbox에 모든 요구사항들을 담고있음 

=> 새로운 스프린트로 만들기 

- Ready단계에 정리된 task 모아둠 

-Asana의 weekly라는 공간에 진행중인 업무들을 정리함 

=> 무슨일 하고있는지 한눈에 파악하기 쉽다 

- 모든 우선순위는 목표에 의해서 결정함 

PM이 되면 어려운점 중하나  -> 여기저기서 요구사항 발생 / 우선순위 정하기가 어려움 

백로그 요구사항 -> 목표에 대입 -> TASK를 만들어서 관리

- 기간이 있는 TASk를 sprint로 보고있음 (평균2주, 1주~1달경우도 있음 ), 기간을 유연하게 관리

- sprint 만들때 옆에 왜하는지 같이 명시 

- 추천 로직 ( 빠르게 생성-> 코드 불안, 확장성 떨어짐) => 기술부채 해결, 유연성 확대 

=> 확장성 고려 

- 급하게 진행된느거 (operation section = ops)에 작성관리 (20%)

=> 미룰수도 있음 ( 항목으로 sprint를 만들어서 작성가능) 

- sprint에 가급적이면 업무비중 80% 유지 

회고(피드백을 주고받는 문화) 

sprint가 끝나고나면 sprint에 참여했던 멤버들이 

1) 각자 잘한점/개선할점 각자정리 ( 이때 상대눈치보단 무조건 1개라도 개선점 적는게 중요) 

2) 회고 미팅( 내용 한번더 정리) 

3) 최종 정리(최종적으로 회고미팅에서 나왔던 이야기들을 다 정리해가지고 전사적으로 공유함 

참고>유투브 기획자 데이먼 

-리전이란 화면에서 내모상자를 나타내며

전 세계에 그 하나 이상의 데이터 센터가 있는 물리적인 위치를 말합니다.

- 하나의 리전안에는 여러가지 가용영역 availability zone = az로 표기됨 , 즉 여러가지 az로 구성이 되어있습니다.

az는 데이터 센터라고 생각하면 됩니다. -> 더 안정적인 서비스 운영가능  = 고가용성라고함(백엔드 서버에서 중요)

- aws에서 서비스를 만들때 리전을 선택해야 해줘야하는데 가까이 있을수록 당연히 더빠릅니다

but 특정한 서비스들은 Region 별로 되는게 아니라 Region 선택없이 해야할것들이 있습니다.

이런 경우에는 강제로 미국 NorthEast로 선택해서 해야하는 경우도 있습니다. 

- Region은 그 지역을 이야기하고 이 안에 여러개의 AZ가 있을수 있습니다. 

- 특정지역(ex.서울)에서 되는 서비스도 있고 안되는것도 있다

(AWS Regional Services List 에서 확인가능)

- 만약 서울에서 개발을 하더라도 일본사람들을 위해서 만들고있다-> 도쿄or 일본에있는 데이터 센터를 사용해줘야함
미국이 고객이다하면 미국에서 서비스를 배포해줘야 합니다. ( 사용자가 기준)

- Routes 53 처럼 DNS 서비스는 서울사용못하고 Global 서비스  

======

- IAM ( ==Route53 과 같은 글로벌 서비스)

액세스 권한 관리 

(User, Groups, Policies)

- 회원가입시 만들어진 계정 => Root Account 

사용/공유되지 않아야 한다. 

보안위험성이 존재 (카드정보 해킹등)

그러면 어떻게해야하냐면 =>  IAM에 들어오셔서  User와 Group을 만들어서 사용해야합니다.

- User/Group 만들어서 보완관리

- 최소한의 권한 원칙을 부여 

aws 키 깃허브에 올리지않게 조심해서 관리해주기 

목차 

- 히스토리 

- 메뉴구조 

- 화며목록 

설계 

- 프로세스

- 정책

- UI, 기능정의

- 마무리 표지

(감사인사) 

화면설계서나 스토리보드를 만들때 첫페이지는 표지로 시작 

같은 버전의 문서를 보는지 체크하는것도 중요 

메뉴구조- 프로젝트 사이즈 한눈에보기 쉬움 

프로젝트를 하게되면 information 아키텍처라는 포멧을 정리하게됨

IA

화면목록중 변경되거나 삭제되면 아에 행을 삭제하는게 아니라 시각화해서 표시해주는게 좋다

- 간단한 UI 몇개있는 페이지를 만들면 FlowChart를 작성할필요가 없다 

조금 복잡한 프로세스가 들어가게되면 FlowChart를 먼저 작성하는것이 좋다 

( 프로세스 - 평행사변형/ 분기 - 마름모/페이지단위(ex: 인증방식 선택-네모난 직사각형으로 표시) 

-비밀번호 찾기같이 입력폼이 필요한경우  -> 오른쪽에 UI에 필요한 필드들과 항목들을 정리하면 

이후에 UI 그릴때 굉장히 빠르게 그릴수있다

- 프로세스에 따라서 alert 메시지가 필요한경우가 있는데요 그럴땐 시각적으로 명확히 구분해서 표시하는것이 좋다

- 정책에선 앞에서 flowchart내용이 회원가입에대한 내용이면 정책도 회원가입에 대한 내용을 정리해주는것이 좋다

이때 어떤것을 선택했는지 비고란등에  ex) 4안으로 결정 이렇게 적어주면 커뮤니케이션할때 좀 더 명확하게 할수있다.

-유저 등급이 많을때는 권한정책을 정리하는것이 좋다 -> 표로 정리하면 굉장히 좋다

( 페이지단위 / 등급단위 / 페이지별 권한에 대해서 정리/ + 페이지에 따라서 기능이 없는경우 블럭처리를 해서 표시해주면 좋다) 

- UI, 기능정의단에서 개발자나 디자이너에게 설명이 필요할경우 별도의 공간에 표시해서 설명해주기도 한다

( 공통적인부분은 check point 로 빼서 적어주는것도 좋으며, 페이지와 관련된 아이디도 함께 적어주면 좋으며, 

페이지가 부족한부분은 따로빼서 정리해주는것이 좋다

ex) validation - 필수 입력항목/ 유효성 체크 => 개발자들이 알기쉽게 나타내기)

Axios의 Instance를 활용하면 API 요청에서 반복되는 구조를 줄이고 함수명을 통해 어떤 요청인지 직관적으로 파악할 수 있습니다

Instance의 핵심 개념은 기본 URL, 헤더, 시간 초과 및 기타 기본 매개 변수와 같은 미리 구성된 설정으로 인스턴스를 생성할 수 있다는 점입니다. 더 이상 API 요청을 만들 때마다 반복되는 설정을 지정할 필요가 없으므로 시간을 절약하고 코드를 효율적으로 작성할 수 있습니다.

2. Interceptor

Axios의 Interceptor는 요청이나 응답이 응용 프로그램에 의해 처리되기 전에 인터셉트하는 데 사용할 수 있는 함수입니다.

Interceptor를 활용하면 요청 또는 응답 데이터를 수정하거나 오류 또는 인증을 처리하는 데 사용할 수 있습니다.

NOTE

별칭 메소드를 사용하면 설정(config)에서 url, method 및 data 속성을 지정할 필요가 없습니다.

// axios() 사용 시

axios({
  url: '/user/12345',
  method: 'put',
  data: {
    firstName: 'Fred',
    lastName: 'Flintstone'
  }
})

// axios.put() 별칭 메서드 사용 시

axios.put('/user/12345', {
  firstName: 'Fred',
  lastName: 'Flintstone'
})

참고>

https://kimyouknow.github.io/fe/Axios%20Instance%EC%99%80%20Interceptor:%20HTTP%20%EC%9A%94%EC%B2%AD%EA%B3%BC%20%EC%9D%91%EB%8B%B5%20%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0

https://yamoo9.github.io/axios/guide/api.html#http-%EB%A9%94%EC%84%9C%EB%93%9C-%EB%B3%84%EC%B9%AD