녹호두

스파르타코딩클럽 엑셀보다쉬운 SQL (4주) 33기

1주차 - 수강일자 210920

기본

• 쿼리문 : 데이터베이스에 명령을 내리는것
  • CRUD 네가지 메인 액션이있지만 DB관련 직종이 아닌이상 R(read)만 제대로 하면 된다. 
  • 이번 강의에서는 R만 배우기로 한다.
• 테이블 : 시트
• 필드 : 컬럼
• 문자에는 '' 따옴표가 필수 / 또는 ""도 무방
• 숫자에는 '' 따옴표 미사용
• SQL은 대소문자를 가리지 않는다. 어떻게 써도 동일하게 인식

where절

• 같다 : =
• 다르다 : !=
• 초과 미만 : > <
• 이상 이하 : >= <=

조건

• 포함 : where 컬럼명 in (조건1, 조건2, ... )
• 범위 : where 칼럼명 between '조건1' and '조건2'
  • ex. between '2021-08-02' and '2021-08-08'
    => 08-02 ~ 08-07 출력. 이상 and 미만
• 패턴 : where 컬럼명 like '%naver.com'
  • '%d' d로 끝나는 
  • 'd%' d로 시작하는
  • '%d%' d가 가운데 들어가는
  • 'a%b' a로시작하고 b로 끝나는

기타

• limit # : #개만 출력하기 (where 절 이후에 사용)
• distinct(칼럼명) : 칼럼명의 중복데이터는 제외하고 (select 절에 사용)
• count(칼럼명) : 칼러명의 갯수세기 (select count(disntinct(칼럼명)) 으로 주로 사용)

애자일 조직 제품 관리자의 고객중심 문서 작성 가이드! (에픽, 유저스토리)

https://youtu.be/Z6tgjS3cMcA

case 1 - 기획자

• 비즈니스 관계자 or 고객으로부터 요구사항 수집
• → 기획자가 분석, 설계
  • 이때 설계된 문서를 "스토리보드"라고 부름 (국내에만 있음)
  • 스토리보드에는 ui, 정책, 기능 명세 등이 담기게 됨
• → 이를 바탕으로 디자이너, 개발자가 작업
  • 디자이너와 개발자는 주로 제작 단계에 참여

# 스토리보드

좌) ui 우) desc

case 2 - pm, po

• 비즈니스 관계자 or 고객으로부터 요구사항 수집
• → po, pm도 분석을 함. 하지만 설계를 하진 않고 고객의 목적과 행동을 정의 (왜 쓰고 뭘 불 편해하고 뭘 원하는지, 니즈) = 니즈를 중심으로 정의
  • 이때 작성된 내용을 Epic, User story라고 함
• → 이 내용을 바탕으로 디자이너, 개발자가 소통해가면서 설계를 함께 진행하고 제작에도 모두 함께

# epic, userstory

문서로 구성

• 테마가 최상단에 가장 크게
  • 에픽
  • (flow chart)
    • 유저 스토리
      • 누가 무엇을 위해서 어떤 기능을 원한다. (유저의 관점에서 작성)
      • acceptance criteria (인수기준)
        • 제품이 최종 사용자 혹은 시스템이 제시하고 있는 요구사항을 만족하고 있는지를 판별하기 위한 기준
        • 인수조건의 가장 큰 특징은 철저하게 사용자의 관점에서 제품의 기능을 정의한다는 것입니다
          • 테스트

→ pm 은 ui 가아니라 위와 같은 문서를 주로 작성한다.

→ 스토리보드는 ppt로 제작해 검색이 어려운데 이런 건 위키로 되어있어서 검색이 용이하다.

→ 유저 스토리는 고객 입장에서 고객이 원하는 것을 고민하는 것으로 서비스 기획과 view(관점)이 많이 다르다.

제품 관리자(PO,PM)의 Product 일정관리 노하우!

https://youtu.be/gg56Z_LlXvE

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

애자일 : 최소단위제품MVP를 빠르게 출시해 개선하는 방식

->  프로젝트 성격에따라서 워터폴/애자일 둘 중 하나가 잘 맞을 수 있음

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

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

backlog에 1) 로드맵 2) 내부 이슈, 기술 부채 3) 고객 요구사항 기록

- 고객 → 사용성 개선, 신규기능 추가, 버그

- 개발 → 우리만 아는 내부 이슈, 기술 부채

- 경영진 → 비즈니스 관련 task

* 기술부채 : 현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영 / 기술적으로 해결되어야할 문제들을 뒤로 미루고 비즈니스 문제를 해결하는 것을 앞당기는 것

backlog page

Inbox → pending (요구사항 정리, 분류, 그룹화 → new sprint 형성) → ready (정리된 task 모아둠)

weekly page

• goal - 모든 task는 목표를 기준으로 함
• in progress
  • backlog를 고르게 분배해 In progress를 잘 만들어야 한다.
  • 담당자 배정, 업무 진행 시 pm이 우선순위를 결정하기 때문에 1) 로드맵 2) 내부 이슈, 기술 분배 3) 고객 요구사항 세 가지의 밸런스를 잘 맞춰야 한다. 단, 회사와 협의한 goal 또한 하나의 기준이 되어야 한다.
  • → 중간에 끼어서 스트레스받는 경우가 많긴 하다.. 단, pm이 잘못 결정하면 프로덕트가 산으로 가는 경우가 많다.
  • 기재 시 각 과업마다 사용하는 이유를 함께 기재
• 여러 개의 sprint를 만들고, 운영단에서 발생하는 문제를 위한 sprint( ops )를 별도로 운영하며 비율은 80% 20%로 유지함

회고

• 스프린트 종료 후 각자 잘한점/개선할 점 각자 정리
• 개선할점 미안해서 안 쓰는 경우도 있는데 무조건 적게 해야 함
• 회고 진행 → 회고 미팅 → 최종 정리(by pm) → 다음 스프린트에 반영
  • ex. 000 프로세스 개편 ~

애자일의 핵심은 고객의 피드백을 듣고 원하는 제품을 만드는 것

수행주체는 사람이기에 팀 세팅이 가장 중요

소모되고 있다는 느낌보다는 의미 있는 일을 하고 있다는 동기부여

정체되어있기보다는 함께 성장하고 발전하는 과정

서로 신뢰하는 팀을 만들어야 한다.

→ 좋은 팀에서 좋은 프로덕트가 나온다.

잘하는 기획자의 기준은 무엇인가?

https://youtu.be/A5yHcKrgTHk

1. 기획을 잘한다는 것 = 업무 스타일이 맞는다는 것

• 넓게 트인 시야로 구체화
• 정리의 신
• 체계적인 위계 정리
• 일정관리의 신

2. 기획을 못한다는 것 = 쟤랑은 일 못하겠어

그게 아니라면, 어느 정도 기획을 하는 범주에 들어오는 것 → 그렇게 되면 업무 스타일이 생기게 된다.

ex. 잘하는 기획자 = 자신과 손발이 잘 맞는 기획자

ㄴ 여러 역량 중에, 동료들과 손발이 잘 맞느냐로 동료들에게 평가받을 수 있다.

ㄴ 기획을 잘한다는 객관적 지표는 없다. 누구와 손발이 잘 맞는가가 잘한다의 기준을 판단하는 것이고 그것은 개인마다 차이가 있을 수 있다.

if 내가 기획을 못하는 거 아닐까란 생각이 들 때

1. 정말 자질이 없을 때
2. 지금 이 팀이 안 맞을 때. 자신의 기획자로서의 성향과 안맞을때 → 조직 또는 팀을 바꿔보자

PO : 프로덕트를 이끄는 전문가

기획자 : 프로덕트의 완성도를 높여주고 현실화해주는 전문가

Con. 잘하는 기획자?

1. 객관적인 기준은 없다.
2. 주변 동료에 의해 평가된다.
3. 나와 손발이 잘 맞는 동료들을 주변에 두면 자연스럽게 잘하는 기획자가 된다.